Hi, On Thu, Feb 20, 2020 at 09:34:02PM +0100, Mathias Buhr wrote: > Hi, > > thanks to this group, both of my firewire interfaces are (almost) > working! Big thank you! > > While the TC Konnekt 24D works fine (playback and recording), the > StudioKonnekt 48 produces clicking artifacts during playback when using > snd_dice. This interface is working flawless on Windows and on a > Jack/FFADO combination. This artifact occurs in all use cases (alsa via > aplay, pulseaudio and jack) and does not seem to be in recorded streams. > After recording the playback with another device, it looks like the > level of the artifact is scaling with the signal and its interval is > interestingly 256ms. Is there anything I can do to further debug this > issue? Capture firewire packets? I would love to get this device fully > working. > > I'm using kernel version 5.5.4 but this issue has been there for a long > time. > > Thanks, > > Mathias Yes. ALSA dice driver brings the issue to your unit regardless of XRUNs. I can see this issue for recent 5 years (so long time). At present, ALSA dice driver is designed with the expectation that the devices performs 'clock-recovery' with timestamp in isochronous packets transmitted by the driver. The driver transfers PCM frames with timestamps as exactly the same number as configured sampling rate; e.g. 48,000 frames/sec or 44,096/44,104 frames/sec. However, many devices including yours don't perform it actually. For example, all of devices from TC Electronics don't perform it: - Konnekt 24D (Dice II STD ASIC) - Konnekt 8 (Dice II STD ASIC) - Konnkt Live (Dice II STD ASIC) - Studio Konnekt 48 (DICE II STD and DICE Mini ASICs) - Impact Twin (DICE II STD ASIC) - Desktop Konnekt 6 (DICE Mini ASIC) - Digital Konnekt 32 (DICE II STD) They work with sampling clock independent of the timestamp from driver. Thus it's not possible to synchronize multiple devices on the same IEEE 1394 bus (this is against the 'myth' that the devices can be synchronized for its internal sampling, but it's the fact). Instead, the device expects the driver to perform the 'clock-recovery' and transfer PCM frames as mostly the same as the calculated sampling rate. Even if the device is configured to handle 48,000 PCM frames per second, the device actually handles less or more PCM frames; e.g. 47,988, 47,992 or 48,008, 48,016. Unfortunately, current ALSA dice driver is not designed to work for it. In device internal, it handles surplus PCM frames or the lack of PCM frames for several seconds, then causes noisy sound I guess. The libffado2 is programmed for the 'clock-recovery'. On the other hand, it includes design mistake to aggregate several types of devices and give abstracted device to applications such as jackd. When considering the above design of actual hardware, the design is not good since each actual hardware works independent sampling clocks. Anyway, if you're satisfied to libffado2, it's better to continue to use it. ALSA IEC 61883-1/6 packet streaming engine is completely different from the one in libffado2. It's the most convenient way to avoid involvement in such difficult issue which developers have left for a long time. Regards Takashi Sakamoto
