Crackly audio through 3.5mm jack

[millerpuckette]

Yes, I'm aware that there is a factor of two/one bit that is missing. You can run:

Code: Select all

/opt/vc/bin/vcgencmd measure_clock pwm
frequency(25)=98304000

which is right. But if I set PWM_RANGE to 0x800 as I predicted I could, the audio comes out at half speed.
Can you run with 0x800?

Dig... http://crca.ucsd.edu/~msp/tmp/mmap-sinetest5.c

I turned off the 2 noxious REPEATFF bits and changed the REANGE to 0x800 -
same frequency, cleaner sound... compare

cc -DTEST_AMPLITUDE=0.005 -o mmap-sinetest4 mmap-sinetest4.c -lm && ./mmap-sinetest4

cc -DTEST_AMPLITUDE=0.005 -o mmap-sinetest5 mmap-sinetest5.c -lm && ./mmap-sinetest5

(amplitude turned way down low so errors are more audible.) I think it's 11 bits now.
(will stay off the emoticons since this web page turns them to ugly sprites, too bad...)

cheers
M

[dom]

I turned off the 2 noxious REPEATFF bits and changed the REANGE to 0x800 -
same frequency, cleaner sound... compare

cc -DTEST_AMPLITUDE=0.005 -o mmap-sinetest4 mmap-sinetest4.c -lm && ./mmap-sinetest4

cc -DTEST_AMPLITUDE=0.005 -o mmap-sinetest5 mmap-sinetest5.c -lm && ./mmap-sinetest5

(amplitude turned way down low so errors are more audible.) I think it's 11 bits now.
(will stay off the emoticons since this web page turns them to ugly sprites, too bad...)

Thanks. I can get the extra bit now. Unfortunately the "repeat last sample" bit helps with the popping, so without that, we get a louder click now.
Might need to see if I can leave the audio outputting silence when not in use.

[MattOwnby]

I've had the test program running for almost 24 hours now and the total samples processed is about to overflow the 32-bit limit so I figure I will stop it now but just thought I would post the "final" results for anyone curious.


Total elapsed time: 84754.080000
Total frames processed: 4068320256
Effective audio frequency: 48001.467965

[millerpuckette]

Thanks. I can get the extra bit now. Unfortunately the "repeat last sample" bit helps with the popping, so without that, we get a louder click now.
Might need to see if I can leave the audio outputting silence when not in use.

Something to try that might bot be too hard (but I'm talking out of my hat here) would
be to keep a buffer of zeros around and when you get the end-of-buffer interrupt before
anyone has queued another buffer, just schedule the zero-filled one and send a software
error back to the user.

It would be good if the buffer of zeros were short; maybe this would be a good moment to
see if it's possible to reduce the internal buffer size? I think it's now 512 and ideally should be
64 or less (so that projects like Henri & Villeret's analog synth emulator
(http://antoine.villeret.free.fr/?p=359) and my own project (Pure Data) can run with music-worthy
latencies (ideally 5-10 msec, say).

cheers
M

[dom]

@millerpuckette
Unfortunately it's all rather more complicated. Audioplus can handle multiple streams of ALSA + Openmax, all with different volumes/bit depths/sample rates.
It all gets mixed on the fly, just before being DMA'd out.

But, I've pushed out new firmware with the extra bit. Please test and comment on the quality.
I've got a new de-popping scheme for ALSA (OpenMAX will stil pop for now).

[salts633]

Your new de-popping scheme is working really well with squeezeslave, its not popping at the beginning or between tracks now, only if I end the process while there is music playing. I think the audio quality is better as well.

Also squeezeplayer (which has a resource intensive gui) is now working for the first time ever. It used to clip/pop so badly it was unusable. I have noticed that there have been lua library updates recently so this may have contributed to the improvement in squeezeplayer.

[millerpuckette]

@millerpuckette
Unfortunately it's all rather more complicated. Audioplus can handle multiple streams of ALSA + Openmax, all with different volumes/bit depths/sample rates.
It all gets mixed on the fly, just before being DMA'd out.

But, I've pushed out new firmware with the extra bit. Please test and comment on the quality.
I've got a new de-popping scheme for ALSA (OpenMAX will stil pop for now).

That works! I now am getting 11 bits of clean audio through aplay.

I do think I hear more of a pop at startup than I used to - am happy to trade that
off for the better audio. Also, somewhere in there the latency improved so that I can
now run shakily at 20 msec and fairly well at 25; this is consistent with a buffer
size of 512 (since one can probably never get below 2 buffers, 1024samples=20-ish
msec). A lower buffer size if possible would still be quite desirable. Folks are getting
10 msec through USB audio interfaces. But this would be icing on the cake I think.

I have to get ready for school now but in a couple of days, if you're still eager to go this
route, I can try out a simple dithering routine to see if the audio quality can be improved
any further.

cheers and thanks for all the work you've put in on this!
Miller

[dom]

Your new de-popping scheme is working really well with squeezeslave, its not popping at the beginning or between tracks now, only if I end the process while there is music playing. I think the audio quality is better as well.

Also squeezeplayer (which has a resource intensive gui) is now working for the first time ever. It used to clip/pop so badly it was unusable. I have noticed that there have been lua library updates recently so this may have contributed to the improvement in squeezeplayer.

Good to hear.

That works! I now am getting 11 bits of clean audio through aplay.

I do think I hear more of a pop at startup than I used to - am happy to trade that
off for the better audio. Also, somewhere in there the latency improved so that I can
now run shakily at 20 msec and fairly well at 25; this is consistent with a buffer
size of 512 (since one can probably never get below 2 buffers, 1024samples=20-ish
msec). A lower buffer size if possible would still be quite desirable. Folks are getting
10 msec through USB audio interfaces. But this would be icing on the cake I think.

I have to get ready for school now but in a couple of days, if you're still eager to go this
route, I can try out a simple dithering routine to see if the audio quality can be improved
any further.

Sure. I'd be interested to hear if you can get better quality out.

[thogue]

I dont know if a simple user report helps, but I have noticeable improvement after a firmware update.

old:
Aug 10 2012 17:19:18
version 330751 (release)
new:
Sep 18 2012 01:44:00
version 337601 (release)

Still hear some static on the 3.5.... static is very noticeable on my headphones, but on my desktop speakers I can't hear it. (figures shure vs logitech)

Hopefully I can be more of a help as I get more in touch with the community. I would really like to get cleanest possible audio out of my rPi.

Thanks for everyones hard work, first day with my rPi has been lots of fun.

[csgabe]

I still have popping or crackling sounds at beginning, end of videos & during seeking too(using omxplayer, debian wheezy, analog audio). I have latest firmware:

Sep 18 2012 01:45:27
Copyright (c) 2012 Broadcom
version 337601 (release)

This is the most annoying issue. Hope it gets fixed.

[thogue]

This is the most annoying issue. Hope it gets fixed.

Seems the general consensus was the noise while playing audio was evening more annoying. It seems that the fix made for overall quality actually made the "pop" louder.

hopefully with some time we will start tackling the "pop" I do agree it is annoying, but for me it can't be compared to the static I was hearing before the update was very painful on my ears.

Also, I am sure this expected but putting load on my Pi causes sound quality to go out the door (pop hiss while playing) . I am considering trying to install a stress application to test what kind of stress causes this. I assuming its just load combined lack of true timing source.

[truehl]

I'm running SqueezeSlave (armhf) with the new firmware and have no pops or cracks, just working fine, great sound and I'm very happy. I'm running a long term test from now to see if it's stable!

Great wokrk, thanks a lot!!!

[dom]

I still have popping or crackling sounds at beginning, end of videos & during seeking too(using omxplayer, debian wheezy, analog audio). I have latest firmware:
This is the most annoying issue. Hope it gets fixed.

Yes, the improved audio quality came at the price of more popping. I've managed to improve the ALSA pops, but haven't tackled the more complicated OpenMAX ones. It is on my list.

[sghazagh]

Did you add it to "/etc/rc.local" file? Or some other places?!

[Killerbee]

@millerpuckette
Unfortunately it's all rather more complicated. Audioplus can handle multiple streams of ALSA + Openmax, all with different volumes/bit depths/sample rates.
It all gets mixed on the fly, just before being DMA'd out.

But, I've pushed out new firmware with the extra bit. Please test and comment on the quality.
I've got a new de-popping scheme for ALSA (OpenMAX will stil pop for now).

@Dom

Have you ever been a HERO?
You are my HERO (for today). Thanks the popping is completely gone.
I am using ALSA with squeezeslave.

Thanks again.
KB

[migube]

hi guys,

The latest FW update (19 sept) says "Improved analogue audio Analogue audio quality has been improved."

I played a stream via shairport (not sure if alsa or not), and HDMI sound is good, Analog is slightly distorted still (no pops though).

Is it anyway linked to this thread ?:)
tx

[lines]

It seems like I get short (100ms) noises during playback since the upgrade, unregularly, about once every two minutes in average. I'm not sure, but i guess the playback time is changed a little after that glitch.
I use mplayer as player, it happens with both wave and mp3. I tried to increase the process priority of the mplayer to -5, this did not help.
could this be a problem with too short latency? how can i set latency higher to check?

in my application i can live with poor quality sound because the sound system is also of low quality and only for speech. Also additional latency is not a problem since the application is not interactive.

thanks!

[millerpuckette]

Sure. I'd be interested to hear if you can get better quality out.

Hi again and sorry for the slow followup... I tried the world's simplest dithering algo
(just keeing some low bits from each sample that were truncated in conversion and
adding them back into the next sample). You can hear the result by running the C
code here:

http://crca.ucsd.edu/~msp/tmp/mmap-sinetest6.c

I ran this as before with an amplitude of 0.005 and compared it to the previous one
(mmap-sinetest5.c) and I think it sounds less distorted. Strictly speaking this doesn't
improve the SNR any firther (actually I think it decreases it by about 3 dB) but it spreads
the error over the entire audible spectrum so that it's less audible, at least for these very
simple test tones.

The test program uses an additional 8 bits to manage the carry-over, but I think if word
length is limited in the hardware then 5-ish bits should do almost exactly the same thing.

If your ears tell you this will be an improvement and if you think it worth the time messing with
bit twiddlnig at that level, I'd certainly be eager to see something like this included.

thanks again for all the revs!
Miller

[jackokring]

Hi again and sorry for the slow followup... I tried the world's simplest dithering algo
(just keeing some low bits from each sample that were truncated in conversion and
adding them back into the next sample). You can hear the result by running the C
code here:

http://crca.ucsd.edu/~msp/tmp/mmap-sinetest6.c

I ran this as before with an amplitude of 0.005 and compared it to the previous one
(mmap-sinetest5.c) and I think it sounds less distorted. Strictly speaking this doesn't
improve the SNR any firther (actually I think it decreases it by about 3 dB) but it spreads
the error over the entire audible spectrum so that it's less audible, at least for these very
simple test tones.

The adding back in simple, but adding twice the amount back in would give better sound, as this is equivalent to a five sample sine ultrasonic at the sample rate times 2 (including the three zeros). I'm not sure what the PWM sample output rate is, but if it is much higher through oversampling then this ultrasonic noise is filtered. The extra dB of noise covers the whole spectrum, and so oversampling by 4 times with simple interpolation provides a 1/4 of the noise in the audio spectrum, and 3/4 fall into the ultrasonics.

[MattOwnby]

I finally was able to test these changes on my Pi and the new firmware resolves the issues I was seeing! Great job, Dom!

The important thing is, does the adjustment improve things. To my unmusical ears, then yes, I think it sounds better. And the 0.4% speed difference has gone.
I'd be interested if you can test the updated firmware (available through rpi-update) and comment on the change.

Excellent work!! I will test this as soon as I can. Unfortunately, I will not have physical access to my Raspberry Pi again for about 7 days (!!) so I cannot test until then. Hopefully some other people in the forum can test sooner than that because I am very curious to see the results.

[millerpuckette]

Hi again and sorry for the slow followup... I tried the world's simplest dithering algo
(just keeing some low bits from each sample that were truncated in conversion and
adding them back into the next sample). You can hear the result by running the C
code here:

http://crca.ucsd.edu/~msp/tmp/mmap-sinetest6.c

I ran this as before with an amplitude of 0.005 and compared it to the previous one
(mmap-sinetest5.c) and I think it sounds less distorted. Strictly speaking this doesn't
improve the SNR any firther (actually I think it decreases it by about 3 dB) but it spreads
the error over the entire audible spectrum so that it's less audible, at least for these very
simple test tones.

The adding back in simple, but adding twice the amount back in would give better sound, as this is equivalent to a five sample sine ultrasonic at the sample rate times 2 (including the three zeros). I'm not sure what the PWM sample output rate is, but if it is much higher through oversampling then this ultrasonic noise is filtered. The extra dB of noise covers the whole spectrum, and so oversampling by 4 times with simple interpolation provides a 1/4 of the noise in the audio spectrum, and 3/4 fall into the ultrasonics.

If I understand this, the suggestion is to synthesize a truncated "sinx" function at twice the
nominal sample rate to alias the error signal into the ultrasonic range. If this is correct that
wouldn't be possible in this context as the test code is only running at the nominal sample
rate and the hardware is using a fixed algorithm to upsample by 2048 times. It would be
possible to code a first-stage upsampler (by a factor of 2 say) as you suggest, feeding the
hardware 10 bit numbers at 96000 instead of 11 bit numbers at 48000, and in this way I think
the result could be further improved - but I hesitate to suggest getting into it so deeply,
particularly since I don't think I can test such an algorithm without first making (or being
given) a special version of the firmware to run at 96K/10 bit instead of 48K/11 bit.

cheers
Miller

[dom]

but I hesitate to suggest getting into it so deeply,
particularly since I don't think I can test such an algorithm without first making (or being
given) a special version of the firmware to run at 96K/10 bit instead of 48K/11 bit.

The PWM clock is the same. Surely the only difference in the two cases is the value written to the PWM_RNG register?

[Avoncliff]

A quick vote of thanks to Dom and all others who have worked on this.
I am now happily listening to Ben Webster through my Quad system, via mpd on the pi controlled from the android phone.
There is a great improvement in sound quality from last time I tried this.

[millerpuckette]

but I hesitate to suggest getting into it so deeply,
particularly since I don't think I can test such an algorithm without first making (or being
given) a special version of the firmware to run at 96K/10 bit instead of 48K/11 bit.

The PWM clock is the same. Surely the only difference in the two cases is the value written to the PWM_RNG register?

Gee, you're right - I forgot about that. Let me see what I can get it to do... only
remaining gotcha is that the code will get more complicated and presumably harder
to translate into firmware.

[wondras]

Hi folks,

You have some *awesome* work going on here! I'm involved in Matt's project, so I am very excited to see Pi coming along for it.

A couple of things I'm wondering about:

1. Will these firmware tweaks result in any significant CPU overhead while audio is playing?

2. Have you considered using any audio measurement tools to evaluate the quality as you experiment with changes to PWM/dither/etc? There are some free tools that may be helpful:

- RightMark Audio Analyzer
http://audio.rightmark.org/

RMAA uses test WAV files to measure frequency response, noise, THD, etc. It's not perfect, but it can be rather revealing. Even a basic PC sound card should be accurate enough to acquire meaningful results from the Pi's analog outputs.


- Audio DiffMaker
http://www.libinst.com/Audio%20DiffMaker.htm

This helps when performing subjective tests by ear with real musical content. It extracts and amplifies the difference between two recordings, so you can compare the original vs. various output devices and settings, or compare two outputs to see if there are significant differences. This can be done manually with any good audio editing tool, but DiffMaker is easier, so it makes multiple tests more practical.


I may be able to run some tests if you think it would be helpful. Otherwise, carry on and good luck!