Analogue audio redux

[jdb]

Available in latest Raspbian is a PWM audio driver that significantly increases the audio quality available from the 3.5mm TRRS jack.

It is enabled by default.

The analogue signal-to-noise ratio now approaches CD quality with this driver[1]. It works by oversampling the audio stream by a high factor and then pushing the quantisation noise away from audible frequencies by a technique known as sigma-delta noise shaping[2].

This is a continuation of the last thread which I closed as it contains a lot of previous bughunting activity that's no longer relevant.

The driver has undergone a few modifications that allow for multiple concurrent users (i.e. ALSA and omxplayer running simultaneously) and improvements in the additional GPU load the driver causes.

Features/bugfixes:
- The driver now allows for up to 8 simultaneous writers
- GPU vector unit utilisation has been reduced significantly as a much more efficient three-stage resampling pipeline is now used[3]
- on-the-fly switching of audio source between HDMI and Analogue with the driver in use no longer corrupts the analogue output
- Finer-grained resource locking in the driver means fewer contention points when the VPU is busy

The intention is to move to using this driver as the default analogue output driver for all models of Pi that have the 3.5mm jack. There may be some "busy" use-cases that cause lag such as playback of HD interlaced content with VPU audio decode (e.g. MPEG2 1080i source with DTS or AC3 audio or simultaneous CSI camera encoding + HD content playback).

Once any known incompatibilities are mapped out then they will either be documented or a slightly nerfed driver configuration could be implemented that expends a a few dB of audio quality in exchange for GPU performance. As of the time of writing there's no obvious need for a nerfed version of the driver.

Please test and report back with any issues. There is currently a known bug where multiple opens/closes of the driver via ALSA can cause the next open to hang. A workaround is to restart the process in question, as it recovers after force-quitting the hung process. This has proven tricky to replicate, so please detail your configuration if you manage to make this bug appear.


Notes:
[1]: The achievable sound quality depends on the model of Pi used as well as the quality of upstream power supply and lack of ground loops in all connections. Original models of Pi (with 26-pin GPIO headers) will suffer from worse background noise performance as there is no dedicated output buffer for the analogue audio jack. Pi 1 A+/B+, Pi 2 and Pi 3 all implement a low-noise "clean" power supply for the analogue audio jack.

[2]: http://www.beis.de/Elektronik/DeltaSigm ... Delta.html

[3]: The signal processing chain implements three resampling stages and a noise shaping stage.
Stage 1 is source samplerate conversion (8kHz-48kHz -> 48828Hz) - this fractional conversion is required as the PWM source clock is not a power-of-two product of audio sample frequencies.
Stage 2 - Oversampling by factor x8 to 390625Hz using a length=512 FIR filter with a nice, sharp cut-off.
Stage 3 - A final x2 oversampling stage with a length=4 FIR filter, which is folded into the noise shaping for various beneficial reasons.
Stage 4 - 2nd-order quantisation noise shaping from 16-bit PCM at 781250Hz to 7-bit PWM samples.

[SurferTim]

I'm an avid pianobar (RPi version of Pandora) listener. I tried your new update, and it may just be my imagination, but the highs appear to be much cleaner. I haven't started and stopped it enough to determine reliability, but I'll post if I have problems.

Edit: Running an RPi3 with Stretch 2017-09-07 with latest update/upgrade/rpi-update.

[tvjon]

"Please test and report back with any issues. "

Until now, it's been very good, thank you.
However, earlier this morning I downloaded:

http://www.youtube.com/v/JN4q8gkteYc&hl ... 2=0x999999

& have just tried to watch it via

omxplayer -o local

Several seconds into the video, the audio disappears, & omxplayer gives up, so ctrl c to quit.
No audio at all via any means after this.

Editing

/boot/config.txt

to remove the pwm line, allows the video to play. Poor quality as you'll see & hear.

Just for repeatability, I restored the line, & this time attempting to play the video killed the entire gpu. No audio or video.

Jessie running yesterday's rpi-update.

Naturally, just ask if you'd like more info', etc.

[jdb]

Following that link, I get a blank webpage?

If I run youtube-dl on just the root URL, it downloads a 360p video that appears to play OK.
Can you upload your copy to e.g. dropbox? There's no guarantee Youtube will serve me the same file as you got.

[tvjon]

"Can you upload your copy to e.g. dropbox?"

Not at the moment I'm afraid.

"There's no guarantee Youtube will serve me the same file as you got."

Ok, I was unaware of that...

Anyway, just got it again, using:

$ cclive http://www.youtube.com/v/JN4q8gkteYc&hl

& same problem, USING OMXPLAYER.

omxplayer - Commandline multimedia player for the Raspberry Pi
Build date: Mon, 30 Jan 2017 01:52:37 +0000
Version : 62fb580 [master]
Repository: https://github.com/popcornmix/omxplayer.git
$

I've played it in vlc 2.2.4.1 first & it survived. Omxplayer lost audio, as did this Pi3, several seconds in.

[tvjon]

Forgot to add that I suffixed its name with mp4:

Brightgreen displaylink.mp4

[SurferTim]

I just downloaded and played a 1280x720 mp4 version of Feast by Disney. Played fine with omxplayer. Sound and video all the way through. RPi3 with Stretch 2017-09-07.
https://youtu.be/xpC33X4VCDo

[jdb]

Ah, cclive downloads a VP8/vorbis encoded video whereas youtube-dl retrieves h264/aac encoded. With start_x=1 omxplayer plays it. It still doesn't break for me, though.

I'm using the latest omxplayer from Raspbian Stretch.

Code: Select all

omxplayer - Commandline multimedia player for the Raspberry Pi
        Build date: Wed, 05 Jul 2017 16:40:39 +0100
        Version   : 5a25a57 [debian]
        Repository: git@github.com:XECDesign/omxplayer.git

Can you post the entire contents of config.txt and state which OS you are using?

[tvjon]

As I mentioned in my intial email, it's (up to date)jessie.

I've now inserted a Stretch µSD card:

pi@s:~ $ uname -a
Linux s 4.9.56-v7+ #1044 SMP Fri Oct 13 15:23:13 BST 2017 armv7l GNU/Linux

Same omxplayer:

pi@s:~ $ omxplayer -v
omxplayer - Commandline multimedia player for the Raspberry Pi
Build date: Mon, 30 Jan 2017 01:52:37 +0000
Version : 62fb580 [master]
Repository: https://github.com/popcornmix/omxplayer.git
pi@s:~ $

& the file:

pi@s:~ $ omxplayer --display 0 -o local "/home/pi/Videos/Brightgreen displaylink.mp4"
Video codec omx-vp8 width 480 height 360 profile -99 fps 30.000000
Audio codec vorbis channels 1 samplerate 44100 bitspersample 16
Subtitle count: 0, state: off, index: 1, delay: 0
V:PortSettingsChanged: 480x360@30.00 interlace:0 deinterlace:0 anaglyph:0 par:1.00 display:0 layer:0 alpha:255 aspectMode:0
V:PortSettingsChanged: 480x360@30.00 interlace:-1 deinterlace:0 anaglyph:0 par:1.00 display:0 layer:0 alpha:255 aspectMode:0
Stopped at: 00:00:22

There's a continuous buzz (sawtooth like) from the audio. I can post a clip of the audio if you like?

Here's a screenshot when the file freezes.

stretch-freeze.jpg (55.2 KiB) Viewed 27212 times

If I leave it for a couple of minutes, Pi freezes completely.

I may get a chance later to try another Rpi3, but using the 2 µSD's which exhibit the problem.

I still can't access dropbox from here, but I may have an email address still in Contacts. I suspect your file is the same though.

Here's the Stretch config.txt, not much different from Jessie.

config.txt.zip

(984 Bytes) Downloaded 308 times

Al the other videos, & music files I've played recently work fine...

[tvjon]

Clutching at straws I removed all the overclock lines, but of course, no difference.

Removed ALSA .asoundrc, same.

Next, as promised, use another RPi3. Still the same, although the audio didn't fail until 1:20 into the video.

As with the previous RPi3, once the audio dies, no more videos will play until reboot.

Removing the pwm line restores normal operation.

[feelslikeautumn]

Is it possible to increase the volume or is that limited by hardware?

I'm clearly not an audiophile, but I can't really tell the difference between a dac and the analogue output of a pi 1. When I switch over the dac sounds better because it is louder, but if I increase the amp volume to compensate I don't think I can tell them apart.

[jdb]

By default, omxplayer has 0dB gain. The default setting for ALSA is -20dB and can be adjusted through alsamixer - the setting will persist across a reboot.

Even at "0dB" line level, the Pi 3.5mm jack typically outputs voltage levels lower than the equivalent line level as the source impedance is not particularly good (~100 ohm) - any appreciable load resistance on the input to an amplifier will attenuate the Pi output much more than if the amp were connected to a line-level DAC.

[HawaiianPi]

I still get some clicks and pops, but they are less frequent and less loud than before. No problems playing a bunch of different videos in resolutions up to full HD. I watched an entire HD movie tonight in omxplayer with the improved audio settings. I'm running Raspbian Stretch fully dist-upgrad(ed) and rpi-update(ed). Sound is definitely improved.

[jdb]

Can you do a loopback recording of the "pops"?

Using a USB sound card with line-in capability (or a PC), can you use Audacity or similar to capture a few seconds of problem audio and post the .wav file to e.g. Dropbox or similar?

I'm interested to see what the glitches look like - if they're less than ~10uS wide then it's hardware FIFO underrun. If they're milliseconds wide then they're software buffer underrun.

[jdb]

Clutching at straws I removed all the overclock lines, but of course, no difference.

Removed ALSA .asoundrc, same.

Next, as promised, use another RPi3. Still the same, although the audio didn't fail until 1:20 into the video.

As with the previous RPi3, once the audio dies, no more videos will play until reboot.

Removing the pwm line restores normal operation.

Aha, it's the older version of omxplayer that causes the issue. I built from dom's repository and can replicate the hang.

As a workaround, you can try updating to latest omxplayer from Jessie and see if the problem goes away.

[tvjon]

"As a workaround, you can try updating to latest omxplayer from Jessie..."

Actually, I cannot:

syn.jpg (27.23 KiB) Viewed 26962 times

Bizarrely, in Stretch,

kweb

is returned as the search result for omxplayer! Why, I wonder?


Of course, I could build Popcornmix's omxplayer, but as the quality of your new audio is better than before, don't you think it would be more useful for me to keep the present combination just to see if other files trigger the problem, thus aiding your debugging effort?

[jdb]

Hmm. Seems like there's no backport available. I'll ask around and see if there's a way of fetching a single package from a different distribution release in a manner that's not likely to break things.

I'd prefer more testing on the newer version as shipped in Stretch as this will have the widest use for people not employing the advanced audio, so when we switch over we're not suddenly putting lots of users on versions that have had comparatively little testing.

That said, the hang with older omxplayer is a proper GPU rtos abort thus something pretty major has gone wrong. Chief suspects are usually memory corruption or stack over/underflow so this does need fixing.

[tvjon]

It looks like it's not only omxplayer which highlights the video freeze & accompanying sawtooth buzz on audio.

As you can see from my previously supplied config.txt, vga666 is enabled. I have vlc 2.2.4.1 running experimentally to a vga display just showing a RTSP feed all day. I can't use omxplayer for this purpose because of its dreadful latency along with corrupted display, & audio which disappears 30 seconds after it starts, never to return. Fortunately, vlc works rather well, presumably because it's using Livemedia rather than just ffmpeg. All the ffmpeg based players, mplayer, mpv, avplay, etc., exhibit these problems.

This is on the Jessie µSD. I can't run vlc as I need on Stretch, as I haven't yet worked out how to persuade vlc to use Stretch's libav versions. When I do succeed, I'll transfer the ip camera to that, & see if it fails in a similar fashion.

Said display has frozen, starting the irritating buzz from the audio. I've unplugged the jack, but I'll leave it running in case you respond with any vcgencmd you might like me to try?

What you may find interesting is that the X running default hdmi monitor is working fine, as I type this message.

It seems this is another useful feature of RPi's DPI interface...

[jdb]

The HDMI monitor will still work as the framebuffer is just a memory-mapped location that's scanned out by HVS. The ARM can freely write to the memory without GPU interaction.

If the GPU has crashed then vcgencmd won't return anything useful.

Is the ACT LED flashing in a regular pattern? If you're seeing 8 short flashes then you are seeing the same symptom as I am with omxplayer.

[tvjon]

Interesting, because the HDMI monitor has now frozen.

No keyboard or mouse input. Ethernet ok.

SSH is still working though! It feels a bit like the Voyager craft

Both red & green leds are permanently on.

[epoch1970]

EDIT. Nevermind. I dumped everything except the kernel in the old 4.9.21 install, rebooted and I can get concurrent access with audio_pwm_mode=2
Excellent! Thanks.

I have a Pi 3 system running Tiny Core Linux, kernel 4.9.21. Actually it is a piCorePlayer machine.

I want my share of audio_pwm_mode=2 goodness and get concurrent access to the audio device. Currently I can't use the new driver at all.
I did rpi-update on another Raspbian Jessie Pi 3 and got the firmware update + kernel bumped to version 4.9.63

Can I dump firmware files into the piCore machine and get the new functionality?
If so what minimum set of files: *.dtbo, *.dtb, ...?

Thanks in advance.

[jdb]

You can replace the firmware without changing the kernel. If there's a big version jump, certain devicetree changes may break certain things in Linux. Good to know you got it working.

[epoch1970]

OFFTOPIC.
jbd, if you're here and interested.

The contraption for which I had to fudge your new firmware in an older OS is a Pi 3 running piCorePlayer, shoehorned into a Berlin Boombox audio device:
https://www.facebook.com/berlinboombox/ ... 9273419878 (has pictures)

I devised a Y cable to power both Pi and amplifier. What the pictures don't tell is that with the Y cable I'm getting quite a bit of noise on the audio output (on network activity, some permanent humm.) I suppose this is due to a ground loop. I tried the following, to no avail:
- cutting the ground wire in the audio cord between the Pi and the amp (makes things worse),
- using power cables of even length on each branch of the Y (doesn't do anything).

Do you have a recommendation of what could be done to eliminate that noise that I created with this Y cable?

(BTW I'm listening to a Pi 3 connected to headphones as I am writing this; it sounds just perfect.)

[jdb]

I would guess that the wire going to the GPIO is coupling noise into somewhere on the amp PCB.

You can buy in-line isolation transformers (ground loop isolators) that block differring ground potentials but pass audio frequencies.

[epoch1970]

I would guess that the wire going to the GPIO is coupling noise into somewhere on the amp PCB.

You can buy in-line isolation transformers (ground loop isolators) that block differring ground potentials but pass audio frequencies.

Hey thanks. I think I'll examine that for the next unit.
For this one, completely in the blind (but reading from a discussion on this forum), I tried twisting my Y cable upon itself.
This made a tremendous difference, the bulk of the interference is gone. No noticeable noise until the amp is above ~80%, at which time the poor thing is screaming its head off anyway...
Still not the best way to enjoy the new audio mode, but I don't feel guilty anymore