@@ -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;
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> --- sound/firewire/bebob/bebob_stream.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-)