Analogue audio testing

[jdb]

Available with rpi-update firmware is an experimental audio driver that should significantly increase the quality of sound produced by the 3.5mm audio jack.

I've reimplemented the original PWM-based 11-bit audio @48kHz as 7-bit 2nd-order Sigma-Delta modulated at 781.25kHz. The effective noise floor with this scheme approximates that of CD-quality audio DACs.

There are some rough edges and probably quite a few bugs, but here's how to enable it:

Run sudo rpi-update

In /boot/config.txt add the following line:

Code: Select all

audio_pwm_mode=2

Before using the audio for the first time, you should run amixer cset numid=3 1 to ensure that HDMI is not selected as the audio output path. OMXplayer should be forced to use "local" as the sound output route.

For continuing discussion about the latest release, please see the new thread ->> viewtopic.php?f=29&t=195178

Please test and report back results.

[GTR2Fan]

Thanks for your efforts. I can't believe this hasn't drummed up more interest than it has. I'll have a play with this over the next few days and see how it goes. It sounds like a mighty impressive WIP so far.

[DMcK]

Yes, thanks. I use the analogue output in my car so I am very interested. However, I won't be able to test it for a week or so. Sorry.

[tvjon]

Available with rpi-update firmware is an experimental audio driver that should significantly increase the quality of sound produced by the 3.5mm audio jack.

I've reimplemented the original PWM-based 11-bit audio @48kHz as 7-bit 2nd-order Sigma-Delta modulated at 781.25kHz. The effective noise floor with this scheme approximates that of CD-quality audio DACs.

...
Please test and report back results.

jdb,

thank you for your effort on this. Much improved. Nice to pause audio, & not to have a huge change in the noise floor.


I've tested it on 2 µSD cards so far, but on the same RPi, eliminating any hardware differences. The first one was inconclusive as it looks like ALSA isn't behaving well on it. I also discovered that the Pulseaudio volume control I use on that card causes massive screen breakup of an eyetoy webcam on an attached Gert VGA666 display!

There's a lot of Bluetooth devices connected to that too.

On a new card, still with jessie, it's fine.


Do you have time to tell us why the audio was changed from the original sigma-delta version?

I'll install more audio related software on this card, & report back if any problems.

[piglet]

Just seen this. Very interesting.

Is this change improve only the Pi B2 output or will it change the Pi B audio too? I know there's a hardware difference between the two.

[tvjon]

I've just tried it on a single ARM
@łe¶ŧ←←↓→øþßðđŋħł»¢“”nµ·²³€½€¾{{[]}\

[tvjon]

Epiphany browser -all that's on this SD so I'll try again

I've just tried it on a single ARM core Pi2 & it works fine. Apart from improved quality that irritating background noise is absent. As a quick test I nop'd out the 4 config.txt statements, played some tracks & up came that noise level again, yuk.

So, unless any serious side effects, it's going on all my Rpi's

[jdb]

Just seen this. Very interesting.

Is this change improve only the Pi B2 output or will it change the Pi B audio too? I know there's a hardware difference between the two.

The basic method of audio generation is the same across all models of Pi (except Zero, which doesn't have it). The PWM peripheral is used to drive an RC filter that "approximates" a DAC.

With Pi 1 model B / A there is still the issue of background contamination from SD/ethernet activity as the audio output uses the same voltage rail as the rest of the board. B+ / A+ / B2 solve this issue by using a CMOS buffer between the GPIO and RC network and supplying the VDD of the buffer from a dedicated regulator.

[jdb]

Do you have time to tell us why the audio was changed from the original sigma-delta version?

I'll install more audio related software on this card, & report back if any problems.

Original sigma-delta, what? The original scheme (used since 2012 release) uses the PWM peripheral in pulse-density modulation mode at 11-bit. The input 16-bit was quantised to 11-bit and output at a sample frequency of ~48kHz

The new scheme uses duty-cycle mode at 7-bit resolution with ~16x oversampling. Benefits:
- This reduces harmonic distortion as we're not driving GPIOs/buffers as fast (THD+N is now about -50dB versus a terrible -20dB before)
- It fits in a sweet-spot with our output RC filter that means the PWM carrier is almost completely suppressed (-38dB at the frequency of interest - one thing to note is that other DACs can have significant out-of-band emissions at several hundred kHz)
- It's about as fast as we can afford to pump samples into the PWM FIFO due to bus latency constraints
- Quantisation noise floor now ~-93dB instead of the ~-60dB it was previously and shouldn't vary with input signal

Gordon's trying to get me to do a writeup. I should probably do that.

[jamesh]

Do you have time to tell us why the audio was changed from the original sigma-delta version?

I'll install more audio related software on this card, & report back if any problems.

Original sigma-delta, what? The original scheme (used since 2012 release) uses the PWM peripheral in pulse-density modulation mode at 11-bit. The input 16-bit was quantised to 11-bit and output at a sample frequency of ~48kHz

The new scheme uses duty-cycle mode at 7-bit resolution with ~16x oversampling. Benefits:
- This reduces harmonic distortion as we're not driving GPIOs/buffers as fast (THD+N is now about -50dB versus a terrible -20dB before)
- It fits in a sweet-spot with our output RC filter that means the PWM carrier is almost completely suppressed (-38dB at the frequency of interest - one thing to note is that other DACs can have significant out-of-band emissions at several hundred kHz)
- It's about as fast as we can afford to pump samples into the PWM FIFO due to bus latency constraints
- Quantisation noise floor now ~-93dB instead of the ~-60dB it was previously and shouldn't vary with input signal

Gordon's trying to get me to do a writeup. I should probably do that.

Writeup would be good. Because there was a couple of sentences in the previous paragraph that I didn't understand (actually, the four points, plus another bit)

[PhilE]

That sounds like false modesty - I'm sure you're just waiting for the chance to pick holes in jdb's work.

(I am winking heavily as I write this (no, read it again James)).

[GTR2Fan]

I've carried out some testing over the past day or so and am very impressed by the improvement in sound quality as well as the vastly improved noise floor. A few observations...

1/ Audio playback in VLC 2.2.1 Terry Pratchett (Weatherwax) is excellent from my archive of home-encoded LAME VBR V3 MP3 files.

2/ The same tracks played in gkreidl's Raspbian compile of KODI 15.2 from Dec 14 2015 is equally excellent, although SD and HD video soundtracks warble heavily as though the samplerate is being ramped up and down very quickly. Imagine a cassette player with a badly bent capstan drive shaft and you'll know what I mean. I wondered if this might be due to some kind of audio resampling going on as I'm watching 25FPS video on a 60Hz panel, but no amount of playing with KODI's audio settings fixed it, apart from forcing ALSA which brings the noise back again, so I guess this defeats the new sound scheme.

3/ The sound in my own compile of Quake3 Arena is amazing compared to how it was before. Very crisp and clean.

4/ The sound in the Pi version of Quake Darkplaces is completely missing. Checking the console for errors after exiting shows a long stream of S_StaticSound: "ambience/fire.wav" hasn't been precached (with various filenames) type errors.

Hopefully the above will be seen as bug reporting, not criticism. It's a sonic marvel for the ears to behold compared to how it was when it's working properly. Big thumbs-up!

[jdb]

2/ The same tracks played in gkreidl's Raspbian compile of KODI 15.2 from Dec 14 2015 is equally excellent, although SD and HD video soundtracks warble heavily as though the samplerate is being ramped up and down very quickly. Imagine a cassette player with a badly bent capstan drive shaft and you'll know what I mean. I wondered if this might be due to some kind of audio resampling going on as I'm watching 25FPS video on a 60Hz panel, but no amount of playing with KODI's audio settings fixed it, apart from forcing ALSA which brings the noise back again, so I guess this defeats the new sound scheme.

This has been reported elsewhere with Kodi. Can you upload a sample file somewhere?

[GTR2Fan]

Can you upload a sample file somewhere?

Download link sent via PM.

By the way, do my ears deceive me, or are we now achieving a full 20kHz bandwidth?

[jdb]

With the previous scheme, harmonic distortion meant that the top end of the audio spectrum was polluted with harmonics from the lower end. This probably manifests as a perceived loss of fidelity at high frequencies.

The total bandwidth is the same in both cases, but with the majority of the spurious noise removed in the new scheme I would wager accurate reproduction at >10kHz makes it sound a lot better.

[dom]

2/ The same tracks played in gkreidl's Raspbian compile of KODI 15.2 from Dec 14 2015 is equally excellent, although SD and HD video soundtracks warble heavily as though the samplerate is being ramped up and down very quickly. Imagine a cassette player with a badly bent capstan drive shaft and you'll know what I mean. I wondered if this might be due to some kind of audio resampling going on as I'm watching 25FPS video on a 60Hz panel, but no amount of playing with KODI's audio settings fixed it, apart from forcing ALSA which brings the noise back again, so I guess this defeats the new sound scheme.

Kodi only resamples when "sync playback to display" is enabled and omxplayer is disabled. Try switching one or both of those settings.
Not a complete solution as omxplayer disabled with "sync playback to display" is the recommended setup, but may be an interesting test.

[GTR2Fan]

Kodi only resamples when "sync playback to display" is enabled and omxplayer is disabled. Try switching one or both of those settings.
Not a complete solution as omxplayer disabled with "sync playback to display" is the recommended setup, but may be an interesting test.

Interesting. Thanks. It would seem that me enabling OMXPlayer hardware acceleration was what broke it. Putting Settings/Video/Acceleration/Allow Hardware Acceleration - OMXPlayer back to its default setting of off fixes the problem. All other video/audio settings are also on defaults.

This just leaves me with the weird problem of sounds in Quake Darkplaces not being precached to worry about. Otherwise, it's now perfectly functional for me.

[cjan]

does this drive include in BRANCH=next ?

[dom]

does this drive include in BRANCH=next ?

Yes - firmware was updated 3 days ago, so includes this.

[becka]

I've switched to this driver a few days ago, after being pointed here when I was investigating the high noise floor in my RPi 2.
In the first tries I had some issues with kodi sound having hiccups (both over- and underrun-like), but those magically resolved.
Sound quality is quite excellent now.

The remaining issue I have is that after a few hours of playback the audio stops responding. Output falls silent. Unloading/reloading the snd_bcm2835 as well as the other snd_* modules does not help. A reboot does.

I have on first glance no suspicious logging in all files I checked (var/log/syslog|debug), but maybe I'd need to enable some debug options first or need to look elsewhere.

Any pointers?

Thanks

[jdb]

Regarding audio output "stopping" - is it a regular interval of time before it stops? Is one program continuously using the audio output in that time?

[becka]

No, the Interval feels random to me. Kodi is running continuously, streaming webradio. After it stopped, I shut down Kodi, tried playing an mp3 via osmplayer, tried unloading and reloading the snd_* modules, retried playing the mp3. Nothing. Reboot and all is good again.

In any case the effect only occurred after a few hours minimum.

[GTR2Fan]

I'm having a similar problem here with extended usage of the new audio driver.

Watching three 45-minute documentaries nose-to-tail in gkreidl's KODI 15.2 started off OK, but the sound on the third documentary started to rhythmically crackle and 'fuzz' around the 2-hour total playtime mark with the audio slowly disappearing behind the noise over the course of a couple of minutes until a loud click was emitted followed by complete silence.

I tried watching three 45-minute episodes of another documentary series the following day and exactly the same thing happened after approximately the same total playback time, so it appears to be a repeatable problem. These are locally encoded files that play back fine in KODI on a Win10 PC, so the files are of known integrity.

It seems to be an application-agnostic problem as I've just been listening to a streaming radio station on the TuneIn website via Chromium 48 web browser and the same thing has happened again after roughly 2 hours of continuous listening.

No amount of switching audio modes or opening and closing other programs that use audio fix it. Only a Raspbian reboot brings it back to life. Nothing odd to see in any log files I'm afraid.

If there's anything you'd like me to try at this end, just give me a shout as I'm happy to make any configuration changes or test any potential bugfixes you'd like to throw my way. I'm probably as keen as you are to see this working 100% due to the night-and-day difference in quality it offers over the old driver.

[chris evans]

Are all the changes in the firmware (start.elf) and config.txt?
If yes then RISC OS and other OS's can easily benefit:-)

[dom]

Are all the changes in the firmware (start.elf) and config.txt?
If yes then RISC OS and other OS's can easily benefit:-)

Yes, nothing is in kernel/userland, so a firmware (start.elf/fixup.dat) update and config.txt settings should work on any distribution.