Re: [LAD] sequencer and sysex again

On Fri, Jun 06, 2008 at 08:47:27PM +0200, rdxesy(a)yahoo.de wrote: What is this midi_spinbutton() ?? Is there anything in the midi_callback() that can block it ? A mutex or so reset after the parameter request loops ? There must be at least 10s of idle time in the second loop (with the usleep()). So if the midi receiver thread doesn't wake up during this time then - It could be blocked on something else and not be waiting in poll(). The trace message you added later should reveal this. - There is no data to receive. This would indicate some cramp in the device you're talking with that somehow freezes while being flooded with parameter requests. - There is a bug in the alsa code handling this. The really strange thing is that you *do* receive all the replies for those requests that were sent without a pause in between. It's the replies to some of the slower ones that are missing. This would suggest that, whatever goes wrong, the damage is already done before you start the second slower loop. You could try to decrease the number of iterations in the first one and see what happens, and if the results are repeatable. Another thing you should do is verify if you really need a separate request for each value. The last two SYSEX protocols I used both allowed to combine a number of requests in a single message, also combining the replies in that case. It would make sense for any device having so many parameters to support this. Another approach to avoid overflows in a system without flow control is to use a 'sliding window' system: for example you don't sent request #123 until you have received the answer for #113, ensuring there are never more than 10 (in this case) in the pipeline. It allows things to work at maximum speed without flooding buffers. Ciao, -- FA Laboratorio di Acustica ed Elettroacustica Parma, Italia Lascia la spina, cogli la rosa.