Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Audio output "hiss" when should be silent #380

Closed
PeterOGB opened this issue Feb 27, 2015 · 18 comments
Closed

Audio output "hiss" when should be silent #380

PeterOGB opened this issue Feb 27, 2015 · 18 comments
Assignees

Comments

@PeterOGB
Copy link

@PeterOGB PeterOGB commented Feb 27, 2015

The on board audio (PWM to 3.5mm Jack) has started to produce a very noticeable level of "hiss" when it is open but being fed silence. Mostly reported on the forums as a ALSA problem but I have openMAX IL code that bypasses ALSA and has the same problem. I've only noticed it since upgrading to 2015-02-16 Raspbian but it may have been there longer. Douglas6 on the forums says "An easy way to produce the symptoms seems to be to install and run fluidsynth."

@P33M

This comment has been minimized.

Copy link

@P33M P33M commented Feb 27, 2015

Is the hiss still present if you add

disable_audio_dither=1 to config.txt?

@PeterOGB

This comment has been minimized.

Copy link
Author

@PeterOGB PeterOGB commented Feb 27, 2015

Yes that seems to have fixed it :-) Should I recommend that as the fix on the forum or is there more to be done to find a better fix ? I assume there is a down side to disabling the dither ?

@P33M

This comment has been minimized.

Copy link

@P33M P33M commented Feb 27, 2015

Disabling it means that the noise floor becomes a function of the input signal. In effect you get slightly more distortion without dither than with.

@PeterOGB

This comment has been minimized.

Copy link
Author

@PeterOGB PeterOGB commented Feb 27, 2015

Ok, but is it the right solution in situations where silence is going to be produced by the application ?

@popcornmix

This comment has been minimized.

Copy link
Contributor

@popcornmix popcornmix commented Feb 27, 2015

The dither is added as a fractional bit (out of the 11 bits of PWM) in range [0..1).
As long as source is outputting silence as zero (or zeros outsize of most significant 11 bits) then the behaviour with or without dither should be the same.
If silence is constant, but non zero, you will hear the dither.

Are you sure the silence being output is zero?

@PeterOGB

This comment has been minimized.

Copy link
Author

@PeterOGB PeterOGB commented Feb 27, 2015

I'm going to say "yes" as the hiss only starts up after the recorded samples have stoppped. (My app has short sound effects for button presses etc). When no effects are playing the output buffer is all zeros. And to be 100% sure I just changed my code to write all zeros into the sample buffer just before the ALSA write is called.... And HISS is still present when dither is enabled.

PS: Problem is not present using HDMI or external USB sound card.
PPS: If you are coming to the Party this weekend I can show you the problem,

@P33M

This comment has been minimized.

Copy link

@P33M P33M commented Mar 1, 2015

You say you already have code that exhibits this - can you post (or gist) this?

@PeterOGB

This comment has been minimized.

Copy link
Author

@PeterOGB PeterOGB commented Mar 1, 2015

I do, but it is part of a large application. I'll chop out the sound stuff for you.

@PeterOGB

This comment has been minimized.

Copy link
Author

@PeterOGB PeterOGB commented Mar 4, 2015

I realised there is no need to write any code.... Just run this...
aplay -t raw -r 48000 -c 2 -f S16_LE /dev/zero

PeterO

@pelwell

This comment has been minimized.

Copy link
Contributor

@pelwell pelwell commented Mar 4, 2015

Neat, but I'm surprised it works - I thought /dev/null returned EOF, whereas /dev/zero returns zeroes.

@PeterOGB

This comment has been minimized.

Copy link
Author

@PeterOGB PeterOGB commented Mar 4, 2015

I typed /dev/null by mistake and I guess you got a notification before I changed it to /dev/zeros :-) Grrrr.... /dev/zero

@P33M

This comment has been minimized.

Copy link

@P33M P33M commented Mar 6, 2015

I can replicate the effect.

@Clay-Tron

This comment has been minimized.

Copy link

@Clay-Tron Clay-Tron commented Mar 8, 2015

Adding the line to disable audio dither seems to work great at silencing the hiss between programs, and fixes an issue with emulation station. However I'm continuing to find is that the hiss remains whilst music is playing. This can be noticed when running any of the python games provided with Raspbian.

@Clay-Tron

This comment has been minimized.

Copy link

@Clay-Tron Clay-Tron commented Mar 8, 2015

To be more specific there is no hiss on the 3.5mm audio line whilst sound is playing in emulators on Retro-Pie distribution, but there is whist sounds are played on Raspbian. There must be a configuration setting that differs between the two that breaks the sound quality in Raspbian. I see that retroarch manages the sound on the retro-pie distribution. Any ideas? Whilst I'm here a big, big thank you for solving the hiss during zero sound output!

@Uplink03

This comment has been minimized.

Copy link

@Uplink03 Uplink03 commented Jun 9, 2015

Disabling dither fixes the hiss for me on both the original Pi B and the Pi 2 (I don't have a Pi B+, but it should be like the Pi B, right?).

Can you please document this option on this page? It's not in there.

@Clay-Tron

This comment has been minimized.

Copy link

@Clay-Tron Clay-Tron commented Jun 10, 2015

Hi,

On the Pi 2 it fixes it on some distributions but not all. Initially it
presented as a background hiss whilst audio wasn't playing. Disabling the
dither stopped that effect. This fixed distributions like RetroPie which is
used to play emulated games, the audio there is now perfect via the 3.5mm
jack. On the other hand Rasbpian still suffers the hiss but only when audio
is being played, for example this can be seen when python games are played.
At the moment the problem is preventing the PI being used as a reliable
audio dedicated device.

I believe the issue is still software as it is differing between
distributions. Some will claim it is an inherent hardware problem due to
the 3.5mm jack being a line out, and not powerful enough to drive
headphones, however this is not the issue as I have tried it on various
different amplifiers and the noise still remains.

The issue needs someone with more Linux knowledge to understand what is
happening at the driver level between distributions.

Kind regards,

Clayton

On Wed, Jun 10, 2015 at 1:10 AM, Uplink03 notifications@github.com wrote:

Disabling dither fixes the hiss for me on both the original Pi B and the
Pi 2 (I don't have a Pi B+, but it should be like the Pi B, right?).

Can you please document this option on this page
https://contactmonkey.com/api/v1/tracker?cm_session=e1360a56-953e-4ed1-9161-933b6e936a22&cm_type=link&cm_link=c5925083-848d-4b7d-bfea-484beb332731&cm_destination=https://www.raspberrypi.org/documentation/configuration/config-txt.md?
It's not in there.


Reply to this email directly or view it on GitHub
https://contactmonkey.com/api/v1/tracker?cm_session=e1360a56-953e-4ed1-9161-933b6e936a22&cm_type=link&cm_link=f0710924-e6e8-4e93-b6c7-86b65269f12e&cm_destination=https://github.com/raspberrypi/firmware/issues/380#issuecomment-110436217
.

@SunayKa

This comment has been minimized.

Copy link

@SunayKa SunayKa commented Apr 28, 2017

I was facing this same issue and infact i did reinstall OS, finally I found that my issue was with servoblaster using as pwm, As servoblaster use PIN 18 which is used for 3.5 audio Jack also, using PCM flag --pcm i was able to get back my audio. Please find more detail on this site

https://leenabot.com/en/Driving-Servo-Motors-Servo-Blaster-for-Raspberry-Pi/

Hope this is helpful for others who are using servoblaster.

@P33M

This comment has been minimized.

Copy link

@P33M P33M commented May 15, 2017

The recommended config.txt option for high-quality audio from the 3.5mm jack is audio_pwm_mode=2. This enables the sigma-delta oversampled PWM with ~16-bit resolution.

@P33M P33M closed this May 15, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants
You can’t perform that action at this time.