On Tue, 10 Jan 2023 14:49:30 +0100,
Takashi Sakamoto wrote:
>
> For reasons, all drivers in ALSA firewire stack have never reported extra
> delay for the runtime of PCM substream. The main reason is that the
> meaning of extra delay differs depending on driver design. Another
> technical reason is that no kernel API was provided to know the current
> hardware time.
>
> I realized that the extra delay is helpful to user space PCM applications
> in the case of packet-oriented drivers since the drivers have a gap
> between the current transmission cycle and the latest transmission cycle
> to which the packet is processed (for PCM capture) or scheduled (for PCM
> playback). The amount of PCM frames delivered during the gap is usually
> invisible from the application as is in reported delay.
>
> A commit baa914cd81f5 ("firewire: add kernel API to access CYCLE_TIME
> register") was already merged into Linux kernel v5.19 or later, and the
> unit drivers can read hardware time and calculate the current isochronous
> cycle. Moreover, a commit f0117128879b ("ALSA: firewire-lib: keep history
> to process isochronous packet") enables to keep the recent history of
> packets, including cycle count and data block count.
>
> It is ready at last. This patchset adds computation of the extra delay.
>
> Takashi Sakamoto (3):
> ALSA: firewire-lib: move parameter for pcm frame multiplier from
> context payload processing layer
> ALSA: firewire-lib: obsolete return value from context payload
> processing layer
> ALSA: firewire-lib: compute extra delay for runtime of PCM substream
Thanks, applied now.
Takashi
