ALSAfirewire broken

ALSAfirewire broken

[M. Armsby]

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=eyJpaWQiOiI0Nzg1IiwiZnVsbF9wYXRoIjoicGlwZXdpcmUvcGlwZXdpcmUiLCJpZCI6MTM0OTgyfQ%3D%3D

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

Re: ALSAfirewire broken

[Takashi Sakamoto]

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:
> 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? 
 
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...)

> 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=eyJpaWQiOiI0Nzg1IiwiZnVsbF9wYXRoIjoicGlwZXdpcmUvcGlwZXdpcmUiLCJpZCI6MTM0OTgyfQ%3D%3D
> 
> 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

Re: ALSAfirewire broken / Pipewire 90ms delay

[M. Armsby]

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

Re: ALSAfirewire broken / Pipewire 90ms delay

[M. 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

Re: ALSAfirewire broken / Pipewire 90ms delay

[M. 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

Re: ALSAfirewire broken / Pipewire 90ms delay

[M. 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

Re: ALSAfirewire broken / Pipewire 90ms delay

[Jaroslav Kysela]

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

-- 
Jaroslav Kysela <perex@perex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.

Re: ALSAfirewire broken / Pipewire 90ms delay

[Takashi Sakamoto]

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

Re: ALSAfirewire broken / Pipewire 90ms delay

[Jaroslav Kysela]

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/9606b377769c8a4a9c9d5a6db5c824606308699c


-- 
Jaroslav Kysela <perex@perex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.

Re: ALSAfirewire broken / Pipewire 90ms delay

[Takashi Sakamoto]

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=d360870a5bcf
[2] https://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394.git/tree/drivers/firewire/ohci.c?h=v6.16#n3137
[3] https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/tree/sound/firewire/amdtp-stream.c?h=v6.16#n227
[4] https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/tree/sound/firewire/amdtp-stream.c?h=v6.16#n160


Regards

Takashi Sakamoto

Re: ALSAfirewire broken / Pipewire 90ms delay

[Jaroslav Kysela]

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

-- 
Jaroslav Kysela <perex@perex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.

Re: ALSAfirewire broken / Pipewire 90ms delay

[Takashi Sakamoto]

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