jdb
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 1660
Joined: Thu Jul 11, 2013 2:37 pm

Analogue audio testing

Postby jdb » Tue Feb 16, 2016 10:03 am

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.

Known rough edges:
- Running the PWM engine at a 781kHz sample rate means the FIFO empties in ~12uS. Changing SDRAM frequencies or running PVT on the SDRAM takes at least 20uS which causes glitches. For now, the firmware disables things that may cause SDRAM accesses to get turned off. In practice, this means that extreme SDRAM overclocks may be unstable with the new audio driver.
- Multiple streams played via different subdevices contend for control instead of mixing - for now only a single stream is supported
- Sometimes the driver can be prodded into a bad state if significant VPU activity is generated at the same time as the driver is opened (e.g. if HD interlaced video is played at the same time as audio usage)
- There is a substantially increased VPU cycle usage with the new audio driver - 25% of VPU0 and ~9% of VPU1 will be used when SDM audio is active. This may cause issues with edge-case usage such as 8-ch HD audio to 2-ch downmix, advanced HD deinterlace and/or simultaneous camera usage.

Please test and report back results. Strikethrough text is no longer valid as of the latest rpi-update firmware.
Rockets are loud.
https://astro-pi.org
User avatar
GTR2Fan
Posts: 1601
Joined: Sun Feb 23, 2014 9:20 pm
Location: South East UK

Re: Analogue audio testing

Postby GTR2Fan » Wed Feb 17, 2016 11:36 pm

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. :)
Pi2B Mini-PC/Media Centre: ARM=1GHz (+3), Core=500MHz, v3d=500MHz, h264=333MHz, RAM=DDR2-1200 (+6/+4/+4+schmoo). Sandisk Ultra HC-I 32GB microSD card on '50=100' OCed slot (42MB/s read) running Raspbian/KODI16, Seagate 3.5" 1.5TB HDD mass storage.
DMcK
Posts: 20
Joined: Sun Jul 01, 2012 4:51 am

Re: Analogue audio testing

Postby DMcK » Thu Feb 18, 2016 4:06 am

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
Posts: 525
Joined: Mon Jan 07, 2013 9:11 am

Re: Analogue audio testing

Postby tvjon » Thu Feb 18, 2016 11:22 am

jdb wrote: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.
User avatar
piglet
Posts: 741
Joined: Sat Aug 27, 2011 1:16 pm

Re: Analogue audio testing

Postby piglet » Thu Feb 18, 2016 11:42 am

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
Posts: 525
Joined: Mon Jan 07, 2013 9:11 am

Re: Analogue audio testing

Postby tvjon » Thu Feb 18, 2016 12:52 pm

I've just tried it on a single ARM
@łe¶ŧ←←↓→øþßðđŋħł»¢“”nµ·²³€½€¾{{[]}\
tvjon
Posts: 525
Joined: Mon Jan 07, 2013 9:11 am

Re: Analogue audio testing

Postby tvjon » Thu Feb 18, 2016 1:01 pm

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
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 1660
Joined: Thu Jul 11, 2013 2:37 pm

Re: Analogue audio testing

Postby jdb » Thu Feb 18, 2016 2:38 pm

piglet wrote: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.
Rockets are loud.
https://astro-pi.org
jdb
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 1660
Joined: Thu Jul 11, 2013 2:37 pm

Re: Analogue audio testing

Postby jdb » Thu Feb 18, 2016 2:46 pm

tvjon wrote: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.
Rockets are loud.
https://astro-pi.org
jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 17444
Joined: Sat Jul 30, 2011 7:41 pm

Re: Analogue audio testing

Postby jamesh » Thu Feb 18, 2016 3:28 pm

jdb wrote:
tvjon wrote: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)
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Please direct all questions to the forum, I do not do support via PM.
PhilE
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 1195
Joined: Mon Sep 29, 2014 1:07 pm
Location: Cambridge

Re: Analogue audio testing

Postby PhilE » Thu Feb 18, 2016 3:35 pm

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)).
User avatar
GTR2Fan
Posts: 1601
Joined: Sun Feb 23, 2014 9:20 pm
Location: South East UK

Re: Analogue audio testing

Postby GTR2Fan » Thu Feb 18, 2016 8:51 pm

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! :)
Pi2B Mini-PC/Media Centre: ARM=1GHz (+3), Core=500MHz, v3d=500MHz, h264=333MHz, RAM=DDR2-1200 (+6/+4/+4+schmoo). Sandisk Ultra HC-I 32GB microSD card on '50=100' OCed slot (42MB/s read) running Raspbian/KODI16, Seagate 3.5" 1.5TB HDD mass storage.
jdb
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 1660
Joined: Thu Jul 11, 2013 2:37 pm

Re: Analogue audio testing

Postby jdb » Fri Feb 19, 2016 11:02 am

GTR2Fan wrote: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?
Rockets are loud.
https://astro-pi.org
User avatar
GTR2Fan
Posts: 1601
Joined: Sun Feb 23, 2014 9:20 pm
Location: South East UK

Re: Analogue audio testing

Postby GTR2Fan » Fri Feb 19, 2016 11:49 am

jdb wrote: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?
Pi2B Mini-PC/Media Centre: ARM=1GHz (+3), Core=500MHz, v3d=500MHz, h264=333MHz, RAM=DDR2-1200 (+6/+4/+4+schmoo). Sandisk Ultra HC-I 32GB microSD card on '50=100' OCed slot (42MB/s read) running Raspbian/KODI16, Seagate 3.5" 1.5TB HDD mass storage.
jdb
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 1660
Joined: Thu Jul 11, 2013 2:37 pm

Re: Analogue audio testing

Postby jdb » Fri Feb 19, 2016 12:42 pm

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.
Rockets are loud.
https://astro-pi.org
dom
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5087
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

Re: Analogue audio testing

Postby dom » Fri Feb 19, 2016 1:05 pm

GTR2Fan wrote: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.
User avatar
GTR2Fan
Posts: 1601
Joined: Sun Feb 23, 2014 9:20 pm
Location: South East UK

Re: Analogue audio testing

Postby GTR2Fan » Fri Feb 19, 2016 1:41 pm

dom wrote: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. :)
Pi2B Mini-PC/Media Centre: ARM=1GHz (+3), Core=500MHz, v3d=500MHz, h264=333MHz, RAM=DDR2-1200 (+6/+4/+4+schmoo). Sandisk Ultra HC-I 32GB microSD card on '50=100' OCed slot (42MB/s read) running Raspbian/KODI16, Seagate 3.5" 1.5TB HDD mass storage.
cjan
Posts: 417
Joined: Sun May 06, 2012 12:00 am

Re: Analogue audio testing

Postby cjan » Sun Feb 21, 2016 1:58 am

does this drive include in BRANCH=next ?
dom
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5087
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

Re: Analogue audio testing

Postby dom » Sun Feb 21, 2016 1:14 pm

cjan wrote:does this drive include in BRANCH=next ?

Yes - firmware was updated 3 days ago, so includes this.
User avatar
becka
Posts: 5
Joined: Fri Feb 19, 2016 12:51 pm

Re: Analogue audio testing

Postby becka » Sun Feb 21, 2016 1:47 pm

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
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 1660
Joined: Thu Jul 11, 2013 2:37 pm

Re: Analogue audio testing

Postby jdb » Sun Feb 21, 2016 4:15 pm

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?
Rockets are loud.
https://astro-pi.org
User avatar
becka
Posts: 5
Joined: Fri Feb 19, 2016 12:51 pm

Re: Analogue audio testing

Postby becka » Sun Feb 21, 2016 5:50 pm

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.
User avatar
GTR2Fan
Posts: 1601
Joined: Sun Feb 23, 2014 9:20 pm
Location: South East UK

Re: Analogue audio testing

Postby GTR2Fan » Mon Feb 22, 2016 1:32 pm

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. :)
Last edited by GTR2Fan on Mon Feb 22, 2016 6:39 pm, edited 1 time in total.
Pi2B Mini-PC/Media Centre: ARM=1GHz (+3), Core=500MHz, v3d=500MHz, h264=333MHz, RAM=DDR2-1200 (+6/+4/+4+schmoo). Sandisk Ultra HC-I 32GB microSD card on '50=100' OCed slot (42MB/s read) running Raspbian/KODI16, Seagate 3.5" 1.5TB HDD mass storage.
chris evans
Posts: 16
Joined: Mon Nov 07, 2011 9:00 pm
Contact:

Re: Analogue audio testing

Postby chris evans » Mon Feb 22, 2016 5:23 pm

Are all the changes in the firmware (start.elf) and config.txt?
If yes then RISC OS and other OS's can easily benefit:-)
http://www.cjemicros.co.uk/rpi/
dom
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5087
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

Re: Analogue audio testing

Postby dom » Mon Feb 22, 2016 7:14 pm

chris evans wrote: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.