BUG: jrecord triggered recording ends prematurely
pmalonis opened this issue · comments
The bug occurs when using jrecord with recording triggered by jstim or jdetect. If the client first connected to the jrecord trigger port shuts down and a new client is connect, the first recording triggered by the second client ends prematurely. Here are the sequence of commands I used to reproduce the bug:
jackd -d alsa&
jrecord -t -I stim -f test6.arf &
jstim -r 5 song.wav -o jrecord:stim -e jrecord:trig_in
jstim -r 5 song.wav -o jrecord:stim -e jrecord:trig_in
In this case the sixth recording is cut off in the middle of the stimulus playback.
Commenting out "arf_thread->reset()" in the jack_portcon function of
jrecord.cc prevents the bug, as does commenting out "stop_recording(data->time + nframes)" in triggered_data_writer::write in the "if (_recording)" block. Commenting out "_writer->close_entry()" in buffered_data_writer::write doesn't prevent the bug, however (I might have mistakenly said so earlier).
Even after these fixes, the first recording triggered by the second client still doesn't contain the full pre-trigger time (about .7s as opposed to 1s).
Running these commands with verbose log messages turned on may indicate something about the underlying problem. Here's the log messages for the fifth entry:
20131220T221712.138538 [jrecord] D: trigger on event: time=50937536
20131220T221712.153564 [jrecord] created entry: /jrecord_0004 (frame=50889536)
20131220T221712.153707 [jrecord] I: writing pretrigger data from 50889536--50937536
20131220T221712.153757 [jrecord] D: prebuf frame: t=50888704, on=832, id=stim, dtype=0
20131220T221712.153938 [jrecord] created dataset: /jrecord_0004/stim
20131220T221712.154912 [jrecord] created dataset: /jrecord_0004/trig_in
20131220T221712.154981 [jrecord] D: event: t=50937536 id=trig_in status=0 message=07E250DFF0DEF4C41369A5506E2A1C85
20131220T221713.866790 [jrecord] D: trigger off event: time=51020144
20131220T221713.867176 [jrecord] I: writing posttrigger data from 51020144--51044144
20131220T221713.867549 [jrecord] D: event: t=51020144 id=trig_in status=16 message=07E250DFF0DEF4C41369A5506E2A1C85
20131220T221713.868604 [jrecord] ports disconnected: jstim:trig_out -> jrecord:trig_in
20131220T221713.868726 [jrecord] I: last input to trigger port disconnected
20131220T221713.870071 [jrecord] ports disconnected: jstim:out -> jrecord:stim
And here's the output from the sixth entry:
20131220T221740.542896 [jrecord] ports connected: jstim:out -> jrecord:stim
20131220T221740.543776 [jrecord] ports connected: jstim:trig_out -> jrecord:trig_in
20131220T221740.704588 [jstim] next stim: 07E250DFF0DEF4C41369A5506E2A1C85 (1.721 s)
20131220T221740.725627 [jrecord] D: trigger on event: time=52308992
20131220T221740.741237 [jrecord] created entry: /jrecord_0005 (frame=52260992)
20131220T221740.741476 [jrecord] I: writing pretrigger data from 52260992--52308992
20131220T221740.741521 [jrecord] D: prebuf frame: t=52260864, on=128, id=stim, dtype=0
20131220T221740.741722 [jrecord] created dataset: /jrecord_0005/stim
20131220T221740.742596 [jrecord] created dataset: /jrecord_0005/trig_in
20131220T221740.742666 [jrecord] D: event: t=52301168 id=trig_in status=16 message=07E250DFF0DEF4C41369A5506E2A1C85
20131220T221740.743361 [jrecord] D: event: t=52308992 id=trig_in status=0 message=07E250DFF0DEF4C41369A5506E2A1C85
20131220T221740.743658 [jrecord] I: writing posttrigger data from 52308993--52332993
Note that there's an event on the trig_in channel with status code 16 (stim off) just before the event with status 0 (stim on). I'm not sure where the offset event is coming from, because the last event from the first jstim run has a much earlier sample count. Tried running the second time with a different stimulus, and the extra event has the first stimulus name in it, so somehow this event is hanging around in some buffer and getting reprocessed.
In any case, the real problem is that the stim off event is taking precedence and causing the entry to terminate immediately after it starts.
On further examination, the stray stim_off event doesn't seem to be causing the entry to be prematurely closed. Instead, it's because the call to arf_thread::reset sets buffered_data_writer::_reset to true, and that doesn't get checked in triggered_data_writer::write until recording has started. I'll fix this and file the stray event bug separately