| Message ID | 20230110134933.322794-1-o-takashi@sakamocchi.jp |
|---|---|
| Headers | show |
| Series | ALSA: firewire-lib: report extra delay of PCM runtime | expand |
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
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(-)