Hi Takashi, On Sat, 2020-02-22 at 10:25 +0900, Takashi Sakamoto wrote: > 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. I was just about to start a thread related to a very similar issue I'm seeing with my Tascam FW-1884. But in my case I'm only running one device/clock source. Could the clock-recovery issue also be affecting a single FW-1884 device? In my case I'm witnessing exactly one frame being dropped at a consistent interval of about 240ms at 96000 frames per second and 480ms at 48000 frames per second. > 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. I have not tried FFADO yet. I will see if the issue goes away with FFADO. Best Regards, Scott
