22 Oct
2009
22 Oct
'09
8:17 p.m.
Hi,
On Thu, 22 Oct 2009 13:46:51 -0400
Paul Davis <paul(a)linuxaudiosystems.com> wrote:
[..]
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
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.