[LAD] Problem with small ALSA rawmidi app

[Frank Neumann]

Hi,
On Thu, 22 Oct 2009 13:46:51 -0400
Paul Davis <paul at linuxaudiosystems.com> wrote:

[..]

> > What I basically do is (code excerpt / pseudo code):
> >
> > snd_rawmidi_t *handle_in = 0, *handle_out = 0;
> > unsigned char ibuf[256];
> > unsigned char obuf[] = { 0xf0, .., 0xf7 }; /* 6 bytes sysex */
> >
> > snd_rawmidi_open(&handle_in, NULL, "hw:2,0,0", SND_RAWMIDI_NONBLOCK);
> >
> > snd_rawmidi_open(NULL, &handle_out, "hw:2,0,0", SND_RAWMIDI_NONBLOCK);
> >
> > snd_rawmidi_write(handle_out, &obuf, 6);
> > snd_rawmidi_drain(handle_out);
> >
> > // wait a little for the answer
> > // I know I should not do it this way, but for testing purposes..
> > usleep(1000000);
> >
> > num = snd_rawmidi_read(handle_in, ibuf, sizeof(ibuf));
> >
> > I know that the data is sent out, but reading back the answer always gives
> > me -1 for num.
> 
> you opened both ports in NON_BLOCKing mode.
> 
> this means that a read or write will ALWAYS return immediately, no
> matter whether there is data/space for the write/read or not.

That's right, but my thinking was that "after sending out the SysEx request,
draining the outbound connection and waiting for 1 second, some data should
be available in the incoming ringbuffer". I see from amidi experiments that
the device answers pretty promptly.

But I think I just found the solution myself, though I am not sure about the
reason - from alsa-utils/amidi/amidi.c, I took over this line of code, before
sending out my data:

 snd_rawmidi_read(handle_in, NULL, 0); /* trigger reading */

So, a dummy read on the inbound connection gets it going.
Now it works as expected. Any idea why this is necessary? "buffer pre-warm"?

Greetings,
Frank