Hi,
Thanks for your report and I'm sorry for your inconveniences.
On Thu, Jul 24, 2025 at 12:37:48PM +0200, M. Armsby wrote:
Firewire Midi was working fine with kernel 5.10 with Reaper. Then obviously a lot changed with the Firewire Stack.
The midi output from Reaper has not changed according to it's developer - Justin. The problem is direct ALSA-Midi.
We tested the midi app from www.alsa-project.org/alsa-doc/alsa-lib/_2test_2rawmidi_8c-example.html#a0 yesterday and it freezes Debian and just breaks Arch with kernel 6.15
Thread at Reaper Bugs forum:
https://forum.cockos.com/showthread.php?t=300278
Has low level ALSA-Midi API changed?
As long as briefly testing with the 'test/rawmidi.c' in alsa-lib and my Tascam FireOne (handled by snd-oxfw) in Ubuntu 25.04 (6.14.0-24-generic), I face no issue addressed in the above thread.
I think it depends on the type of device (and driver). Would I ask you the devices you used when facing the issue? I would regenerate the issue with the same device.
Additionally, it is preferable to share the purpose of your kernel configuration, especially to linux-realtime or so.
(I realized that test/rawmidi.c in alsa-lib includes a bug that read(2) system call in internal snd_rawmidi_hw_tread() does not return even if receiving SIGINT signal. The careless installation of signal handler may causes the bug...)
If using Pipewire-Jack with ALSAfirewire the Reaper midi output works fine but unfortunately Pipewire adds 90ms delay when playing back through any Firewire interface compared with an onboard soundcard.
The pipewire dev Wim Tayman, says it's ALSAfirewire fault but I proved it is not - see thread:
https://gitlab.freedesktop.org/pipewire/pipewire/-/issues?show=eyJpaWQiOiI0N...
The ALSA recording and playback is confirmed by my tests to be working under 10ms RTT with Echo, Motu and Bebop interfaces.
Is this problem related to first? Low level communication error?
The 90ms delay is reasonable..., depending on the PCM buffer configuration.
At present, all of drivers in ALSA firewire stack works with such delay due to queued initial packet. Therefore PipeWire computes the delay as expected. We would need to reeinvent the packet streaming engine if reducing the delay.
Thanks
Takashi Sakamoto