snd_dice: Clicking artifacts with TC StudioKonnekt 48

[Scott Bahling]

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