[LAD] sequencer and sysex again

[Fons Adriaensen]

On Fri, Jun 06, 2008 at 08:47:27PM +0200, rdxesy at yahoo.de wrote:

> I guess this makes things clearer :)

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.