0

Disabling power saving or auto-mute to avoid popping on audio start?

vanfanel

May 14, 2017 11:23

None

Follow

Hi there,

I have an Hifiberry DAC+ mounted on my Pi3.

The problem is that it produces a very noticeable poping sound when it starts playing audio from ANY program using the ALSA API (RetroArch, omxplayer, Scummvm...)

I have came to the conclussion that it only happens at start, so it may be related to power-saving features (the DAC is muted if no audio is being sent to it I guess). Is there a way to disable that so no popping is hear?

There should be no popping after the system initializes ALSA...

Some other drivers allow this, like the Intel HDA: the intel hda kernel module allows these parameters:

options snd_hda_intel power_save=0 power_save_controller=N

Is there something similar for the hifiberry kernel modules??

• Facebook
• Twitter
• LinkedIn

27 comments

• 0
  
  HiFiBerry team May 14, 2017 15:00

  Hi,

  Unfortunately there are no kernel-options like this.

  Best regards,
  Daniel

• 0
  
  vanfanel May 14, 2017 16:04

  @Daniel: could I somehow modify the kernel driver code and rebuild to test? I mean: can you point me in the right direction on what should I disable in the code to avoid this power-saving mode when no sound is played?

• 0
  
  HiFiBerry team May 14, 2017 17:33

  Hi,

  there is no flag that you can just set. Your application would need to send a constant stream of data to the chip. You can't simply hack this in the driver.

  Best regards,
  Daniel

• 0
  
  vanfanel May 14, 2017 18:21

  @Daniel: Yes, but there must be a piece of code that times out when no data is received or something like that. Maybe not a simple flag but doable anyway if I'm pointed in the right direction.

• 0
  
  HiFiBerry team May 14, 2017 18:24

  There is nothing that "times out". Feel free to look at the source code by yourself:

  https://github.com/raspberrypi/linux/blob/rpi-4.9.y/sound/soc/codecs/pcm512x.c

  Best regards,
  Daniel

• 0
  
  vanfanel May 14, 2017 18:32

  @Daniel: then what causes these poppings when an ALSA program starts? Sure you have noticed them.

• 0
  
  HiFiBerry team May 14, 2017 18:35

  No, I've never heard any pops. This might be a problem with the input stage of your amplifier.

  Best regards,
  Daniel

• 0
  
  HiFiBerry team May 14, 2017 18:36

  It's also possible that your amplifier has a power-saving feature and shuts down and input if no input signal is detected.

  Best regards,
  Daniel

• 0
  
  vanfanel May 14, 2017 18:50

  @Daniel: The pops can be heard without any amplifiers, with a simple RCA-to-jack cable and headphones. So that's not the cause I believe.

• 0
  
  HiFiBerry team May 14, 2017 19:28

  The output isn't designed to directly connect headphones. As I said before, I never heard any pops. If you think, there might be a hardware problem with your board, we can check it for you. 

  Best regards,
  Daniel

• 0
  
  llevola December 11, 2020 17:37

  I borrow this old thread, because I think my question is related to the same issue.

  So, as Daniel said, there seems to be no driver options for disabling auto-muting. Looking at PCM5122 datasheet, there is so-called "zero data detection" which lies inside the DAC chip. One workaround could be to program the DSP to always set the LSB in audio stream to keep DAC from muting itself. I might experiment with this myself at some point.
  
  But, PCM5122 has internal registers to control this muting behaviour. It can be disabled completed with ATMUTECTL bits or timeout chosen between 1024 and 512000 audio clock cycles (21 ms to ~10 sec at 48 kHz). I guess ideally options should be patched to the kernel module, which is not necessarily Hifiberry's responsibility. I am not competent enough to contribute either. Hope somebody would, since similar issue seem to annoy people around internet forums.

  From PCM1796 datasheet I understand that the same thing is called "infinite zero detect mute control", which seems to be disabled by default. Could some DAC2 HD owner test if they experience this "auto-mute popping"? In my case with DAC+DSP (PCM5122) I sometimes hear it when pausing tracks, but navigating Apple TV menus (from optical input) is a sure test case. *pop-BLEEP-pop*.
  
  My question to Hifiberry is if the boards are built so that it would be possible to send I2C commands to DAC chips? By passing the driver and setting the registers directly could be a workaround before kernel patch appears. Any related tips, where to look for, are appreciated. I am not that familiar with linux sound architecture.

• 0
  
  clivem December 11, 2020 19:05

  Barking up the wrong tree... You need to disable the dapm in the pcm512x driver. ie. the power management, (suspend/resume), to stop the chip being powered down.

• 0
  
  HiFiBerry team December 11, 2020 19:17

  In addition to the comment from @clivem a few more comments:
  
  1. The data sheet of a chip won't tell you something about the behavior of a full circuit. The DAC2HD uses an output buffer that's "always on".
  2. If you can write to a device via I2C has nothing to do with hardware. It's not that a board has to be "build so that...". IN general if a device driver uses an I2C device, access to it is blocked to user space programs. That's exactly how it should be, because altering the state of a device without the kernel knowing about this can result in all kinds of problems.
  However, it IS possible (even though I would not recommend it at all). 
  The "-f" option of i2cset allows you to write to any i2c address:
  https://manpages.debian.org/wheezy/i2c-tools/i2cset.8
  
  Note that in worst case this can result in kernel crashes as you will alter the state of registers without the kernel having any idea about it.

  Edited by HiFiBerry team December 11, 2020 19:22
• 0
  
  llevola December 11, 2020 19:42

  Thanks for input and explanations, both.

  Is the chip really powered down each fraction of a second when there is no sound coming in?

  On 1: No, of course not. But it told me that there is something that timeouts and that there is something that can be disabled, contra to your previous comments about feeding constant stream of data. Its just not in the driver, but inside the chip. I don’t know if ”zero data mute” was/is the issue, hence the wish to try disabling it.

  On 2: It has to do with it so much that I2C-lines have to be connected... I could have maybe written that explicitly. I don’t know if the kernel driver uses it normally or not. Having the theoretical possibility to try (risking kernel crash or whatever) gives at least chance to prove if the popping is due to zero data mute or not. Then one can move on to barking up some other tree.

• 0
  
  clivem December 11, 2020 20:01

  Is the chip really powered down each fraction of a second when there is no sound coming in?

  5 seconds, I think from memory between stopping playing and the power management kicking-in.

• 0
  
  llevola December 11, 2020 22:36

  5 seconds in far too long to coincide with this popping. ”On-pop”, the sound itself and ”off-pop” all happen within 1,0-1,5 sec. It’s much more like the 21 milliseconds of the zero data mute. I just don’t have an oscilloscope to prove anything.

  I found Allo MiniBoss in my electronics heap to compare. It had the same PCM5122 and same kind of ”pause/play pop”. But with it I hear also a second pop that’s ~5 seconds away. Disabling the automute or changing to delay longer than the default 21ms makes this ”pause/play pop” to occasionally have even louder crack.

  So I am not sure if either is the right tree to bark at.

  Edited by llevola December 11, 2020 23:54
• 0
  
  clivem December 12, 2020 11:25

  llevola, I have just re-read your first post to this thread where you are talking about "but navigating Apple TV menus (from optical input)"... Which board do you have? Is it the DAC+ DSP - I don't own that board, only the original DAC+ and DAC+Pro?

  If it is, the pop/click could be caused by whatever other chip they have on that board (WM8804????) that they are using to accept the optical input..... feeding the data to the PCM512x output. But I don't own that board, to be able to test.

• 0
  
  HiFiBerry team December 12, 2020 11:33

  @Ilevola: I also just noticed now that you're talking about a DAC+DSP. This has nothing to do at all with the PCM5122. There is no PCM5122 on the DAC+ DSP. You can change the behavior of the DAC+DSP to whatever you like by creating your own DSP program. Depending on what program you run on the DSP, it will behave differently as the full control on what data is sent to the output (and also muting) is handled by the DSP program.

  Edited by HiFiBerry team December 12, 2020 12:11
• 0
  
  HiFiBerry team December 12, 2020 11:33

  PS: clivem dop me a message at support@hifiberry.com if you want to play around with the DSP a bit...

• 0
  
  llevola December 12, 2020 12:33

  Well, my mistake, it’s PCM5102A on DAC+DSP. I have a DAC+ with PCM5122 and it pops the same as DAC+DSP and Allo MiniBoss. But based on what I wrote above on testing with mute setting on Allo, I feel like the zero data mute works as it should and is not responsible for the pops.
  
  clivem Optical input was just an example of case where I am consistenly and easily able to demonstrate the pops. It’s not the only one. The pops are independent of the software and board. I even happen to have Pimoroni Phat DAC, which has PCM5102A without a DSP, for example.

  Upon further searching I found these threads, which seem reasonably close to understanding the issue:
  https://raspberrypi.stackexchange.com/questions/74456/i2s-dac-device-support-kernel-drivers-and-noise-pop-crackle-on-playbac
  https://e2e.ti.com/support/audio/f/6/t/472960
  https://github.com/raspberrypi/linux/issues/2212
  It seems more universal issue than just PCM-family dacs or TI-products, and they suggest it has to do with how well chips behave when I2S clocks start/stop or, put another way, how Raspberry SoC’s linux drivers control the clocks.

  But how are the I2S clocks actually handled in the case when there’s the DSP between Raspberry and the DAC?

  Edited by llevola December 12, 2020 12:37
• 0
  
  clivem December 12, 2020 14:45

  llevola OK, this is going off at a tangent now.

  Upon further searching I found these threads, which seem reasonably close to understanding the issue:

  Yes, the BCM I2S code is a little cranky, but two of the things you reference end up talking about that crappy Adafruit MAX98357 implementation, which sure, doesn't like BCLK running when LRCLK is stopped, but and this is a huge BUT.... if Adafruit had bothered to implement the sdmode GPIO it could have been click/pop free. And as Matthias pointed out when the patch was submitted to upstream to try and change the BCM I2S behaviour, to work around it..... Changing behaviour (whether right or wrong, that other sound devices were developed against and depend on), is likely to result in "breaking" several other designs to make one work that IMHO, was implemented incorrectly to start with. For reference: https://lkml.org/lkml/2020/10/28/774

  I could waste the next twenty minutes explaining how the whole MUTE situation really works on PCM512x architecture. How it is a two stage, digital infinite atten ramp-down, followed by analogue mute..... How the AMCT register works..... How the inf zero detect or auto-mute is implementing just the analogue mute, that the charge pump on the output stage is powered down.... What effect the power management settings - (standby, power down) have in the real world...... BUT, we are not even talking about the PCM512x any more.....

  And as I have no idea about the DAC+ DSP board and what chip it is even using, nor do I have the time to look into it. (Daniel, I appreciate the offer, but I have zero time at the moment to play with tech). Sorry, I can't offer any other advice.

  Other than to suggest for the people who want a 100% guaranteed anti-click/pop method, you implement an external mute relay that shunts the sound card outputs to ground, controlled using gpio from the codec driver. This is what I do on every board I have connected to my main ($$$$$$$) system, where having learnt my lesson a long time ago, with a blown Lowther driver, courtesy of a crappy Pi DAC design, from a bunch of morons who who shall remain nameless, (IT WAS NOT A HIFIBERRY PRODUCT).....

  For the more DIY inclined you can probably find such a relay board on aliexpress for a couple of bucks, or 15 EURO will get you a more audiophool version from JLSounds using silent reed relays.....

  

  I'll post the driver mods for the 2x HiFiBerry products I still use, (DAC+Pro and DAC2HD), when I have time.

• 0
  
  HiFiBerry team December 12, 2020 15:10

  clivem: For the DAC+ Pro, we have a GPIO mute patch ready already that we're just testing with HiFiBerryOS. If this works well, we'll send a PR to the Pi kernel.
  (Background is that we use a GPIO mute pin on the Amp100 which is basically a DAC+ Pro and a power amplifier)

• 0
  
  llevola December 12, 2020 15:38

  clivem Let’s not go into chip architecture even if might enjoy the lecture 😄 Thanks for the efforts anyhow. I knew two of threads were more about MAX98357, but they provided pointers to the clock investigations anyway. The thread from TI support forum also showed similar spiking oscilloscope plots from PCM5122.

  External muting happened to be one solution suggested by TI themselves on the second link...

  Edited by llevola December 12, 2020 16:18
• 0
  
  clivem December 12, 2020 16:31

  And I wrote the DAC+DSP chip above

  Yes, you wrote that it is using PCM5102A for output, but that is just going to be a dumb implementation in hardware mode, or dual codec, slaved to the main codec, in alsa. It's what that PCM5102A is connected to, what is sending it data, that I would be good to know. What is the chip that provides the DSP and the optical input. It's that other chip that is going to be master, in control, and the PCM5102A just a dumb slave. I have no idea what that master chip is? Daniel?

  If I had implemented a design with the PCM5102A in hardware mode as output DAC, I would have connected pin 17 to a gpio so I could control the mute of it, especially in hardware mode. (Setting pin 17 low mutes - digital atten to infinity, followed by hard analogue mute). Whether they did or not, I have no idea. Not my design and I have no interest in critiquing HiFiBerry designs. It's not just about which chip is used, it's about how it's implemented, as part of the overall product.

• 0
  
  llevola December 12, 2020 20:02

  The DSP-chip on it is ADAU1451 and the program inside it is made by Hifiberry.

  I feel I have some entitlement for questioning/criticism since I pay for these products, which are supposed to be for sound-quality oriented people. But generally the Hifiberry products are excellent and just what I want with painless setup, lightweight OS, beautiful UI etc.

  Edited by llevola December 12, 2020 20:03
• 0
  
  clivem December 12, 2020 20:29

  The DSP-chip on it is ADAU1451

  Thanks for the info. I'm not familiar with it.

  I feel I have some entitlement for questioning/criticism

  I'm not trying to stop you. ;) I'm just saying that I'm not critiquing HiFiBerry designs.

  And praise where its due.... The fact that this is still usable, 6 and a half years after purchase, and sure, while it never was state of the art to begin with, but hey it does a decent enough job of playing music...... I'm sure in the 6 and a half years of use, I've had the 25 EUROS back that was invested into it, several times over! LOL

  

  

• 0
  
  clivem December 14, 2020 10:45

  https://drive.google.com/file/d/1WpP-YH1C9MSUeQV6BQiHST4zHTSKFAoe/view?usp=sharing