Hello everyone.
2 Firewire problems with ALSAfirewire.
1. 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?
2. 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?
Cheers - and let me know if I can help in any way, although I'm not a programmer.
P. S. I hope you can read my post as I loaded up K-9 eMail client so as to deliver text only.
-- Martin Armsby
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
The new ALSAfirewire drivers are very good. Well done to everyone who worked on them!
Today I tested brand new CachyOS with xfce desktop kernel 6.15 Initial Pipewire test showed RTT 98ms at 64/44100 so I uninstalled all traces of Pipewire and installed PulseAudio and Jack2 instead. I first tested ALSA direct from Reaper with Echo Audiofire4, Pianoteq and the RTT was as expected around 8ms (no 90ms) Then Jack2 with ALSAfirewire. The result was very similar and around 2% less rtCPU usage but a few X-runs on page refresh. I then set CPU to balanced and Jack failed with hundreds of X-runs whereas your wonderful ALSAfirewire alone continued with no X-runs :)
So you don't need to re-invent anything and there is nothing reasonable about 90ms delay. ALSAfirewire is working fine as long Pipewire isn't involved.
Please fix the Pipewire problem as now nearly all distros are issued with it and everyone is blaming ALSAfirewire stack! This madness should be stopped don't you agree?
Please.
Thanks Martin Armsby
-------- Original Message -------- From: Takashi Sakamoto o-takashi@sakamocchi.jp Sent: 24 July 2025 16:38:13 CEST To: m.armsby@gmx.de Cc: alsa-devel@alsa-project.org Subject: Re: ALSAfirewire broken
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
-- Martin Armsby
On 30 July 2025 21:36:00 CEST, "M. Armsby" m.armsby@gmx.de wrote:
The new ALSAfirewire drivers are very good. Well done to everyone who worked on them!
Today I tested brand new CachyOS with xfce desktop kernel 6.15 Initial Pipewire test showed RTT 98ms at 64/44100 so I uninstalled all traces of Pipewire and installed PulseAudio and Jack2 instead. I first tested ALSA direct from Reaper with Echo Audiofire4, Pianoteq and the RTT was as expected around 8ms (no 90ms) Then Jack2 with ALSAfirewire. The result was very similar and around 2% less rtCPU usage but a few X-runs on page refresh. I then set CPU to balanced and Jack failed with hundreds of X-runs whereas your wonderful ALSAfirewire alone continued with no X-runs :)
So you don't need to re-invent anything and there is nothing reasonable about 90ms delay. ALSAfirewire is working fine as long Pipewire isn't involved.
Please fix the Pipewire problem as now nearly all distros are issued with it and everyone is blaming ALSAfirewire stack! This madness should be stopped don't you agree?
Please.
Thanks Martin Armsby
-------- Original Message -------- From: Takashi Sakamoto o-takashi@sakamocchi.jp Sent: 24 July 2025 16:38:13 CEST To: m.armsby@gmx.de Cc: alsa-devel@alsa-project.org Subject: Re: ALSAfirewire broken
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
-- Martin Armsby
So everyone is pleased ALSAfirewire is working so well with RTT under 10ms
The issue about 90ms is successfully addressed at my request:
https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/4785
I hope you can further support Firewire as many are now really excited about finally being able to use it in professional studios without the (firewire playback only) dreaded 90ms.
Im so glad I managed to wake the sleeping Firewire dragon and Wim Taymans is working on the buffers correction needed to work around ALSAfirewire 90ms which no one needed.
Cheers
Martin Armsby Martin A - maa -- Martin Armsby
participants (2)
-
M. Armsby -
Takashi Sakamoto