29 Jun
2020
29 Jun
'20
8:17 p.m.
I've been working on a problem with a Perl program sending and receiving
large sysex dumps via the ALSA::MIDI module. It looks like there is a
4kB buffer in ALSA rawmidi that can be overrun if things go in or out
too quickly. Keeping it from filling too fast outgoing is easy. But
since there is no way for MIDI to tell the remote sender to slow down,
preventing buffer overruns from incoming data is turning into a problem.
Is there a way I can either tune the size of the buffer from Perl,
perhaps with some kind of library call to ALSA's raw MIDI API, or
somehow make the access blocking so that it won't try to take more data
than it can handle? I've been looking at the C source for the amidi
command, but I'm trying to deal with this in Perl if possible.
It seems to depend a lot on how fast the device wants to send, but some
devices break the sysex transfer into chunks and try to slow down, and
other don't bother and just expect you to keep up.
29 Jun
29 Jun
10:52 p.m.
On Mon, 29 Jun 2020, Brent Busby wrote:
I've been working on a problem with a Perl program
sending and receiving
large sysex dumps via the ALSA::MIDI module. It looks like there is a
4kB buffer in ALSA rawmidi that can be overrun if things go in or out
too quickly. Keeping it from filling too fast outgoing is easy. But
since there is no way for MIDI to tell the remote sender to slow down,
preventing buffer overruns from incoming data is turning into a problem.
Is there a way I can either tune the size of the buffer from Perl,
perhaps with some kind of library call to ALSA's raw MIDI API, or
somehow make the access blocking so that it won't try to take more data
Blocking? from your own words above: "since there is no way for MIDI to
tell the remote sender to slow down" I would say blocking is not a choice.
than it can handle? I've been looking at the C
source for the amidi
command, but I'm trying to deal with this in Perl if possible.
It seems to depend a lot on how fast the device wants to send, but some
devices break the sysex transfer into chunks and try to slow down, and
other don't bother and just expect you to keep up.
Some devices respect the 3.1k midi bit rate, but others do not. Actual DIN
MIDI transfer is pretty much gone and MIDI is now mostly USB or networked.
Both USB (even v1) and network are capable of faster transfer rates. So it
is up to the device if they send things at MIDI speed or as fast as
possible. Most synths allow sending one patch at a time... but as synths
have gotten more complex, even one patch can be quite large.
So what does this tell us? ALSA has problems keeping up with MIDI sysex
already... what will happen with MIDI 2.0? (Jack is worse)
python-rtmidi in the rtmidi.MidiIn class, has queue_size_limit as a
parameter. If that actually changes the ALSA buffer size or not, I don't
know. It calls this: the size of the internal ring buffer. So is that a
ring buffer in ALSA (or whatever backend) or internal to the rtmidi lib
itself?
The ALSA seqencer itself has a resizable memory pool as well though I do
not know what limits it may have being in kernel space.
Note that I have just started my journey learning alsa midi sequencer API
myself... so I am not anywhere close to expert. (I have a program that is
jack midi I want to convert to alsa seq)
--
Len Ovens
www.ovenwerks.net
1602
days inactive
1602
days old
linux-audio-user@lists.linuxaudio.org
1 comments
2 participants
participants (2)
-
Brent Busby -
Len Ovens