[IDEA] Controlling zero data detect feature in PCM51xx DAC's

[STUDI]

Applies to PCM51xx DAC chips.

A request to add variables for the driver to control the use of the features of these systems, i.e. the zero data detect function along with setting the activation delay of this function.

The DC chip detects silence in the downstream PCM data and activates the mute. Switching the mute on and off is accompanied by an audible click.

After installing Moode, selecting a driver adequate for the DAC on the PCM51xx, when switching between tracks with silence between them, there are two cracks. Changing the DAC board to one using a different chip, changing the driver for a different family of DAC chips and then returning to the DAC extension with PCM51xx and these glitches are gone.

I don't see any other reason than this zero data detect functionality in PCM51xx chips and, unfortunately, its default activation, and the use of the DAC extension with a third-party chip for some time causes a change in setting this functionality when initializing the DAC's work.

[Tim Curtis]

I'm not experiencing any glitches with Allo Boss PCM5122 DAC. Maybe it's the particular board u are using?

The chip option you mentioned would need to be exposed by the PCM5122 driver to ALSA and be a writable setting. It would show up in the output of the amixer command along with the other chip options.

In any case it's something that would need to be implemented in a kernel driver so you might want to  try posting in the Raspberry Pi Linux Git. https://github.com/raspberrypi/linux/issues

ETA: By the way I clicked on the link in your signature and got a virus warning :-0 so I had to disable the signature. Please check the link.

[STUDI]

I'm not experiencing any glitches with Allo Boss PCM5122 DAC. Maybe it's the particular board u are using?

I had two HAT extensions based on PCM5122 at my disposal, the first one is Hifiberry DAC+, the second one is an extension with switched crystals 49.152MHz / 45.1584MHz (driver is Allo Boss). The problem is not related to the masteclock switching as Hifiberry does not have any additional logic between the Raspberry PI system and the PCM5122 chip. These glitches only occur when the audio signal level becomes silence. If there is even minimal noise in the audio stream, there are no glitches, just like the next two tracks are actually a continuous recording with an artificially determined division into tracks (e.g. a concert). This clearly indicates the detection of zero data in the stream from the I2S bus. Two different extensions, the use of different drivers suitable for the PCM5122 chip does not change the situation. Only a change to another extension with a different chip and then return to the extension with the PCM5122 chip - regardless of whether it's Hifiberry or the latter. Since then, these glitches are gone. Two different extensions, including one very simple in terms of layout, exclude a hardware problem in the extension - the probability of the same failure, the same error in two different systems is practically close to zero.

It would show up in the output of the amixer command along with the other chip options.

But that means adding scripts that will set additional parameters. This has one drawback - a new version and a job to be done again. A GUI interface would be ideal, but depending on the DAC chip used, there would be a different dialog box.

OK, I understand the reference to the creators of the kernel, but it means that, unfortunately, the chance to solve this problem will be negligible, after all, something is playing there, so it's OK. (Similar treatment of audio playback is in the case of KODI as for me permanent regression from version 17).

It's a pity because the only thing left to do is use the USB DAC. In this case, there is no problem with glitches, the problem of extremely "dirty" masterclock in the I2S bus of the Raspberry Pi is also eliminated.



PS:  How to edit a signature? I don't see an option to edit it.