All of lore.kernel.org
 help / color / mirror / Atom feed
From: Takashi Sakamoto <o-takashi@sakamocchi.jp>
To: tiwai@suse.de
Cc: alsa-devel@alsa-project.org, clemens@ladisch.de
Subject: [PATCH 5/6] ALSA: firewire-tascam: perform sequence replay for media clock recovery
Date: Mon, 31 May 2021 11:51:02 +0900	[thread overview]
Message-ID: <20210531025103.17880-6-o-takashi@sakamocchi.jp> (raw)
In-Reply-To: <20210531025103.17880-1-o-takashi@sakamocchi.jp>

This commit takes ALSA firewire-tascam driver to perform sequence replay
for media clock recovery.

The protocol specific to Tascam FireWire series is not compliant to
IEC 61883-1/6 in terms of syt field of CIP. The protocol doesn't use
presentation time in received CIP for playback timing. The sequence of
the number of data blocks per packet is important for media clock
recovery.

Although the devices in Tascam FireWire series transfer packets
regardless of receiving packets, the tx packets includes no events
in the beginning of streaming. It takes so long to multiplex any event
into the packet after receiving the sequence of packets. As long as I
experienced, it takes several thousands of isochronous cycle. Furthermore,
just after changing sampling transmission frequency, it stops multiplexing
event at once, then starts multiplexing again.

The sequence replay is tested with below models:
 * FW-1884
 * FW-1804
 * FW-1082

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
---
 sound/firewire/tascam/tascam-stream.c | 21 +++++++++++++++++++--
 sound/firewire/tascam/tascam.h        |  1 +
 2 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/sound/firewire/tascam/tascam-stream.c b/sound/firewire/tascam/tascam-stream.c
index 4811b60e5823..53e094cc411f 100644
--- a/sound/firewire/tascam/tascam-stream.c
+++ b/sound/firewire/tascam/tascam-stream.c
@@ -11,7 +11,7 @@
 #define CLOCK_STATUS_MASK      0xffff0000
 #define CLOCK_CONFIG_MASK      0x0000ffff
 
-#define READY_TIMEOUT_MS	500
+#define READY_TIMEOUT_MS	4000
 
 static int get_clock(struct snd_tscm *tscm, u32 *data)
 {
@@ -423,6 +423,8 @@ int snd_tscm_stream_reserve_duplex(struct snd_tscm *tscm, unsigned int rate,
 			fw_iso_resources_free(&tscm->rx_resources);
 			return err;
 		}
+
+		tscm->need_long_tx_init_skip = (rate != curr_rate);
 	}
 
 	return 0;
@@ -454,6 +456,7 @@ int snd_tscm_stream_start_duplex(struct snd_tscm *tscm, unsigned int rate)
 
 	if (!amdtp_stream_running(&tscm->rx_stream)) {
 		int spd = fw_parent_device(tscm->unit)->max_speed;
+		unsigned int tx_init_skip_cycles;
 
 		err = set_stream_formats(tscm, rate);
 		if (err < 0)
@@ -473,7 +476,19 @@ int snd_tscm_stream_start_duplex(struct snd_tscm *tscm, unsigned int rate)
 		if (err < 0)
 			goto error;
 
-		err = amdtp_domain_start(&tscm->domain, 0, false, false);
+		if (tscm->need_long_tx_init_skip)
+			tx_init_skip_cycles = 16000;
+		else
+			tx_init_skip_cycles = 0;
+
+		// MEMO: Just after starting packet streaming, it transfers packets without any
+		// event. Enough after receiving the sequence of packets, it multiplexes events into
+		// the packet. However, just after changing sampling transfer frequency, it stops
+		// multiplexing during packet transmission. Enough after, it restarts multiplexing
+		// again. The device ignores presentation time expressed by the value of syt field
+		// of CIP header in received packets. The sequence of the number of data blocks per
+		// packet is important for media clock recovery.
+		err = amdtp_domain_start(&tscm->domain, tx_init_skip_cycles, true, true);
 		if (err < 0)
 			return err;
 
@@ -499,6 +514,8 @@ void snd_tscm_stream_stop_duplex(struct snd_tscm *tscm)
 
 		fw_iso_resources_free(&tscm->tx_resources);
 		fw_iso_resources_free(&tscm->rx_resources);
+
+		tscm->need_long_tx_init_skip = false;
 	}
 }
 
diff --git a/sound/firewire/tascam/tascam.h b/sound/firewire/tascam/tascam.h
index 78b7a08986a1..28dad4eae9c9 100644
--- a/sound/firewire/tascam/tascam.h
+++ b/sound/firewire/tascam/tascam.h
@@ -99,6 +99,7 @@ struct snd_tscm {
 	unsigned int push_pos;
 
 	struct amdtp_domain domain;
+	bool need_long_tx_init_skip;
 };
 
 #define TSCM_ADDR_BASE			0xffff00000000ull
-- 
2.27.0


  parent reply	other threads:[~2021-05-31  2:54 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-31  2:50 [PATCH 0/6] ALSA: firewire: media clock recovery for syt-unaware devices Takashi Sakamoto
2021-05-31  2:50 ` [PATCH 1/6] ALSA: fireworks: delete SYTMATCH clock source Takashi Sakamoto
2021-05-31  2:50 ` [PATCH 2/6] ALSA: fireworks: perform sequence replay for media clock recovery Takashi Sakamoto
2021-05-31  2:51 ` [PATCH 3/6] ALSA: oxfw: " Takashi Sakamoto
2021-05-31  2:51 ` [PATCH 4/6] ALSA: firewire-digi00x: " Takashi Sakamoto
2021-05-31  2:51 ` Takashi Sakamoto [this message]
2021-05-31  2:51 ` [PATCH 6/6] ALSA: fireface: " Takashi Sakamoto
2021-06-01  6:21 ` [PATCH 0/6] ALSA: firewire: media clock recovery for syt-unaware devices Takashi Iwai

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210531025103.17880-6-o-takashi@sakamocchi.jp \
    --to=o-takashi@sakamocchi.jp \
    --cc=alsa-devel@alsa-project.org \
    --cc=clemens@ladisch.de \
    --cc=tiwai@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.