Reply To: Different length of stored sound files with MediaRecorder()

PennController for IBEX Forums Support Different length of stored sound files with MediaRecorder() Reply To: Different length of stored sound files with MediaRecorder()



Unless you have high-quality hardware in a controlled environment, you won’t reach millisecond-precise computation. Every single instruction takes time to be executed on a machine, including low-level steps such as receiving and processing audio signal from the microphone or updating the display on the monitor, or higher level steps such as executing the PennController commands in your script

Some things work in a cyclic way, including the way Timer elements work, and I think audio processing too. If the process happens to start near the end a cycle and end near the beginning of another cycle, you might end up with two extra cycles (compared to a situation where the process happens to start at the beginning of a cycle and end at the end of the current cycle)

Because you call record on the MediaRecorder element and then wait on the two Timer elements before calling stop on the MediaRecorder element, the audios will be at least 3000ms long. But if the Timer elements happen to be longer than their respective duration, the audios will be longer too. Plus the delays due to internal processing

The differences you see between the End-Start subtractions and the actual audio file lengths are also due to processing delays: the MediaRecorder element logs when the record and stop commands are executed, but there also are small delays between when the commands are executed, and when they actually take effect at a lower level. Ideally, I should have designed the element to log both the timestamps of the record and stop commands, and the actual start/stop events of the recorder (which should be closer to when recording actually happens)

You might get closer to an actual duration of 3000ms by doing away with the extra layer of PennController and writing your experiment directly in javascript instead, but you will likely still end up with delays, because javascript is executed in the browser at a rather high level. If you really need high time accuracy, you’d be better off writing your experiment using a lower-level paradigm and running it on the same machine using a high-quality recording device for all your participants. Then you’ll get as close to 3000ms as can be nowadays