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
sound/firewire/amdtp-am824.c | 50 +++++--------
sound/firewire/amdtp-stream.c | 108 +++++++++++++++++++++++++--
sound/firewire/amdtp-stream.h | 12 +--
sound/firewire/digi00x/amdtp-dot.c | 18 ++---
sound/firewire/fireface/amdtp-ff.c | 18 ++---
sound/firewire/motu/amdtp-motu.c | 18 ++---
sound/firewire/tascam/amdtp-tascam.c | 18 ++---
7 files changed, 146 insertions(+), 96 deletions(-)
--
2.37.2
