Popping noise on analog output (solved)

[doveman]

Doesn't look like it's ready to use yet. http://forum.stmlabs.com/showthread.php?tid=1052

Apart from the very high CPU usage when playing audio, it seems the a/v sync is off and it tends to reboot when switching to the next song in the queue!

The cheap PCM2704 http://www.aliexpress.com/store/product ... 55749.html also only supports 2.0 in, so wouldn't help with offloading the decoding of DTS (or other multi-channel tracks). That's something I could live with though if it wasn't for the other issues.

[ski522]

Apart from the very high CPU usage when playing audio, it seems the a/v sync is off and it tends to reboot when switching to the next song in the queue!

The cheap PCM2704 http://www.aliexpress.com/store/product ... 55749.html also only supports 2.0 in, so wouldn't help with offloading the decoding of DTS (or other multi-channel tracks). That's something I could live with though if it wasn't for the other issues.

High CPU in XBMC only, I'm running MPD for music and my CPU runs at about 4%-5%. As for video that's another problem since omxplayer doesn't support direct interface into alsa and thus you have to use pulse to intercept the sound...essentially adding another layer onto sound which on Pi's CPU is a problem.

If you're only interested in music you can beat the PCM2704 card, but video is another story.

[doveman]

Yeah, I'm using XBMC and am looking for a solution for both music and video, which doesn't appear to be available yet.

[dom]

Or could the firmware be changed to enable a cmdline.txt switch to leave the PWM on all the time?

This is a frequent request, but obviously if it were that easy, it would have been done months ago.
In fact I have a shelved changelist from about 6 months ago that does this. Unfortunately there is little improvement.

There are a number of problems. First audioplus (the audio output library on GPU) is a complex beast. There is a large circular dma buffer containing audio to ouput.
There may be multiple clients writing to this buffer, all with different sampling rates, numbers of channels, bits per sample, and it all gets resampled and mixed on the fly just ahead of the dma read pointer.

It wasn't designed for the PWM output on Pi, so there is another stage of reading the signed 32-bit quantities, and converting to 12-bit unsigned values, again (from ISR) just before the DMA read pointer.

Now, audioplus expects to be able to be able to halt and resume the DMA. With most hardware that maintains the last sample value output, but the PWM perhiperal (in 12 bit mode) drops to 0 when this happens
(note: silence is a mid point 0x400, so dropping to zero is a big discontinuity causing a pop).

This halting of dma occurs for a number of reasons, including pausing the stream, underrun, stopping the stream, and these all cause pops.

The underrun is the most common problem. Running the ARM 100% busy (e.g. MAME not quite keeping up) will constantly underflow, which is unavaoidable, but every underflow produces a pop.
Also omxplayer initially starts the audio_render component before submitting any audio, so until the audio buffer has filled, it is constantly underflowing (producing a longer pop than, say, aplay).
xbmc does this too (but not quite so badly).

There are other operations that cause popping. Audioplus has a flush operation that memsets the output buffer to zero. This is normally safe(ish), but with PWM this also replaces the samples nearest the DMA read pointer which are 0x400 for silence with zero, again popping).

Avoiding ever halting the DMA is the solution to the pops, but it changes the behaviour of the clients of audioplus.
e.g. OpenMAX typically has 100ms of audio queued. It expects to be able to pause the audio and video output and have it stop immediately. When play is resumed that 100ms will come out.
I need to experiment with allowing the 100ms to be played after the pause, rather than after the resume, and see if that is acceptable, and doesn't introduce audio sync issues.

So, the good news is, on my fourth or fifth attempt and solving the pops, I have a better understanding of exactly where the pops are coming from. I have some hacked code on my machine that is sounding a lot cleaner, and have some confidence that things will improve.

[obcd]

Thanks for passing and clearing things up dom.
I asked in the Power Users section if it would be possible to connect a codec to P5 without changes to the firmware, but didn't got an answer yet.
It could solve the issue without the need to give up an usb port, and it could provide true 16 bit quality.
The analog supply of the codec could be filtered to improve spurious background noise problems.
I was under the impression that the IIS lines were programmed to function as generic gpio.
I was curious if they could be reprogrammed to be used as IIS?

[mahjongg]

0.59V is close to the conducting voltage of the diode.

True, but this value is only reached during the extreme peaks of the audio, if the audio is overdriven to a point that 0,59V is reached on a regular basis the extreme clipping that would occur would be much worse than whatever effect the diodes would have.

[redhawk]

Considering how weak the Pi on-board audio is I would have to say it's highly unlikely the diodes would be capable of conducting.
Also silicon diode don't simply conduct at 0.6v and then not conduct at 0.59v there is a gradual decrease in resistance as the voltage increases at the forward bias point, so if anything the audio would have a limiting effect rather than hard clipping.

Richard S.

[mahjongg]

No obviously the conductivity follows a curve, as any diode does, but this (double) diode typically doesn't conduct already at 0.6V!
The circuit will put out several mA (7.8mA at most) and a BAV99 diode has a typical curve so that at 1mA flowing through it will drop at least 0.71V, and so at 0.6 Volt it will conduct far less than 1mA, guestimating from the curve in the datasheet I would say its less than 0.01 mA.
I remain convinced that in the current circuit the diodes have no discernible influence on audio quality whatsoever!

Also, even when the diode starts conducting at 0.59V it would only improve audio quality, as soft clipping is a lot less harsh sounding than hard clipping.

[obcd]

It's basically 0.6 and 0.7V (not 6 or 7)
IMHO, a small board with a codec chip would be the perfect solution for those who intend to use the Pi analog output for more than beeps and blips. I know you can buy cheap usb dongles, but they use up one of your usb ports.

[sej7278]

It's basically 0.6 and 0.7V (not 6 or 7)
IMHO, a small board with a codec chip would be the perfect solution for those who intend to use the Pi analog output for more than beeps and blips. I know you can buy cheap usb dongles, but they use up one of your usb ports.

i've got the pcm2704 and i still get a squeak at the beginning of each music track, and humming from the wifi dongle. usb dacs are not the magic answer people on here seem to say they are.

[mahjongg]

It's basically 0.6 and 0.7V (not 6 or 7)

Ooops, obviously you are right, its now corrected.

[ski522]

It's basically 0.6 and 0.7V (not 6 or 7)
IMHO, a small board with a codec chip would be the perfect solution for those who intend to use the Pi analog output for more than beeps and blips. I know you can buy cheap usb dongles, but they use up one of your usb ports.

i've got the pcm2704 and i still get a squeak at the beginning of each music track, and humming from the wifi dongle. usb dacs are not the magic answer people on here seem to say they are.

Thought you already mentioned that the problem was from you're wi-fi dongle and not the PCM2704 usb card? Otherwise there was another thread on the forum in which the person discovered it was their wi-fi dongle causing some of their sound problems.

[sej7278]

Thought you already mentioned that the problem was from you're wi-fi dongle and not the PCM2704 usb card? Otherwise there was another thread on the forum in which the person discovered it was their wi-fi dongle causing some of their sound problems.

the wifi dongle causes my constant clicking noise (well i guess that's a bug in the usb subsystem) but the pcm2704 still doesn't fix the squeaking noise at the beginning of every track.

[doveman]

That must be something else, as I get a popping/thumping noise at the start/skip/pause, not a squeaking noise. Maybe the popping noise is masking it though and once that's eliminated by using the USB soundcard the squeaking is audible, or maybe that only happens when using the USB soundcard.

[dom]

So, the good news is, on my fourth or fifth attempt and solving the pops, I have a better understanding of exactly where the pops are coming from. I have some hacked code on my machine that is sounding a lot cleaner, and have some confidence that things will improve.

I've pushed out an updated firmware that should improve pops. rpi-update to get it.
ALSA and XBMC are both improved in the cases I've tested. omxplayer is noisy at the start, but that is a bug in omxplayer that I'll investigate later.

Please update and report what is better and what still has problems.

[doveman]

Cool. I'm not sure what rpi-update is but I'm sure someone will have a OE or Raspbmc build with your new firmware soon.

I'm interested in what you've done to improve things, if you feel like sharing

[sej7278]

Cool. I'm not sure what rpi-update is but I'm sure someone will have a OE or Raspbmc build with your new firmware soon.

https://github.com/Hexxeh/rpi-update

I'm interested in what you've done to improve things, if you feel like sharing

https://github.com/Hexxeh/rpi-firmware/ ... b87359517e

seems to have reduced the squeaking i'm seeing with the pcm2704 usb dac between tracks too, could be a coincidence or to do with the gpu_mem=16 split i'm now using.

[doveman]

https://github.com/Hexxeh/rpi-update

Thanks.

https://github.com/Hexxeh/rpi-firmware/ ... b87359517e

That just seems to list the files that have been modified, which doesn't mean much to me. I'm more interested in whether the modifications leave the PWM on all the time or what other mods have been made to improve the audio.

[dom]

That just seems to list the files that have been modified, which doesn't mean much to me. I'm more interested in whether the modifications leave the PWM on all the time or what other mods have been made to improve the audio.

The changes are things discussed in my post a few posts back.

It is a gpu firmware only (*) change, so doesn't affect the alsa driver.
There are now two config options, force_pwm_open (default enabled) and force_hmdi_open (default disabled).
Note: you are not expected to change these from their defaults, and the non-default states are not well tested, and are only there to help disagnosing problems.

With force_pwm_open enabled, it will be disabled from boot, but after first use, it will remain open indefinitely. You will hear a slight click on first use.
There is a small cost in power/gpu cycles/memory bandwidth for keeping audio enabled, but in practice I think this will be unnoticable.

As discussed in earlier post, just leaving the analogue audio enabled doesn't stop the popping. There are a number of other operations that provoke pops.
Pause/unpause is the most awkward one. We can't pause audio output without a glitch. So, I've changed the semantics of a pause so samples continue playing after the pause, rather than being blocked until after the resume.
If the latency is low (it's typically 100ms), this isn't too noticable, but it could have implications in some use cases.

The force_hmdi_open is less intrusive, and just keeps the hdmi open, without changing pause/flush behaviour. It could be useful if your hdmi device takes a long time to detect the audio, and you currently lose the first second of audio.
It is not expected to be useful to most, so is disabled by default.

(*) I did also make a slight change to alsa driver. espeak chooses a buffer size that is too low to avoid underruns, so I've made the alsa driver advertise a larger miniumum buffer size which improved the audio quality for espeak.

The behaviour of USB sounds cards shouldn't be affected.

[redhawk]

Dom, how easy would it be to modify the audio drivers so the active state could be indicated via a GPIO pin??

I was thinking of implementing a muting circuit controlled via GPIO, something like when playback starts the GPIO output is 3.3v and the audio gets unmuted (with a circuit delay to avoid the "pop").
When audio has finished the GPIO output goes back to 0v (the driver provides a short delay and then the PWM engine is turned off).

I have no idea how to hack the audio drives for the Pi but I'm willing to give it a go if I knew where to start.

Richard S.

[dom]

I was thinking of implementing a muting circuit controlled via GPIO, something like when playback starts the GPIO output is 3.3v and the audio gets unmuted (with a circuit delay to avoid the "pop").
When audio has finished the GPIO output goes back to 0v (the driver provides a short delay and then the PWM engine is turned off).

Considering this requires a hardware mod (and so almost no-one will benefit), it's not worth any significant time.
And I don't think it is trivial. As explained, there are lots of reasons for pops, and the simple one (which this can fix) is already fixed in the latest firmware.

The more complicated ones, such as pausing the dma output (and wanting to maintain the existing output level) probably won't be fixed by this scheme.

[doveman]

The changes are things discussed in my post a few posts back.

It is a gpu firmware only (*) change, so doesn't affect the alsa driver.
There are now two config options, force_pwm_open (default enabled) and force_hmdi_open (default disabled).
Note: you are not expected to change these from their defaults, and the non-default states are not well tested, and are only there to help disagnosing problems.

Excellent, thanks for the explanation.

[doveman]

I've tested your new firmware with rbej's OpenElec build and I'm happy to say the popping problem is gone. Great job dom

I have another problem with audio levels however. I haven't tested enough previously to know if it's always been like this or not. When I play Movies it's very quiet but when I stream from iPlayer it's quite loud/normal, although that varies as Mayday episode 1 is loud/normal whilst The Sorcerers Apprentice is very quiet like my Movies. This is a film rather than a TV Programme so maybe that's relevant but I'm not sure if iPlayer content is all stereo or if some things have multi-channel audio. I tried enabling the Boost Volume on Downmix option but that hasn't made any difference. Playing Recorded TV (pretty sure it's only stereo as it's recorded from UK Freeview) is quiet as well. I know the RPi analog output is relatively quiet anyway but if one programme can be loud enough, I'd think everything else should be able to reach the same volume.

[dom]

I have another problem with audio levels however. I haven't tested enough previously to know if it's always been like this or not. When I play Movies it's very quiet but when I stream from iPlayer it's quite loud/normal, although that varies as Mayday episode 1 is loud/normal whilst The Sorcerers Apprentice is very quiet like my Movies. This is a film rather than a TV Programme so maybe that's relevant but I'm not sure if iPlayer content is all stereo or if some things have multi-channel audio. I tried enabling the Boost Volume on Downmix option but that hasn't made any difference. Playing Recorded TV (pretty sure it's only stereo as it's recorded from UK Freeview) is quiet as well. I know the RPi analog output is relatively quiet anyway but if one programme can be loud enough, I'd think everything else should be able to reach the same volume.

I am aware of iPlayer being louder that most other video content. It's not just analogue audio - it's the same on hdmi.
I'm pretty sure it's also the same on my Popcorn Hour media player.
I have a feeling that iPlayer normalises their audio to ensure it is full range, whereas most other content doesn't, so appears quieter (although nothing more than a feeling).

[doveman]

I am aware of iPlayer being louder that most other video content. It's not just analogue audio - it's the same on hdmi.
I'm pretty sure it's also the same on my Popcorn Hour media player.
I have a feeling that iPlayer normalises their audio to ensure it is full range, whereas most other content doesn't, so appears quieter (although nothing more than a feeling).

Actually, now that you mention it I recall finding iPlayer quite loud when I used it in Mediaportal. Perhaps they only normalise their own programmes and not films that they show, which would explain why The Sorcerer's Apprentice was quiet.

I wonder if there's any way to make XBMC/RPi normalise everything else then, so that I don't have to crank up the volume on my TV/Amp for it and then risk getting deafened when using iPlayer or another piece of equipment?