ALSA: bebob: perform sequence replay for media clock recovery

This commit takes ALSA bebob driver to perform sequence replay for media
clock recovery.

Many users have reported discontinuity of data block counter field of CIP
header in tx packet from the devices based on BeBoB ASICs. In the worst
case, the device corrupts not to respond to any transaction, then generate
bus-reset voluntarily for recovery. The sequence replay for media clock
recovery is expected to suppress most of the problems.

In the beginning of packet streaming, the device transfers NODATA packets
for a while, then multiplexes any event and syt information. ALSA
IEC 61883-1/6 packet streaming engine has implementation for it to drop
the initial NODATA packets. It starts sequence replay when detecting any
event multiplexed to tx packets.

The sequence replay is tested with below models:

 * Focusrite Saffire
 * Focusrite Saffire LE
 * Focusrite Saffire Pro 10 I/O
 * Focusrite Saffire Pro 26 I/O
 * M-Audio FireWire Solo
 * M-Audio FireWire Audiophile
 * M-Audio Ozonic
 * M-Audio FireWire 410
 * M-Audio FireWire 1814
 * Edirol FA-66
 * ESI Quatafire 610
 * Apogee Ensemble
 * Phonic Firefly 202
 * Behringer F-Control Audio 610

Unfortunately, below models doesn't generate sound. This seems regression
introduced recent few years:

 * Stanton Final Scratch ScratchAmp at middle sampling transfer frequency
 * Yamaha GO44
 * Yamaha GO46
 * Terratec Phase x24

As I reported, below model has quirk of discontinuity:

 * M-Audio ProFire Lightbridge

DM1000/DM1100 ASICs in BeBoB solution are known to have bugs at switch of
sampling transfer frequency between low/middle/high rates. The switch
generates the similar problems about which I mention in the above. Some
vendors customizes firmware so that the switch of frequency is done in
vendor-specific registers, then restrict users to switch the frequency.

For example of Focusrite Saffire Pro 10 i/o and 26 i/o, users allows to
switch the frequency within the three steps; e.g. 44.1/48.0 kHz are
available at low step. Between the steps, extra operation is required and
it always generates bus-reset.

Another example of Edirol FA-66, users are prohibited to switch the
frequency by software. It's done by hardware switch and power-off.

I note that the sequence replay is not a solution for the ASIC bugs. Users
need to disconnect the device corrupted by the bug, then reconnect it to
refresh state machine inner the ASIC.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210601081753.9191-4-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>

1 files changed, 9 insertions, 4 deletions

diff --git a/sound/firewire/bebob/bebob_stream.c b/sound/firewire/bebob/bebob_stream.c
index 47773ca97e46..470c2b70cbfa 100644
--- a/sound/firewire/bebob/bebob_stream.c
+++ b/sound/firewire/bebob/bebob_stream.c
@@ -649,10 +649,15 @@ int snd_bebob_stream_start_duplex(struct snd_bebob *bebob)
 		else
 			tx_init_skip_cycles = 16000;
 
-		// MEMO: In the early stage of packet streaming, the device transfers NODATA packets.
-		// After several hundred cycles, it begins to multiplex event into the packet with
-		// syt information.
-		err = amdtp_domain_start(&bebob->domain, tx_init_skip_cycles, false, false);
+		// MEMO: Some devices start packet transmission long enough after establishment of
+		// CMP connection. In the early stage of packet streaming, any device transfers
+		// NODATA packets. After several hundred cycles, it begins to multiplex event into
+		// the packet with adequate value of syt field in CIP header. Some devices are
+		// strictly to generate any discontinuity in the sequence of tx packet when they
+		// receives inadequate sequence of value in syt field of CIP header. In the case,
+		// the request to break CMP connection is often corrupted, then any transaction
+		// results in unrecoverable error, sometimes generate bus-reset.
+		err = amdtp_domain_start(&bebob->domain, tx_init_skip_cycles, true, false);
 		if (err < 0)
 			goto error;