Hi,
In a commit f9e5ecdfc2c2 ("ALSA: firewire-lib: add replay target to cache
sequence of packet"), I categorize devices supported by drivers in ALSA
firewire stack in terms of the way to deliver effective sampling
transfer frequency. This patchset is for the devices in group 3.
The devices are known to have problems when ALSA firewire-motu driver
handles. Many of them generate sound with noise. In the worst case, it
generates no sound.
The devices interpret presentation time to decide playback timing.
Unlike the syt-aware devices, the devices interpret the presentation
time in source packet header (SPH) per data block, instead of the
presentation time in syt field of CIP header.
Current implementation of the driver processes the sequence of outgoing
packet by computation according to nominal sampling transfer frequency.
However, the ideal sequence is not adequate to the devices, actually.
With this patchset, the drivers are going to replay the sequence of
incoming packets for media clock recovery, instead of nominal sampling
transfer frequency. For the detail of sequence replay, please refer to a
commit 39c2649c71d8 ("ALSA: firewire-lib: replay sequence of incoming
packets for outgoing packets"). The sequence replay is done by two levels;
the sequence of the number of data blocks per packet, and the sequence of
SPH per data blocks in the packet.
Takashi Sakamoto (3):
ALSA: firewire-motu: use macro for magic numbers relevant to IEC
61883-1
ALSA: firewire-motu: cache event ticks in source packet header per
data block
ALSA: firewire-motu: sequence replay for source packet header
sound/firewire/motu/amdtp-motu.c | 136 +++++++++++++++---------------
sound/firewire/motu/motu-stream.c | 27 +++++-
sound/firewire/motu/motu.h | 14 ++-
3 files changed, 104 insertions(+), 73 deletions(-)
--
2.27.0
