Re: [PATCH] ALSA: seq: midi: wait for output buffer space on non-atomic delivery

[Takashi Iwai]

On Mon, 31 Aug 2026 16:32:00 +0200,
Junjie Cao wrote:
> 
> dump_midi() drops a chunk with -ENOMEM as soon as it does not fit in the
> rawmidi output buffer, whatever context it runs in.  When a client
> write(2)s one large SysEx event, the event is dispatched directly with
> atomic == 0 and the payload is copied from user memory chunk by chunk
> (snd_seq_deliver_event() rejects USRPTR events with atomic set), so the
> caller can sleep, yet the transfer still dies as soon as it gets ahead
> of the device by output_buffer_size bytes:
> 
>   ALSA: seq_midi: MIDI output buffer overrun
> 
> The report is a sample upload to a Novation Circuit Tracks over Web
> MIDI, failing after about a second with the default 4096-byte buffer.
> Raising output_buffer_size only moves the limit.
> 
> When atomic is clear, wait for the device to drain instead, the way
> snd_rawmidi_write() does for a userspace writer: sleep on
> runtime->sleep with the same 30-second no-progress timeout and feed the
> buffer in pieces.  Atomic delivery keeps the fail-fast path.
> 
> A writer sleeping here still holds the source port's subscriber list
> read-side, so unsubscribing that connection waits for the transfer to
> finish or the timeout to fire.  midisynth_unuse() wakes a sleeping
> writer after clearing output_substream, so once teardown gets there it
> does not sit in snd_use_lock_sync() waiting out a stalled device.
> 
> Compile-tested only; no device with a large SysEx sink here.
> 
> Reported-by: Ruslan <ruslan.panasiuk@xxxxxxxxx>
> Closes: https://bugzilla.redhat.com/show_bug.cgi?id=2517136
> Signed-off-by: Junjie Cao <junjie.cao@xxxxxxxxx>

A large SYSEX is a long-standing PITA, and I appreciate your attempt
to fix it.  But, the problem is that you can't take long time in
dump_midi() which is called from the sequencer event handler, per
design; the atomic=false there doesn't mean that you are allowed to
block for a too long time like 30 seconds.

For working around this problem, we need a basic design change in ALSA
sequencer core, I'm afraid.


thanks,

Takashi