Crackly audio through 3.5mm jack

[philevans]

Hi,

I have been using Debian squeeze (also tried the Wheezy beta) to test the audio from the 3.5mm jack on my Pi. All I have been doing is modprobing the sound driver and using mpg123 (also tried other players), and all of them result in extremely crackly sound. When I tried playing audio in X, when I moved the mouse it went even worse and seemed to be stopping for a split second every time the cursor updated.

I have heard the ALSA drivers are still alpha - maybe that is why? Has anyone else experienced crackly sound through the 3.5mm jack? The best way to demonstrate this at the most basic level is the hello_audio demo program. For me the sound is not smooth, its very crackly.

Any ideas?

Thanks,
Phil.

[mahjongg]

Yes, the driver is still beta, and has some problems with not being able to fill the wave queue fast enough when the CPU takes long times returning to the driver, ("latency" problems) also the 3.5mm analog audio out supports only small loads, it should be connected to an amplifier, not directly drive a headset or such. Attempting to drive a low impedance will result in sound distortion.

[philevans]

Yeah I was running the jack through my amplifier and still got the same crackling. So is it right that even the hello_audio sample program should have the same issue seen as it is extremely low level, i.e. lower than ALSA, and AFAIK is simply sending out a sine wave?

[mahjongg]

Yes, the crackling is a software issue with the current low level audio driver.
Interestingly enough, I have heard rumours that the XMBC app doesn't have these audio problems, but maybe i'm wrong about that.

[drmarkb]

if your using xbmc your more than likely using hdmi audio, where the poor audio quality doesnt seem to be present (AFAIK).

Are there any plans on releasing a new ALSA driver in the near future?

[Lastb0isct]

Hey Guys. I'm getting the crackling audio while using hdmi video out and 3.5mm audio out. I have to use this because the TV i'm using doesn't have HDMI in(it's an old TV). I'm using OpenELEC XBMC and have noticed it all the time. It seems like it might be a software issue as you stated above. Hopefully this is resolved with the new, updated driver.

[migube]

Running latest Openelec XBMC and the crackle seems to be for mp3 playback on HDMI only, not Analog Jack.
Playing the same mp3 file but converted to .ac3 and passing through HDMI, letting the Amplifier do the job, gives perfect sound. So looks the mp3->Wave-> HDMI conversion introduces the crackles?


Then on Analog Jack I have to turn the Amplifier (Yamaha AV) much more, and on god listening strength white noise & some low distortion is audible.
I hope this is due to the driver & can be fixed ,not the AD HW converter ...

tx

[portets]

Then on Analog Jack I have to turn the Amplifier (Yamaha AV) much more, and on god listening strength white noise & some low distortion is audible.

Is the volume on your pi turned up all the way?

[Narf03]

anybody got any idea when the 3.5 audio will get fixed ?
can live with it but would be nice to use pi to play real nice music while browsing.

[portets]

some audio-related fixes just made it to the github repository. not sure if they fix these issues though.

run rpi-update if you have it.

[Narf03]

some audio-related fixes just made it to the github repository. not sure if they fix these issues though.

run rpi-update if you have it.

doing that everyday =)

[adenin]

I am also really disappointed at the audio quality coming from 3.5mm audio jack,
I wanted to use rpi for internet radio listening, I have denon amplifier, and use mpd package,
but sometimes ( I mean specific frequency of speech/music ) it is almost impossible to listen

I tried alsamixer - but it only allows to change volume - PCM value
I tried also different distros (arch, squeeze, raspbian, openelec) ..without success

Has anybody suceeded at improving audio quality? .. how?
..or USB audio card is the only way ?

thanks

[raha0007]

No you can use omxplayer to play the files it will be flawless and it has very low cpu usage.
It is hardware accelerated and it only clicks when you start and stop.
Its not the 3.5mm jack's fault its the ALSA drivers and omxplayer doesnt use those.


The only thing we need now is a GUI for omxplayer to play several files in a row.

[adenin]

No you can use omxplayer to play the files it will be flawless and it has very low cpu usage.
It is hardware accelerated and it only clicks when you start and stop.
Its not the 3.5mm jack's fault its the ALSA drivers and omxplayer doesnt use those.


The only thing we need now is a GUI for omxplayer to play several files in a row.

hm :/ it does not look like you described

omxplayer http://live.slovakradio.sk:8000/Litera_128.mp3
makes the same poor-quality audio
as
mpc add http://live.slovakradio.sk:8000/Litera_128.mp3
mpc play X
where X is index of the last added
( achieved using 'mpc playlist' )

[Powerphil]

Hi,
Has this been resolved? I'm trying to use the pi in my car connected to a 7" screen, and the only issue is the noise on the 3.5mm audio output. Is there a means of taking audio off the hdmi without a major investiment

[millerpuckette]

Hi all -

I did some testing on the analog output and found a couple of things: 1. somehow the audio
output is getting quantized to about 10 bits (perhps the dithering algorithm is only using 10-bit
numbers?) - this is causing audible harmonic distortion.

2. something is modulating the sound at a frequency that's suspiciously like 44100/512 (this at
a sample rate of 44100 Hz.) This could happen if the dithering algorithm isn't saving its state across
buffers of 512 sample frames (and am I inferring correctly that the dithering algo is indeed blocked
at 512 sample frames?)

I think both of these problems are likely to be inside the firmware where only the Pi team can see
the code. From an earlier thread I heard from Dom that the dithering algo is oversampling by a
factor of 2048 - it should be possible to get a much cleaner sound once the dithering algo is done
optimally. If Dom is listening I'm happy to offer whatever help I can from the limited view I have of
things

Miller (Pd developer and Pi user since last Friday

[MattOwnby]

Hi all -

I did some testing on the analog output and found a couple of things: 1. somehow the audio
output is getting quantized to about 10 bits (perhps the dithering algorithm is only using 10-bit
numbers?) - this is causing audible harmonic distortion.

2. something is modulating the sound at a frequency that's suspiciously like 44100/512 (this at
a sample rate of 44100 Hz.) This could happen if the dithering algorithm isn't saving its state across
buffers of 512 sample frames (and am I inferring correctly that the dithering algo is indeed blocked
at 512 sample frames?)

I think both of these problems are likely to be inside the firmware where only the Pi team can see
the code. From an earlier thread I heard from Dom that the dithering algo is oversampling by a
factor of 2048 - it should be possible to get a much cleaner sound once the dithering algo is done
optimally. If Dom is listening I'm happy to offer whatever help I can from the limited view I have of
things

Miller (Pd developer and Pi user since last Friday

I have done some tests too and discovered possibly the same thing you are seeing, Miller.

I generated a digital sine wave from scratch and then saved it as a .wav file. I then played it on the pi using omxplayer (and the analog 3.5mm output) and there is definitely some repeating "artifacts" present in the sound that should not be there. I may plug the output of my pi into my PC's sound card and get a sample to try to illustrate the differences between the sampled output and the original input if that would be helpful.

Here is a link to a .WAV file I just generated where you can clearly hear something not right when using "omxplayer".

http://www.rulecity.com/browsetmp/middle_c.zip

[dom]

I did some testing on the analog output and found a couple of things: 1. somehow the audio
output is getting quantized to about 10 bits (perhps the dithering algorithm is only using 10-bit
numbers?) - this is causing audible harmonic distortion.

PWM is limited to 100MHz @ 1bit. So at 48kHz you get ~11 bits.
We are actually not dithering at all with current code (if you are using the term in the way I understand it).

An earlier version of the code did add dithering noise (i.e. add a random +/0.5lsb to each sample). That's not currently in.
It didn't have a large benefit. I'm not sure I could tell the difference.

Although the GPU drives the audio from the ALSA driver, the arm does have access to the PWM device, and so it should be possible to drive it directly, if you think it is possible to get better quality out.
Might be worth writing a test program that drives PWM in a polled manner. Should be possible from user space with the mmap hack.

Obviously if you can demonstrate a way of getting better quality audio out, I'm sure I could replicate what you are doing on the GPU which can do things more efficiently.

[MattOwnby]

Although the GPU drives the audio from the ALSA driver, the arm does have access to the PWM device, and so it should be possible to drive it directly, if you think it is possible to get better quality out.
Might be worth writing a test program that drives PWM in a polled manner. Should be possible from user space with the mmap hack.

Are you saying that the hello_audio program uses the ALSA driver behind the scenes? (and thus it would be more efficient to use the ALSA driver than openmax calls?)

[millerpuckette]

Wow - mmap() - that takes me back to '91 - I'd be happy to give this a try if only
for nostalgia's sake! Is there a document (or sample code) that shows what address
the registers live at and how they're interpreted by the 1-bit DAC controller? Many
thanks. Just for a sneak preview, since you can only convert 11 bits, trick number
one is to take the low-order bits that got dropped and add them into the following
word. But there are various ways to improve on that in turn. And I still want to try to
figure out what's giving the 80 Hz modulation effect.

Phil - ALSA seems pretty stable on Pi and is the lowest-level (hence probably more
robust) path out. I get the crackles to and have to fool around with buffer sizes and
whatnot - this depends on what software you're using, and I don't know how mpg123
performms. Maybe the most likely to work is 'aplay' working on a PCM (uncompressed)
soundfile.

cheers
Miller

[dom]

Are you saying that the hello_audio program uses the ALSA driver behind the scenes? (and thus it would be more efficient to use the ALSA driver than openmax calls?)

No hello_audio doesn't use ALSA. They both use audioplus on GPU which can do mixing, resampling and output.
OpenMAX is probably more efficient, but there is not much in it.

[dom]

Wow - mmap() - that takes me back to '91 - I'd be happy to give this a try if only
for nostalgia's sake! Is there a document (or sample code) that shows what address
the registers live at and how they're interpreted by the 1-bit DAC controller? Many
thanks.

I think this has the info you need.
http://www.raspberrypi.org/wp-content/u ... herals.pdf

[MattOwnby]

Are you saying that the hello_audio program uses the ALSA driver behind the scenes? (and thus it would be more efficient to use the ALSA driver than openmax calls?)

No hello_audio doesn't use ALSA. They both use audioplus on GPU which can do mixing, resampling and output.
OpenMAX is probably more efficient, but there is not much in it.

Ok that is good that there is a resampler because of this new thread I just posted: http://www.raspberrypi.org/phpBB3/viewt ... 38&t=17127

[millerpuckette]

Wow - mmap() - that takes me back to '91 - I'd be happy to give this a try if only
for nostalgia's sake! Is there a document (or sample code) that shows what address
the registers live at and how they're interpreted by the 1-bit DAC controller? Many
thanks.

I think this has the info you need.
http://www.raspberrypi.org/wp-content/u ... herals.pdf

Thanks - this might take a while for me to figure out... stay tuned!
cheers
Miller

[millerpuckette]

Wow - mmap() - that takes me back to '91 - I'd be happy to give this a try if only
for nostalgia's sake! Is there a document (or sample code) that shows what address
the registers live at and how they're interpreted by the 1-bit DAC controller? Many
thanks.

I think this has the info you need.
http://www.raspberrypi.org/wp-content/u ... herals.pdf

Thanks - this might take a while for me to figure out... stay tuned!
cheers
Miller

OK... Please try my opus, http://crca.ucsd.edu/~msp/tmp/mmap-sinetest.c
-- it attempts to play a sinusoid for 10 seconds by flogging the PM control
registers. There are more detailed comments in the code, but in a nutshell, the
ALSA playback (in 2012-08-16-wheezy-raspbian) somehow modulates the output
so that you hear parasitic extra tones. Playing 440 Hz. there is a noticeable parasite
around F (MIDI 41, 87 Hz.) I think my sample code shows that the hardware is capable
of better. My guess about the parasitic tone is that there's a timing glitch every 512
samples but I haven't looked carefully for it yet.

That parasitic tone is the worst audio artifact in my opinion, but I think that
it will also be possible to further improve the audio by various (as yet unspecified)
bit-twiddling tricks -- I'll fool with this over the weekend if you seem interested (and
maybe regardless).

cheers
Miller