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@xxxxxxxx>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.
