Both mechanisms play a 4kHz tone in the left audio channel for a user specified interval, followed a similar period of silence specified in the 50% of Cycle Period edit box.   The first method, activated when the "Use DirectSoundCapture" checkbox is checked, will measure the latency automatically with no external equipment other than a connector to connect the LINE IN input on the sound card to the LINE OUT or the use of the Stereo Mix recording device should your system have one, in a similar fashion to a VOX it looks for signal energy in the captured data after the tone has been played.   The second method, activated when the "Use PIO12 output" is checked assumes you have installed a PIO card and tested it with the PIO Test, it will send a LOW signal to all 8 bits of Port C of the PIO when the 4kHz signal is played, you can then measure the latency externally.
    In a similar fashion to the Tachistoscopic Acid Test you will be able to specify various other sound files to be played at the same time in order to ascertain what effect (if any) extra mixing has, note that the time values of when the buffers are to be played are in milliseconds, not tics as they are in the Tscope test.   If using DirectSoundCapture to measure latency and also playing buffers you will have to go to some care to make sure the buffers are played in the channel that the beep is not played in (if everything is setup correctly the beep and the DirectSoundCapture should be using the left channel so when you setup the buffers in the Sound test check the Right Channel and uncheck the Left Channel if it is already checked).
   
    When using DirectSoundCapture you will want to test whether you have got the LINE IN correctly connected to the LINE OUT, using the Sound test is a great help.   You can play a wave in the left channel and then click the Record button and you should be able to see a signal on the VU display, if you don't see any signal you will want to check the volume control applet in the control panel (or on the task bar), check the Options / Properites / Recording controls and check that the LINE IN input is selected and at maximum volume.
    Also when using DirectSoundCapture to measure latency clicking the Refresh button updates the results currently gathered (otherwise they will only be displayed when the test is stopped), if you notice that the standard deviations are large (like >50% of the average) then increase the period duration.   In testing on a an old Sound Blaster 16 that has a quite high latency of 16ms (later sound cards such as the Turtle Beach Montego have a latencies in the order of 2ms) I noticed that when using the default value of the "50% of Cycle Period" control, 50ms, the test was having a great deal of trouble getting consistent latencies (the standard deviation was about equal to the average), setting 50% of the period to 80ms instantly cleared up the results and lowered the SD to 1.6ms.
   
    If using the PIO12 output and a logic analyzer, once you have determined the size of the latency you can enter it in the Observed Sound Latency box, otherwise click the "Use DSC results" button after the test has run using DirectSoundCapture.   DMDX will use this value to offset the latency of playing a buffer.   NOTE: There is one of these onset values per audio driver so if you change drivers you will need to set this value again.   If at a later date we find more variables affect this onset then there will be more registry keys (like maybe frequency or the number channels) and the onset of each will need to be measured.
    TimeDX will not use this value it any way, it simply writes it into the registry, to determine whether the value is being used to good effect you will have to use DMDX -- there is a discussion and an example in the DMDX help file under Sound.

    You might be wondering why the PIO stuff is included when the test can now automatically determine latency using DirectSoundCapture.   The answer is primarily because the PIO stuff was written first and secondarily because having DirectSoundCapture active may itself introduce additional latency that may not be present when DMDX is running if you don't use the DigitalVOX.   Having used an oscilloscope on my development systems I can see that using DirectSoundCapture incurs a small additional latency of about 0.5ms, however an oscilloscope is hardly an accurate tool to measure this latency with so I really can't tell.   What I can tell though is that the additional latency is insignificant and given the impressive accuracy of DirectSoundCapture's results in this test thoroughly recommend it's use -- your system's drivers may be different though.

    Having measured the latency with this test under the best case scenario where there are no other threads doing things like moving data into video memory and others that are keeping track of the vertical retrace there will be additional variable latency introduced when DMDX runs with all the other tasks it performs and they have to interleave themselves with the sound related tasks.   At this juncture there is little that can be done other than to decide which task has the highest priority in the experimental situation you are using.   If presentation accuracy of acoustic stimuli is the primary thing you are interested in then you will have to use the Task Priorities dialog and move the priority of the sound thread to HIGHEST, above the priority of the vertical retrace thread (usually running at ABOVE_NORMAL priority), otherwise leaving things at default settings should be adequate.

    Assuming I haven't gotten bored and fixed this test it appears to be broken under Windows 10.  However a better test is to use DMDX itself to measure the capture latency and there's a section in the DMDX help on that.





TimeDX Index.