Fedora Account System
Red Hat Associate
Red Hat Customer
1. Please describe the problem: Context: First of all, the 'bug' is related to specific audio production device types that are using Web MIDI with SysEx extension. In my case it is Novation Circuit Tracks, a so called groovebox that used for creating and performing electronic music. WebMidi and SysEx is often a default way for transfer data in such devices, because of it does not require custom protocol, just MIDI, and works in Web (with WebMIDI). /Context My Novation Circuit Tracks is detected correctly and normal Web MIDI communication works in Chromium. Large SysEx transfers, specifically sample uploads from Novation Components, fail after approximately one second. Cause: >cat /sys/module/snd_seq_midi/parameters/output_buffer_size 4096 Fix: >sudo bash -c 'echo "options snd_seq_midi output_buffer_size=131072" > /etc/modprobe.d/snd-seq-midi-buffer-size-novation.conf' >sudo rmmod snd_seq_midi >sudo modprobe snd_seq_midi Increasing `output_buffer_size` from 4096 (default) to 131072 completely resolves the problem. 2. What is the Version-Release number of the kernel: Linux fedora 7.0.13-100.fc43.x86_64 3. Did it work previously in Fedora? Unknown 4. Can you reproduce this issue? Reproducing is not trivial if you do not own hardware that relies on the SysEx/WebMIDI transport. In my case, with Novation Circuit Tracks groovebox: 1. Use any Chromium(!) browser (native, no Flatpak) 2. Go to https://components.novationmusic.com/ 3. Connect device (Novation Circuit Tracks or similar) via USB 4. In the Novation Components web UI ensure it is connected and operational 5. In 'Samples editor' UI add any wav/mp3 sample to any slot 6. Click 'Send to Circuit Tracks' (or Send to <Your Device Name>) 7. Progress bar would appear and then it would crash with 'Something went wrong' after 1 sec 5. Does this problem occur with the latest Rawhide kernel? Untested. It is likely not related to particular version, but to `snd_seq_midi` module configuration 6. Are you running any modules that not shipped with directly Fedora's kernel?: No 7. Please attach the kernel logs. ``` rugp. 15 19:39:56 kernel: dump_midi: 10 callbacks suppressed rugp. 15 19:39:56 kernel: ALSA: seq_midi: MIDI output buffer overrun rugp. 15 19:39:56 kernel: ALSA: seq_midi: MIDI output buffer overrun rugp. 15 19:39:56 kernel: ALSA: seq_midi: MIDI output buffer overrun rugp. 15 19:39:56 kernel: ALSA: seq_midi: MIDI output buffer overrun rugp. 15 19:39:56 kernel: ALSA: seq_midi: MIDI output buffer overrun rugp. 15 19:39:56 kernel: ALSA: seq_midi: MIDI output buffer overrun rugp. 15 19:39:56 kernel: ALSA: seq_midi: MIDI output buffer overrun rugp. 15 19:39:56 kernel: ALSA: seq_midi: MIDI output buffer overrun rugp. 15 19:39:56 kernel: ALSA: seq_midi: MIDI output buffer overrun rugp. 15 19:39:56 kernel: ALSA: seq_midi: MIDI output buffer overrun ``` Reproducible: Always
Root cause: dump_midi() in sound/core/seq/seq_midi.c fails a chunk with -ENOMEM whenever it doesn't fit in the rawmidi output buffer, even on the write(2) path where the caller may sleep. Any one-shot SysEx larger than the buffer is dropped once the client gets ahead of the device by output_buffer_size bytes, so raising the module parameter only moves the limit. Patch sent upstream, waiting for the device to drain instead on the non-atomic path: https://lore.kernel.org/all/<message-id>/ Until it lands, the output_buffer_size workaround from comment 0 is the right one. If you can test a build with the patch, a Tested-by on the list thread would help.
Correct link for the patch in comment 1: https://lore.kernel.org/all/20260831143200.412572-1-junjie.cao@intel.com/(In reply to junjie.cao from comment #1) > Root cause: dump_midi() in sound/core/seq/seq_midi.c fails a chunk with > -ENOMEM whenever it doesn't fit in the rawmidi output buffer, even on > the write(2) path where the caller may sleep. Any one-shot SysEx larger > than the buffer is dropped once the client gets ahead of the device by > output_buffer_size bytes, so raising the module parameter only moves > the limit. > > Patch sent upstream, waiting for the device to drain instead on the > non-atomic path: > https://lore.kernel.org/all/<message-id>/ > > Until it lands, the output_buffer_size workaround from comment 0 is the > right one. If you can test a build with the patch, a Tested-by on the > list thread would help. Correct link for the patch in comment 1: https://lore.kernel.org/all/20260831143200.412572-1-junjie.cao@intel.com/
Upstream declined the blocking approach: the seq_midi event handler runs inside the sequencer delivery path and must not sleep for long, whatever the calling context. The maintainer's position is that a real fix needs a design change in the sequencer core (parking events per destination port with back-pressure to the writer). Thread: https://lore.kernel.org/all/871pbddz5k.wl-tiwai@suse.de/ Until that lands, the output_buffer_size workaround from comment 0 stands. It only raises the limit: a transfer that gets more than output_buffer_size bytes ahead of the device is still truncated silently, because Chromium sends SysEx as 256-byte direct events and does not check the result of snd_seq_event_output_direct().