[PATCH 0/3] ALSA: firewire-motu: media clock recovery for sph-aware devices

[Takashi Iwai]

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