linux-kernel - Re: ALSAfirewire broken / Pipewire 90ms delay

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <48A27ABA-5EF6-400D-A47A-103C1A4ABC6D@gmx.de>
Date: Tue, 02 Sep 2025 09:59:58 +0200
From: "M. Armsby" <m.armsby@....de>
To: alsa-devel@...a-project.org
CC: Takashi Sakamoto <o-takashi@...amocchi.jp>, linux-kernel@...r.kernel.org
Subject: Re: ALSAfirewire broken / Pipewire 90ms delay

On 30 July 2025 21:36:00 CEST, "M. Armsby" <m.armsby@....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@...amocchi.jp>
>Sent: 24 July 2025 16:38:13 CEST
>To: m.armsby@....de
>Cc: alsa-devel@...a-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