Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
several overlapping calls to softCodeHandlerFunction
#1
Hi

I have a visual stimulus(2 sec long) being handled by the softcode handler function(softcode(1)). But at some points another softcode is being sent(softcode)by my statematrix before the visual stimulus is finished. It appears to me that the second call stays in queue until the first call returns. Is that right? Is there a work around for this so that the second call starts to execute immediate(i.e. in parallel)?
Reply
#2
Hi Mahyar


That sounds correct - since MATLAB is single-threaded, unless you explicitly implement multithreading with the parallel computing toolbox. Exceptions are timer and UI handle callbacks, which execute in parallel.

In the audio example protocol with psychtoolbox, an ongoing sound can be stopped with soft code "255", because the psychtoolbox "play" function is non-blocking. 

With visual stimuli, I'm assuming you are using the "flip" command in a loop, to swap video buffers - so MATLAB will be busy for the duration of your loop.
One way to solve this is with a MATLAB timer object, which you can make global. Your soft code handler starts playback by starting the timer: start(t), and ends playback by stopping it: stop(t). The timer callback function loads the next frame and calls flip().

I have a wrapper function in development to make this easy, but its current implementation assumes things about your setup (portion of the screen your video is on, its size, color not supported, etc.), and also hasn't been validated for frame rate interval uniformity. I will release it once it's debugged, but I can't promise a release date yet.

J
Reply
#3
(03-24-2017, 12:54 PM)Josh Wrote: Hi Mahyar


That sounds correct - since MATLAB is single-threaded, unless you explicitly implement multithreading with the parallel computing toolbox. Exceptions are timer and UI handle callbacks, which execute in parallel.

In the audio example protocol with psychtoolbox, an ongoing sound can be stopped with soft code "255", because the psychtoolbox "play" function is non-blocking. 

With visual stimuli, I'm assuming you are using the "flip" command in a loop, to swap video buffers - so MATLAB will be busy for the duration of your loop.
One way to solve this is with a MATLAB timer object, which you can make global. Your soft code handler starts playback by starting the timer: start(t), and ends playback by stopping it: stop(t). The timer callback function loads the next frame and calls flip().

I have a wrapper function in development to make this easy, but its current implementation assumes things about your setup (portion of the screen your video is on, its size, color not supported, etc.), and also hasn't been validated for frame rate interval uniformity. I will release it once it's debugged, but I can't promise a release date yet.

J

Hi Josh
Thank you for your answer. Yes true, I am using flip and the program(now octave) is busy. I looked into different options for multi-threading but at the end it doesn't like there is a straight forward for multi-threading for either Matlab or Octave.

Your proposal for timer sounds great and I think theoretically it should work with the frame rate uniformity. However I don't have access to the timer class(or something similar) on octave so far.

Right now I am thinking of using a trigger from the bpod to stop the softcodes, so that an i/o card would read it and the softcodehandler would check the port on the card inside it's loop that performs the visual stimulus update. Do you think this is a plausible approach and/or do you think this can be done without an additional i/o card but through the usb interface of the bpod itself?

M.
Reply
#4
Quote:Right now I am thinking of using a trigger from the bpod to stop the softcodes, so that an i/o card would read it and the softcodehandler would check the port on the card inside it's loop that performs the visual stimulus update. Do you think this is a plausible approach and/or do you think this can be done without an additional i/o card but through the usb interface of the bpod itself?

M.

Update: So my idea is to do a check during the visual-stimulus-update-loop and check if there is a message from Bpod to stop the loop. Looking through the code it sounds like if I read the Bpod output by BpodSerialRead(), I will also have to handle all the information coming from Bpod just like the RunStateMatrix.m does. But that loop is very slow(~100 ms) so what comes to my mind is two possiblities:

1- read the Bpod data during the loop(softcodeHandler), store them and react to specific codes(e.g. softcode 255) . When the softCodeHandler returns we can do all the updates in RunStateMatrix

2-Have Bpod(modify the firmware) send a code on another port in case of specific events(e.g. softcodehandler 255) to the governing computer and read that code inside the loop with a function like BpodSerialRead2ndPort().

I would appreciate if you can tell me your idea about the plausibility of these ideas.

Best Regards

Mahyar
Reply
#5
So just an update:

I solved this finally with a work around. I grabbed a parallel port and used the ack pin(easiest) to receive "stop visual stimulus" signal from the bpod(bnc out). And then I made a simple oct code(c++ code in octave equivalent of mex in matlab) to read the ack port. It is quite quick in reading the port so for every loop of visual stimulus update in the softcode handler I read the port and if it is "On" I stop the visual stimulus.

Although it is not straight forward it solves the issue and the visual stimulus is still played reliably.

Idea for further implementation: However I think it would be theoretically possible to use the other usb port of bpod to make another serial connection to the computer(though not a very fast one), right?
Reply
#6
Hi Mahyar


Great work on the hack, and thank you for sharing it!
It's a shame that Octave doesn't have a timer class. This will be a problem for full compatibility with Bpod going forwards. Several of the plugins for Bpod's new hardware modules use timer objects to show streaming data online, and the TrialManagerObject (a way to minimize dead-time between trials despite CPU-intensive online analysis) also depends on timer.

FYI, there is an updated version of the PsychToolboxVideoServer that supports color, and automatically runs a configurable sync patch to capture the precise timing of frame updates with a photodiode or a device like frame2ttl.

Thanks again for posting your work-around,
Josh
Reply


Forum Jump: