DMDX Help.


RecordVocal notes.

    It's impressive that over the years the RecordVocal input device has remained as problematic as it has but due to the singular predilection sound device driver writers have for making the same mistakes over and over DMDX continues to expose them.  The principal problem is that driver writers don't expect programs to start and stop recording vocalizations, they expect one start call at the start of the session and one stop call at the end.  Which isn't how DMDX works, it starts and stops the audio every item as it has no idea when it will next be needed.  A lot of the time just downloading new drivers will fix the issue however sometimes you just have to work with the drivers you have.  To do that you have to experiment with parameters to RecordVocal when you specify it as an input device, all of which is covered elsewhere (principally the two pages I've linked to here) but I might as well go over it in some detail in one location.

    How do you tell when it's not working?  Principally you see that the vocalizations are all over the place in the saved WAV files.  Of course if you're running an experiment this might not be so obvious as subject's vocalizations do tend to vary their onsets.  So you use the caputuretest.rtf item file in demos.zip on the web site similar to this:

<ep> <cr> <azk> f10 <t 4000> <id "keyboard"> <vm desktop>
<id recordvocal 150,500> <id digitalvox> </ep>
0 "This itemfile is for RecordVocal/DigitalVox testing." @-2 <set 1,1000>,
"WAV output must be looped to Input" @-1,
"(so the TimeDX Sound Latency test works)",
"RTs should be in the 1000ms range" @1;

+1 "first" / <wav 2> "1sec50ms" %0 <svp start> / * <%ms 1000> / "beep" ;
+2 "second" / <wav 2> "1sec50ms" %0 <svp start> / * <%ms 1000> / "beep" ;
+3 "third" / <wav 2> "1sec50ms" %0 <svp start> / * <%ms 1000> / "beep" <dec 1> <bicgt 1,0,-1> ;
0 L "The End" ;
 
    This file plays a 50 ms beep 1000 ms after the clock is turned on and assuming you've set the Digital VOX up correctly and your sound card is mixing the wave output into the sound input (whether by connecting the line output to the mic or line inputs or by setting the record device to use the wave output in the sound card control panel) you'll see 1000 ms RTs.  Of course nothing is ever perfect so you'll see some few milliseconds of variation (typically less than 5 ms) and should your machine have latencies recording and playing audio files (30 ms is not unusual on older hardware) you'll see those in there as well (you could remove them with the TimeDX Sound Latency test).  If however you see wildly varying RTs (hundreds of milliseconds) then you'll have to play with the overrun protection that RecordVocal has.  This basically makes the audio buffers DMDX uses larger and for some reason this appears to get around the errors.  Overrun protection is specified with the second parameter and a typical value I've seen work has been 500 ms although others report values as large as 1500 being needed (so <id recordvocal 150,1500>).




DMDX Index.