| Message ID | 20210602013406.26442-1-o-takashi@sakamocchi.jp (mailing list archive) |
|---|---|
| Headers | show |
| Series | ALSA: firewire-motu: media clock recovery for sph-aware devices | expand |
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
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(-)