summaryrefslogtreecommitdiff
path: root/sound/firewire/amdtp-stream.h
diff options
context:
space:
mode:
authorTakashi Sakamoto <o-takashi@sakamocchi.jp>2021-05-27 21:26:10 +0900
committerTakashi Iwai <tiwai@suse.de>2021-05-28 11:05:45 +0200
commit39c2649c71d87cda8af6547076ab7abec4b15b23 (patch)
tree52f41455150f73c5f2653e6439b12da2f474bf5b /sound/firewire/amdtp-stream.h
parentf9e5ecdfc2c2f2a87f4aa8aa3d0216016103d769 (diff)
downloadlinux-next-39c2649c71d87cda8af6547076ab7abec4b15b23.tar.gz
ALSA: firewire-lib: replay sequence of incoming packets for outgoing packets
ALSA IEC 61883-1/6 packet streaming engine uses pre-computed parameters ideal for nominal sampling transfer frequency (STF) to transfer packets to device since it was added 2011. As a result of user experience for a decade, it is clear that the sequence is not suitable to some actual devices. It takes the devices to generate noise, and causes any type of discontinuity in the series of packet transferred from the device. It's required for the engine to transfer packets according to effective STF. The effective STF is given by media clock recovered by the sequence of packet transferred from the target device. In the previous commit, the sequence is already cached. The media clock recovery can be achieved by analyzing the sequence. In technological world, many ideas are proposed for media clock recovery. However, the small part of them could be actually adopted in our case since floating point arithmetic is not mostly available in Linux kernel land. This commit adopts the simple way from them; sequence replay, which means that the sequence of parameters from incoming packet is used as is to transfer outgoing packets. The media clock is not computed internally, but the sequence of outgoing packet superficially looks to be generated by the media clock. The association between source and destination is decided when starting AMDTP domain. When the target device supports a pair of isochronous packet streams, the tx stream is source and the rx stream is destination. When it supports two pair of streams, each of tx stream is associated to corresponding rx stream in its order. When it supports less number of tx streams than rx streams, the fist tx stream is selected for all of rx streams. When it supports more tx streams than rx streams, the first tx packet is associated to the rx stream. As I noted in previous commit, the sequence of parameters from incoming packet is different between devices, time to time. It is worse idea to replay the sequence of parameters from a device for the sequence of packet to the other devices even if they are in the same category of device. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20210527122611.173711-3-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
Diffstat (limited to 'sound/firewire/amdtp-stream.h')
-rw-r--r--sound/firewire/amdtp-stream.h3
1 files changed, 3 insertions, 0 deletions
diff --git a/sound/firewire/amdtp-stream.h b/sound/firewire/amdtp-stream.h
index ddfb885b6113..61b6b5ae8b3b 100644
--- a/sound/firewire/amdtp-stream.h
+++ b/sound/firewire/amdtp-stream.h
@@ -166,6 +166,9 @@ struct amdtp_stream {
unsigned int data_block_state;
unsigned int syt_offset_state;
unsigned int last_syt_offset;
+
+ struct amdtp_stream *replay_target;
+ unsigned int cache_head;
} rx;
} ctx_data;