[alsa-devel] rawmidi virtual and long sysexes
Hi alsa-devel,
Recently I noticed this problem and fixed it in the client consuming sequencer events: https://github.com/munt/munt/commit/0ea0846d0849872acf4384bdf5edeff026d12f42
Basically, the rawmidi virtual plugin enforces a 256-byte limit on events, and emits multiple events if e.g. a >256 byte sysex is encountered.
This does not seem to be documented behavior for snd_seq_event_input(), nor is the fixed limit described anywhere.
Would it be better if the maximum event size could be configured through params? That would avoid needing this clumsy workaround by sequencer clients. In any case, it seems that the documentation should be updated to reflect the need to receive multiple sequencer events to complete a sysex if EOX is not located in the first.
Please cc me as I'm not subscribed.
Ryan C. Underwood wrote:
Basically, the rawmidi virtual plugin enforces a 256-byte limit on events, and emits multiple events if e.g. a >256 byte sysex is encountered.
All sequencer clients have such a limit.
This does not seem to be documented behavior for snd_seq_event_input(), nor is the fixed limit described anywhere.
Yes, the documentation is lacking.
Would it be better if the maximum event size could be configured through params? That would avoid needing this clumsy workaround by sequencer clients.
Handling split messages cannot be avoided; the API is not capable of sending arbitrarily large messages.
Regards, Clemens
On Tue, Dec 22, 2015 at 06:51:47AM +0100, Clemens Ladisch wrote:
Ryan C. Underwood wrote:
Basically, the rawmidi virtual plugin enforces a 256-byte limit on events, and emits multiple events if e.g. a >256 byte sysex is encountered.
All sequencer clients have such a limit.
I was not objecting to a limit. I was questioning the utility of a _hard-coded_ limit.
This does not seem to be documented behavior for snd_seq_event_input(), nor is the fixed limit described anywhere.
Yes, the documentation is lacking.
What's the best way to submit a documentation change, patch the docs embedded in the code and mail that here?
Would it be better if the maximum event size could be configured through params? That would avoid needing this clumsy workaround by sequencer clients.
Handling split messages cannot be avoided; the API is not capable of sending arbitrarily large messages.
So, the client writing to rawmidi has local knowledge about the largest sysex he will generate. I only propose that alsa-lib be willing to accept this local knowledge over its own hard-coded default when sizing the event buffer. (For example, the device buffer size is configurable by the sequencer client.)
Of course, I won't bother if such a patch would be rejected, and will instead change the documentation.
On Tue, Dec 22, 2015 at 06:51:47AM +0100, Clemens Ladisch wrote:
Ryan C. Underwood wrote:
Basically, the rawmidi virtual plugin enforces a 256-byte limit on events, and emits multiple events if e.g. a >256 byte sysex is encountered.
All sequencer clients have such a limit.
Clemens, could you please clarify what did you mean in this message: http://mailman.alsa-project.org/pipermail/alsa-devel/2015-March/088852.html Didn't you mean the limit is 4096?
Handling split messages cannot be avoided; the API is not capable of sending arbitrarily large messages.
We are having this problem with munt, and for munt the largest sysex it can parse, is AFAIK around 300 bytes. It doesn't need the arbitrary large messages, because they are illegal for it. It should better have them dropped entirely. IMHO it would be nice to have the default buffer size large anough to avoid the fragmentation for all practical cases, leaving the fragmentation capability only for the pathological/ theoretical cases. 4096 is enough for this. 1024 is enough. 256 is obviously not. So IMHO it would be nice to just enlarge the default and save people from the troubles they actually really do not need to take. I mean, even the 1-byte buffer will work, but is it sane? pipes etc have >=4096 bytes AFAIK, so it is obviously not a problem for kernel to allow just that. So the question is very simple: why not?
participants (3)
-
Clemens Ladisch -
Ryan C. Underwood -
Stas Sergeev