ALSAfirewire broken
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
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.
@wtaymans Wim Taymans and some guest programmers found a simple workaround to bypass the 90ms delay:
monitor.alsa.rules = [ { matches = [ { node.name = "alsa_output.firewire-0x000a35003926b6db.pro-output-0" } ] actions = { update-props = { api.alsa.period-num = 3 } } } ]
The communication from DAW to pure ALSAfirewire is not burdened with 90ms so please change the pins or whatever pipewire is using, so that it can avoid the 90ms like a DAW does when communicating directly to ALSAfirewire driver. It must be obvious and easy to see in comparison and thus fix.
ALSAfirewire RTT = 10ms Pipewire-Firewire RTT = 10 + 90ms
Please, many professionals are waiting for this fix which will boost Linux up to professional level.
Thanks
-- Martin Armsby
On 2 September 2025 09:59:58 CEST, "M. Armsby" m.armsby@gmx.de wrote:
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.
@wtaymans Wim Taymans and some guest programmers found a simple workaround to bypass the 90ms delay:
monitor.alsa.rules = [ { matches = [ { node.name = "alsa_output.firewire-0x000a35003926b6db.pro-output-0" } ] actions = { update-props = { api.alsa.period-num = 3 } } } ]
The communication from DAW to pure ALSAfirewire is not burdened with 90ms so please change the pins or whatever pipewire is using, so that it can avoid the 90ms like a DAW does when communicating directly to ALSAfirewire driver. It must be obvious and easy to see in comparison and thus fix.
ALSAfirewire RTT = 10ms Pipewire-Firewire RTT = 10 + 90ms
Please, many professionals are waiting for this fix which will boost Linux up to professional level.
Thanks
-- Martin Armsby
It's a great shame - that such issues are just ignored.
Lucky for us, Wim Taymans ist creating a workaround for Pipewire to bypass the ALSAfirewire 90ms buffer problemcwith help from some great reaper users and programmers. Soon to be released.
Regards Martin A -maa -- Martin Armsby
On 03. 09. 25 3:11, M. Armsby wrote:
On 2 September 2025 09:59:58 CEST, "M. Armsby" m.armsby@gmx.de wrote:
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.
@wtaymans Wim Taymans and some guest programmers found a simple workaround to bypass the 90ms delay:
monitor.alsa.rules = [ { matches = [ { node.name = "alsa_output.firewire-0x000a35003926b6db.pro-output-0" } ] actions = { update-props = { api.alsa.period-num = 3 } } } ]
The communication from DAW to pure ALSAfirewire is not burdened with 90ms so please change the pins or whatever pipewire is using, so that it can avoid the 90ms like a DAW does when communicating directly to ALSAfirewire driver. It must be obvious and easy to see in comparison and thus fix.
ALSAfirewire RTT = 10ms Pipewire-Firewire RTT = 10 + 90ms
Please, many professionals are waiting for this fix which will boost Linux up to professional level.
Thanks
-- Martin Armsby
It's a great shame - that such issues are just ignored.
Lucky for us, Wim Taymans ist creating a workaround for Pipewire to bypass the ALSAfirewire 90ms buffer problemcwith help from some great reaper users and programmers. Soon to be released.
For Takashi Sakamoto:
The hw_params constraints in the firewire driver should be improved based on [1]. The drivers may also require the SNDRV_PCM_INFO_BATCH info flag.
For reporter:
Please, show the procfs files (hw_params/status) for both playback and capture streams (pcm0p/pcm0c) for working 3 periods and 90ms setup - the reports in [1] are really messed up. But if pipewire uses the whole requested playback buffer, then the latency depends on the size of this buffer.
Jaroslav
[1] https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/4785
Hi Jaroslav,
On Wed, Sep 03, 2025 at 10:47:32AM +0200, Jaroslav Kysela wrote:
For Takashi Sakamoto:
The hw_params constraints in the firewire driver should be improved based on [1]. The drivers may also require the SNDRV_PCM_INFO_BATCH info flag.
How it works in this case?
Thanks
Takashi Sakamoto
On 03. 09. 25 13:15, Takashi Sakamoto wrote:
Hi Jaroslav,
On Wed, Sep 03, 2025 at 10:47:32AM +0200, Jaroslav Kysela wrote:
For Takashi Sakamoto:
The hw_params constraints in the firewire driver should be improved based on [1]. The drivers may also require the SNDRV_PCM_INFO_BATCH info flag.
How it works in this case?
I guess that the question is for the BATCH flag. It's just an information that the stream queuing is not granular enough like for PCI cards and the samples are queued in chunks to the hardware. Applications can handle the queuing differently in this case.
See also proposed (and applied) change in [2]. Please, read [1] thread referred in my previous e-mail to see the problematic buffer size configurations for firewire drivers.
Jaroslav
[2] https://gitlab.freedesktop.org/pipewire/pipewire/-/commit/9606b377769c8a4a9c...
Hi,
On Wed, Sep 03, 2025 at 02:19:59PM +0200, Jaroslav Kysela wrote:
On 03. 09. 25 13:15, Takashi Sakamoto wrote:
Hi Jaroslav,
On Wed, Sep 03, 2025 at 10:47:32AM +0200, Jaroslav Kysela wrote:
For Takashi Sakamoto:
The hw_params constraints in the firewire driver should be improved based on [1]. The drivers may also require the SNDRV_PCM_INFO_BATCH info flag.
How it works in this case?
I guess that the question is for the BATCH flag. It's just an information that the stream queuing is not granular enough like for PCI cards and the samples are queued in chunks to the hardware. Applications can handle the queuing differently in this case.
Hm. A packet can multiplex several Multi Bit Linear Audio (MBLA) data frames defined in IEC 61883-1/6 (e.g. 0, 6-8 frames per packet at 48.0 kHz sampling transmission rate) When considering the frame count reported by typical serial sound interface in embedded SoCs, this granularity is not particularly unusual, even if DMA transmission occurs between system buffer and the interface buffer. Since the ALSA PCM interface does not expose this granularity, it remains invisible to userspace applications, and application therefore cannot distinguish its origin. This is why these drivers does not report the BATCH flag[1].
Nevertheless, one likely reason might be that i programmed the IEC 61883-1/6 packet stream engine to recycle retired packet buffers as quickly as possible, using a "sequence replay" approach. This behaviour may appear as though it follow the concept of the BATCH flag.
I plan to redesign both the engine and PCM operation implementations of each driver to address this point, as well as to add support for SNDRV_PCM_INFO_SYNC_APPLPTR to packetize in application processes. However, it is not yet the right time (I still have some items in Linux firewire stack itself).
See also proposed (and applied) change in [2]. Please, read [1] thread referred in my previous e-mail to see the problematic buffer size configurations for firewire drivers.
In Linux FireWire subsystem, there is a size restriction on the context header within the.structure specific to isochronous context[2]. This software-side restriction determines the upper limit of the PCM buffer. The content of IEC 61883-1/6 CIP header is stored into this buffer, The frame count in each PCM period/buffer, as well as the total count itself, are governed by the computation of the number of headers fitting into the context header buffer[3]. The count differs by the design of target device. The design of protocol mentioned in the above appends more constraints[4].
[1] https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/commit/?id=d... [2] https://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394.git/tree/... [3] https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/tree/sound/f... [4] https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/tree/sound/f...
Regards
Takashi Sakamoto
On 04. 09. 25 15:18, Takashi Sakamoto wrote:
Hi,
On Wed, Sep 03, 2025 at 02:19:59PM +0200, Jaroslav Kysela wrote:
On 03. 09. 25 13:15, Takashi Sakamoto wrote:
Hi Jaroslav,
On Wed, Sep 03, 2025 at 10:47:32AM +0200, Jaroslav Kysela wrote:
For Takashi Sakamoto:
The hw_params constraints in the firewire driver should be improved based on [1]. The drivers may also require the SNDRV_PCM_INFO_BATCH info flag.
How it works in this case?
I guess that the question is for the BATCH flag. It's just an information that the stream queuing is not granular enough like for PCI cards and the samples are queued in chunks to the hardware. Applications can handle the queuing differently in this case.
Hm. A packet can multiplex several Multi Bit Linear Audio (MBLA) data frames defined in IEC 61883-1/6 (e.g. 0, 6-8 frames per packet at 48.0 kHz sampling transmission rate) When considering the frame count reported by typical serial sound interface in embedded SoCs, this granularity is not particularly unusual, even if DMA transmission occurs between system buffer and the interface buffer. Since the ALSA PCM interface does not expose this granularity, it remains invisible to userspace applications, and application therefore cannot distinguish its origin. This is why these drivers does not report the BATCH flag[1].
Nevertheless, one likely reason might be that i programmed the IEC 61883-1/6 packet stream engine to recycle retired packet buffers as quickly as possible, using a "sequence replay" approach. This behaviour may appear as though it follow the concept of the BATCH flag.
I plan to redesign both the engine and PCM operation implementations of each driver to address this point, as well as to add support for SNDRV_PCM_INFO_SYNC_APPLPTR to packetize in application processes. However, it is not yet the right time (I still have some items in Linux firewire stack itself).
Thanks for this update.
See also proposed (and applied) change in [2]. Please, read [1] thread referred in my previous e-mail to see the problematic buffer size configurations for firewire drivers.
In Linux FireWire subsystem, there is a size restriction on the context header within the.structure specific to isochronous context[2]. This software-side restriction determines the upper limit of the PCM buffer. The content of IEC 61883-1/6 CIP header is stored into this buffer, The frame count in each PCM period/buffer, as well as the total count itself, are governed by the computation of the number of headers fitting into the context header buffer[3]. The count differs by the design of target device. The design of protocol mentioned in the above appends more constraints[4].
It would be nice to check the buffer size / period size values using procfs for the problematic 2048 setup (see the referred thread), if there's a demand to fix this. Maybe there's a mismatch between GUI/sound server settings and driver settings.
Jaroslav
On Thu, Sep 04, 2025 at 03:32:52PM +0200, Jaroslav Kysela wrote:
It would be nice to check the buffer size / period size values using procfs for the problematic 2048 setup (see the referred thread), if there's a demand to fix this. Maybe there's a mismatch between GUI/sound server settings and driver settings.
Please suggest that all people involved in the discussion use strace(1) to determine whether the failure originates from SNDRV_PCM_IOCTL_HW_PARAMS or SNDRV_PCM_IOCTL_PREPARE, since the alsa-lib API, 'snd_pcm_hw_params()', involves both and can be misleading.
Thanks
Takashi Sakamoto
participants (3)
-
Jaroslav Kysela -
M. Armsby -
Takashi Sakamoto