Noise at front of audio playback


50 posts   Page 1 of 2   1, 2
by tobie » Tue Jun 19, 2012 3:58 pm
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?
Posts: 11
Joined: Tue May 15, 2012 5:15 pm
by DirkS » Tue Jun 19, 2012 9:49 pm
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
Posts: 529
Joined: Tue Jun 19, 2012 9:46 pm
Location: Staffordshire, UK
by tobie » Wed Jun 20, 2012 11:28 am
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?
Posts: 11
Joined: Tue May 15, 2012 5:15 pm
by dom » Wed Jun 20, 2012 12:14 pm
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.
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 3992
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by tobie » Wed Jun 20, 2012 12:34 pm
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?
Posts: 11
Joined: Tue May 15, 2012 5:15 pm
by dom » Wed Jun 20, 2012 12:44 pm
tobie wrote: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.
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 3992
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by tobie » Wed Jun 20, 2012 3:28 pm
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.
Posts: 11
Joined: Tue May 15, 2012 5:15 pm
by gritz » Wed Jun 20, 2012 8:55 pm
@ 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)

Image

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:

Image

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).

Image

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.
Posts: 449
Joined: Sat Jan 28, 2012 2:33 am
by tobie » Fri Jun 22, 2012 10:49 am
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.
Attachments
RPi-audiojack-noisesound.jpg
RPi-audiojack-noisesound.jpg (57.42 KiB) Viewed 9971 times
Posts: 11
Joined: Tue May 15, 2012 5:15 pm
by gritz » Fri Jun 22, 2012 1:21 pm
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.
Posts: 449
Joined: Sat Jan 28, 2012 2:33 am
by rite » Sun Jun 24, 2012 9:15 am
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.
Posts: 1
Joined: Sun Jun 24, 2012 9:11 am
by dom » Sun Jun 24, 2012 10:43 pm
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.
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 3992
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by gritz » Mon Jun 25, 2012 1:05 am
dom wrote: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! :)
Posts: 449
Joined: Sat Jan 28, 2012 2:33 am
by tobie » Mon Jun 25, 2012 4:06 pm
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?
Posts: 11
Joined: Tue May 15, 2012 5:15 pm
by dom » Mon Jun 25, 2012 4:26 pm
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?
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 3992
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by tobie » Mon Jun 25, 2012 5:18 pm
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?
Posts: 11
Joined: Tue May 15, 2012 5:15 pm
by yeahbox » Mon Jun 25, 2012 10:28 pm
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 :)
Posts: 36
Joined: Sun May 27, 2012 10:35 pm
Location: Manchester, UK
by dom » Mon Jun 25, 2012 10:36 pm
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...
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 3992
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by gritz » Mon Jun 25, 2012 11:38 pm
dom wrote:If I play it with mplayer, it plays perfectly...


Any audible transients at start / end of playback?
Posts: 449
Joined: Sat Jan 28, 2012 2:33 am
by tobie » Tue Jun 26, 2012 8:40 am
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
Posts: 11
Joined: Tue May 15, 2012 5:15 pm
by anwe79 » Thu Jun 28, 2012 10:59 am
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.
Posts: 26
Joined: Sat Oct 08, 2011 10:30 pm
by johanj » Thu Jul 05, 2012 6:28 pm
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
Posts: 1
Joined: Thu Jul 05, 2012 6:20 pm
by Morpion » Fri Jul 06, 2012 7:46 am
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.
Posts: 1
Joined: Fri Jul 06, 2012 7:43 am
by juekr » Sat Jul 14, 2012 12:37 pm
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.
Posts: 6
Joined: Sat Jul 14, 2012 12:27 pm
by thoms3n » Sat Jul 14, 2012 2:08 pm
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
Posts: 1
Joined: Sat Jul 14, 2012 2:06 pm