Available in latest rpi-update firmware is a PWM audio driver that significantly increases the audio quality available from the 3.5mm TRRS jack.
To enable the advanced audio driver, add audio_pwm_mode=2
The analogue signal-to-noise ratio now approaches CD quality with this driver. 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.
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.
- 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
- 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.
: 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.
: http://www.beis.de/Elektronik/DeltaSigm ... Delta.html
: 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.
Rockets are loud.