rawmidi virtual and long sysexes

rawmidi virtual and long sysexes

[Ryan C. Underwood]

[-- Attachment #1.1: Type: text/plain, Size: 879 bytes --]


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, <nemesis@icequake.net>

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 173 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: rawmidi virtual and long sysexes

[Clemens Ladisch]

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

Re: rawmidi virtual and long sysexes

[Ryan C. Underwood]

[-- Attachment #1.1: Type: text/plain, Size: 1426 bytes --]

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.

-- 
Ryan C. Underwood, <nemesis@icequake.net>

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 173 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: rawmidi virtual and long sysexes

[Stas Sergeev]

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?