Noise at front of audio playback

hi, is anyone else experiencing noise with aplay and other audio applications?

This is 50-100ms white noise at the start of playback, after which the file is as expected.

I do not have the same problem following the hello_audio.bin example described here:
viewtopic.php?p=73345#p73345

So I suspect the artefact is related to the ALSA driver?

Yes, I've noticed the same when doing some tests using aplay.
Have not had the time to dive further into it, though.

Gr,
Dirk

A bit more detail here.

I'm hearing the same sound artefact during playback with speaker test and recorded sound:

Code: Select all

$ sudo aplay /usr/share/sounds/alsa/Front_Center.wav
...
$ speaker-test
...
$ arecord -d 10 -D plughw:1,0 test.wav
$ aplay test.wav

...
This behaviour is also present in the beta distribution of Wheezy:
http://www.raspberrypi.org/archives/1435

Any ideas of things I might try?

[dom]

I assume you are using analogue/headpones socket?
Yes, it is known about that it "pops" when opening and closing that interface.
I think we need to generate a ramp down to zero when switching off and a ramp up from zero when switching on, but I've not had a chance to investigate.

Yes this relates to speaker or headphones using the audio Jack.

Here's a recording of the output from aplay /usr/share/sounds/alsa/Front_Center.wav:

http://www.tobiekerridge.co.uk/pickup/Front_Center_Output.wav

When you say interface, is this hardware related? Is it possible that USB sound output will not have the same behaviour?

[dom]

When you say interface, is this hardware related? Is it possible that USB sound output will not have the same behaviour?

My understanding is that the HDMI, or USB audio wouldn't have this issue.

I'm not sure if the clicks associated with the device opening and closing and the noise from aplay (and other applications using ALSA) are the same behaviours.

I've recorded audio output from RPi headphone jack, one generated from "hello_audio.c", the other "hello_audio_output.wav" played using aplay.

Code: Select all

$ /opt/vc/src/hello_pi/hello_audio/hello_audio.bin

Audio output from hello_audio.bin can be downloaded here

Code: Select all

$ aplay /usr/share/sounds/alsa/Front_Center.wav

Output from Front_Center.wav can be downloaded here

The first has barely audible clicks at front and back, the other is pronounced noise at the front.

I will dig deeper and try other ways of pushing the audio.

@ tobie: I don't have a Pi to play with, but I took a look at your wavs in the Audacity freebie (because it makes for nice clear screenshots) and the clicks at the beginning and end of hello_audio_output.wav are due to D.C. offset: (the forum's chopped off a bit of the pics here)



It almost looks like the PWM is sat at 100% space (i.e. 0 Volts) until the start of the waveform, then there's a sudden transient. The sine starts at 0 degrees, so the wave should start at the horizontal centreline, but there's a sudden step that shouldn't be there (non-techie explanation!). This is a zoom of the start of the signal:



There's also a bit of a spike a few tens of milliseconds before the tone starts. Can't help with that.

When the waveform is cut off it stops just past 0 degrees (the centreline), but it then drops to -ve limit, suggesting that the PWM has hit 100% space again rather than ticking along at 50% (as it should under no signal conditions).



There's a similar transient at the end of Front_Center.wav, but as for the wideband noise at the start... Bug? Sorry I can't be more help.

Gritz that's a great bit of analysis on the wave.

I had a look at both samples together in Audacity, and the signatures you describe at the front and back look very similar. Perhaps because the sound you looked at (hello_audio_output.wav) is so 'full' compared to the voice sample (Front_Center.wav) the artefacts are not so noticeable during playback.

Following Dom's comments I'll take this as a hardware issue with the jack rather than a software issue with driving sound, and now focus on a USB solution for cleaner sound output.

Thanks both for your pointers.

Hi tobie, it is software related in the sense that the hardware is "dumb" (in the nicest possible way!) and needs to be told exactly what to do.

If I'm right (dangerous assumption...) and the PWM is being killed under no-audio to e.g. save a bit of power then a more civilised routine would be something like: detect "play" command -> ramp up PWM from 0% to 50% over at least several tens of milliseconds -> play audio -> ramp down. If control latency is unacceptable then the PWM engine needs to be kept running all the time that the audio application is open.

It's interesting that you found the same issue with different audio players and it does suggest that the issue is a bit further "under the hood". The Alsa thing still is in beta though, I think.

I have this exact problem with OpenElec. I am currently running audio from the RPi to the aux in on my amp, and the click at start and stop makes it pretty much unusable. Looking forward to a solution for this - USB audio alternative or driver fix.

[dom]

Okay, I've worked on this all weekend. Removing pops is surprisingly hard to do. But at least for my simple test cases, it seems much fixed.
Can you test? Changes pushed to rpi firmware github, and hexxeh's rpi-update repo.

Okay, I've worked on this all weekend. Removing pops is surprisingly hard to do. But at least for my simple test cases, it seems much fixed.
Can you test? Changes pushed to rpi firmware github, and hexxeh's rpi-update repo.

Thanks for putting in the hours! No Pi here to test with though.

Could you share any notes on what you did (in a form that a knuckle-dragging hardware guy could understand)?

Thanks!

Yup, that is a big improvement.

Here is the previous output, here is the output with Dom's recent changes, and here is the original file (differences in volume are due to settings on the input device used for the recording).

Without meaning to take anything away from Dom's work here, the difference between the improved version and the source sample is still noticeable. I'm sure current playback over the audio jack will be fine in many cases. My case is a voice synthesis app using Festival, with lots of short utterances. Speech is not a forgiving medium for even small glitches.

This final file is a recording of playback via the headphone jack with a small amount of silence added to the head of "Front_Center.wav". The silence is about 200ms, which is towards the end of the much less noticeable click. A short science allows time for the device to open, and for the front of the speech to then follow.

For now as an alternative to USB out I'm happy to do some kind of on-the-fly concatenation of audio files with a 'header of silence', or does this seem inelegant?

[dom]

That effect wasn't obvious with my test cases (silence and singing). It sounds like the "front" word is compressed.
My guess is that when opening, after receiving the the initial samples, I have to ramp up the PWM output to the level of the first sample. This takes ~100ms.
I'm guessing the ALSA driver is noticing that delay and discarding 100ms of audio near the start of the audio to catch ip, causing the "front" to become "frnt".

Rather than ramp up before the audio, I could fade it in, but you will still lose the start of the sound. Any better suggestions?

I don't know what to suggest, what do you think Gritz or Rite?

I've prepared a file that repeats the word "front", here's the source file and here's the output. Being able to compare the wave shape of the same sound might be useful?

Sounds like there are some buffers that needs to be cleared properly here. I don't know much about ALSA but there must be some sort of output buffer that samples are written to. This buffer must be cleared of all previous samples before it is filled with the new samples that we want to play. There should be no need to add extra time at the start of an already existing .wav file. This should be taken care of by the driver. Latency should be perfectly acceptable here, in Windows using MME drivers one can easily have 300ms of latency and if someone wants super low latency then ASIO drivers are the way to go (on windows)

As long as the audio stream is not synced to a video or another playback of some sort then latency shouldn't be any problems. So filling all output buffers with zeros and then start filling them with our samples is my suggestions. I wouldn't recommend to generate fade in and fade out (ramp up/down) because this would only put a patch over the real problem, which probably has something to do with the buffers not being cleared.

Maybe I should finally learn some more about ALSA. But there-are-so-many-projects-my-head-is-exploding

[dom]

I can confirm that the extra 100ms of ramping is not relevant. I still get the "Frnt" effect.
This is playing the wav file with aplay.
If I play it with mplayer, it plays perfectly...

If I play it with mplayer, it plays perfectly...

Any audible transients at start / end of playback?

Can confirm there's no noise with mplayer at the front or back, nor with sox:

Code: Select all

$ sudo apt-get install sox
$ sox /usr/share/sounds/alsa/Front_Center.wav -t alsa default

Dito, I tried alsaplayer which works (with some minor pops, but i don't hink i have that latest update), aplay seems to be broken.

Upgrading firmware did the trick. plopping is 99% gone

Thx for the work!

I used the Hexxeh upgrade tool:

Code: Select all

raspberrypi:/boot> sudo ldconfig
raspberrypi:/boot> cd
raspberrypi:~> sudo rpi-update
Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS
Performing self-update
Autodetecting memory split
Using ARM/GPU memory split of 192MB/64MB
Updating firmware (this will take a few minutes)
Using SoftFP libraries
217396170: vchiq_lib: Very incompatible VCHIQ library - cannot retrieve driver version
If no errors appeared, your firmware was successfully updated
A reboot is needed to activate the new firmware

Grtz

Johan

I've been trying to compile Pd-extended on my Pi - I'm getting there, but I've been experiencing not just this burst of noise at the start of audio files, but really intense distortion while running the audio test patches inside Pd (which admittedly compiled with errors, so it's not really surprising it's not working 100% yet.).

Looking forward to testing this fix out tonight. I'll post my results tonight.

Upon searching for a solution for exactly the same problem, I came across this discussion - but sadly the firmware update didn't do the trick for me. Being a Linux novice there's not much else for me to do than kindly ask the nice guys in is forum for help.

I'm using Debian Squeeze on the raspi and the noise occurs always when switching from one webradio stream to another with mpd/mpc. The raspi is connected to a pair of active speakers using the 3,5 mm audio jack.

Hi,

unfortunately the firmware update did not solve the problem for me. I'm using mpd on debian and have the plop while manually skiping tracks.

Thanks