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