Canvas presentation time issue

cltsson

Dear all,

This post follows this one : https://forum.cogsci.nl/discussion/comment/28157. As it's about a different topic, I thought it would be wiser to create a different thread.

The context :

I'm working on a voice key detection script that runs until a timeout occurs and record a sound file. While the recording runs, the script compares the loudness of the sound to a threshold and extract the response time on that basis. This will be a script that we will use for various purposes (mental calculation, reading, ...).

To try it out, I implemented it to the Lexical-decision task sample OS experiment. I want words/non-words to be presented for 2000 ms and sound to be recorded from stimulus presentation onset. Hence, the word canvas duration is set to 0 and I place my script right after. So far so good.

The issue :

The problem is that the canvas will be shown until the whole script is processed and not necessarily the 2000 ms of sound recording. For example, I tested the timing of canvas presentation and I'm more around 2300/2400 ms of presentation time, which is totally inacceptable for time-sensitive experiment.

The question :

How can I make sure that canvas presentation is "exactly" 2000 ms, that sound recording start "exactly" when canvas is shown, and stops "exactly again" when the canvas disappears ?

I'm sure I'm missing something quite obvious.

Many thanks for your help.

For your perfect illustration, I joined the script as an attachment.

Voicekey.txt

eduard

I am not sure how this works with pyaudio, but generally, you have to be careful blocking the cpu during a loop. Things like wait, sleep, etc. block the computer such that nothing can happen during that duration, including keeping track of durations. So when you want your loop to not last longer than 2 seconds, you have to make sure your iterations are very short. What happens in your case, (I think) is that

block = stream.read(chunk)

is doing such blocking, lasting for a few hundred millisecond, maybe? such that the temporal resolution of your loop is limited by this bit. If you can, try to reduce the size of the chunks to maybe only 10-20 ms. Still not ideal, but then your temporal delay will be much less

Alternatively, you can always set the time limit to something clearly smaller (1500ms), and in case too much time is left add an additional wait period before the next trial, rather than the current response period.

I hope this makes sense.

Eduard

cltsson

Thanks for answering so promptly, it makes perfect sense !

I investigated a bit and calculated the timing of different elements in the script and it seems that this bit :

# Listen for sounds until a timeout occurs.
start_time = clock.time()

print(f"Trial n° {Trial_nbr} starts recording")

while clock.time() - start_time <= timeout:
    try:
        block = stream.read(CHUNCK)
        frames.append(block)
    except IOError as e:
        print(e)
    loudness = get_rms(block)
    list_ldn.append(loudness)
    list_ct.append(clock.time())

end_time = clock.time()

# Close the audio stream
stream.stop_stream()
stream.close()
p.terminate()
print("%f ms total duration" % (end_time - start_time))

runs for an average of 2015 ms - which seems totally acceptable given that the ~15 ms delay is quite consistant.

The part that seems to take some time (and is more inconsistant) is this one :

# Opens the microphone
stream = p.open(
    format=FORMAT,
    channels=CHANNELS,
    rate=RATE,
    input=True,
    input_device_index=0,
    frames_per_buffer=INPUT_FRAMES_PER_BLOCK
    )

it seems to take between 150 to 350 ms and delays the sound recording - does that sound possible to you ? (pun not intended).

Therefore, and I am really not sure it's the right thing to do - so I'm might need some guidance on this - I place this part of the script in the prepare part of the script so that it doesn't load when timing is of the essence. It seems that this way the canvas presentation matches the timeout duration (~2000 ms) but is there something else I'm not considering that might make this a wrong solution ?

Thanks for your help !

eduard

Yeah, that sounds legit. Again, I don't know how it works with audio, but for eye tracking it is similar, that first a connection to the device must be established that can take some few hundred milliseconds. And it generally also makes sense to move the time-consuming part to parts of the sequence that are not time-sensitive. The risk then is that the connection is open for "unnecessary" long durations, such that bad things can happen if anything unexpected happens. But normally, there shouldn't be a problem.

As last time, I would advice you to just try it out, maybe take some benchmarks and if everything looks fine, you're good to go!

Eduard

cltsson

Makes perfect sense, thanks for your input ! I might as well just try to open the stream between the fixation cross on the stimuli sequence - might just do the trick !

Anyways, appreciate your input ! Thanks