On Wed, 02 Jun 2021 03:34:03 +0200,
Takashi Sakamoto wrote:
>
> 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
Applied all three patches now. Thanks.
Takashi
