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

Re: Analogue audio testing

Fri Mar 11, 2016 12:22 pm

The range is 0..127 for meaningful output. If the accumulated error exceeds 127, the PWM engine simply clips at 127. If the computed value is <0, then we get a wrap to 127 which is annoying.

One potential fix aside from disallowing volumes greater than -3dB at mix time is to rejig the scaling/shifting such that we saturate instead of wrapping.
Rockets are loud.
https://astro-pi.org

Berde
Posts: 6
Joined: Tue Mar 08, 2016 9:58 pm

Re: Analogue audio testing

Fri Mar 11, 2016 12:25 pm

Hi, Is the new driver available? I´ve just tried to update but the start_x.elf is still from March 2nd. Rapsberry 3 and OSMC. Many thanks

dom
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5354
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

Re: Analogue audio testing

Fri Mar 11, 2016 12:29 pm

Berde wrote:Hi, Is the new driver available? I´ve just tried to update but the start_x.elf is still from March 2nd. Rapsberry 3 and OSMC. Many thanks
OSMC isn't going to update to every experimental firmware we release. They often update on a monthly cycle, but that is their choice.

You can manually update the firmware. Download:
https://github.com/raspberrypi/firmware ... tart_x.elf
https://github.com/raspberrypi/firmware ... ixup_x.dat

and replace the ones on the boot partition (the one you see from windows) of your sdcard. Be aware this is experimental and backup up (or using a spare sdcard) would be recommended.

Berde
Posts: 6
Joined: Tue Mar 08, 2016 9:58 pm

Re: Analogue audio testing

Fri Mar 11, 2016 1:30 pm

dom wrote:
Berde wrote:Hi, Is the new driver available? I´ve just tried to update but the start_x.elf is still from March 2nd. Rapsberry 3 and OSMC. Many thanks
OSMC isn't going to update to every experimental firmware we release. They often update on a monthly cycle, but that is their choice.

You can manually update the firmware. Download:
https://github.com/raspberrypi/firmware ... tart_x.elf
https://github.com/raspberrypi/firmware ... ixup_x.dat

and replace the ones on the boot partition (the one you see from windows) of your sdcard. Be aware this is experimental and backup up (or using a spare sdcard) would be recommended.
It worked pretty well! Noise is gone. My experience is that I have to set the volume level 80% higher than I usually do but it works very well. It still has some minor clipps and the sound seems a little flat. Thank you very much!!!

masa-aud
Posts: 144
Joined: Fri Feb 26, 2016 9:20 am

Re: Analogue audio testing

Sat Mar 12, 2016 7:42 pm

reply to jdb on improving audio decoder
I think that strongly welcome the audio quality of RPi is improved at least to 16bit PCM at 44kHz of CD audio rather than 11bit pseudo PCM at 48kHz by PWM which I know here. Your showing method of 7bit 16x sampling sounds good greater than previous 11bit pseudo PCM if it introduces a kind of delta scheme to enlarge maximum amplitude derived from 11bit (=7+4) for lower frequency of principal audio component around 400Hz e.g..

rosswesleyporter
Posts: 10
Joined: Tue Sep 22, 2015 3:53 am

Re: Analogue audio testing

Sun Mar 13, 2016 5:31 pm

I did some more in depth testing and thought I should share the results. In short, sounds good on an A+, best with system volume at 90% or less, likely to be loud enough on your in-ear headphones, if using big headphones then use high sensitivity headphones. Details below.

TEST SETUP:
- A+STOCK - Pi A+ with stock firmware, current full Raspian, VLC, audio out via built-in headphone jack
- A+NEW - Pi A+, same as above, but with March 9 firmware
- A+USB - Pi A+ with a $9 USB audio adapter
- Headphones: Sony MDR7506 over ear, AmazonBasics on-ear, Panasonic RP-HT21, Amazon Premium in-ear, Shure in-ear model unknown but not cheap
- Music: Beethoven's Ode to Joy -- FLAC files from a really good Berlin Philharmonic recording
- Judge: my son the musician
- Note that I am using DQMusicBox on the A+s. Which gives me rotary encoders (dials) to control VLC -- VLC volume and VLC track selection.

OBSERVATIONS:
- New firmware clearly sounds better than stock. I didn't tell the judge which A+ was which. He quickly identified which was A+NEW -- sounds a lot better than A+STOCK.
- On A+STOCK with system volume (alsamixer) at 100% and VLC volume at 100%: audible popping several times per minute; I'm assuming that the popping is a result of clipping.
- On A+ STOCK with system volume (alsamixer) at 90% and VLC volume at 100%: audible popping is much less noticeable.
- Comparing audio quality A+NEW vs. A+USB: A+USB does sound a bit better, IMHO A+NEW is more than good enough for happy music listening, except for the audio popping when at high volume levels.
- Comparing maximum volume on A+NEW and A+USB. A+USB is louder. A+NEW is loud enough with the in-ear headphones tested. A+NEW is *just* loud enough with the Sony over-ear and Amazon on-ear headphones. A+NEW is not loud enough with the $5 Panasonic on-ear headphones. Those Panasonic headphones are loud enough with A+USB. See excellent post above from Sleep Mode zZ on headphone sensitivity. I am sensitive (pun intended) to volume levels, because I am working with a hearing impaired population.

I did not try all of the above with Pi 2. But I did do some testing and results are consistent with the above. I have not tried any of this with a Pi 3. I might do some more Pi A+ testing Raspbian Lite or DietPi.

Thanks again to jdb for making such clear improvements in the audio quality from the built-in headphone jack.

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

Re: Analogue audio testing

Sun Mar 13, 2016 6:29 pm

rosswesleyporter wrote:I did some more in depth testing and thought I should share the results. In short, sounds good on an A+, best with system volume at 90% or less, likely to be loud enough on your in-ear headphones, if using big headphones then use high sensitivity headphones. Details below.

TEST SETUP:
- A+STOCK - Pi A+ with stock firmware, current full Raspian, VLC, audio out via built-in headphone jack
- A+NEW - Pi A+, same as above, but with March 9 firmware
- A+USB - Pi A+ with a $9 USB audio adapter
- Headphones: Sony MDR7506 over ear, AmazonBasics on-ear, Panasonic RP-HT21, Amazon Premium in-ear, Shure in-ear model unknown but not cheap
- Music: Beethoven's Ode to Joy -- FLAC files from a really good Berlin Philharmonic recording
- Judge: my son the musician
- Note that I am using DQMusicBox on the A+s. Which gives me rotary encoders (dials) to control VLC -- VLC volume and VLC track selection.

OBSERVATIONS:
- New firmware clearly sounds better than stock. I didn't tell the judge which A+ was which. He quickly identified which was A+NEW -- sounds a lot better than A+STOCK.
- On A+STOCK with system volume (alsamixer) at 100% and VLC volume at 100%: audible popping several times per minute; I'm assuming that the popping is a result of clipping.
- On A+ STOCK with system volume (alsamixer) at 90% and VLC volume at 100%: audible popping is much less noticeable.
- Comparing audio quality A+NEW vs. A+USB: A+USB does sound a bit better, IMHO A+NEW is more than good enough for happy music listening, except for the audio popping when at high volume levels.
- Comparing maximum volume on A+NEW and A+USB. A+USB is louder. A+NEW is loud enough with the in-ear headphones tested. A+NEW is *just* loud enough with the Sony over-ear and Amazon on-ear headphones. A+NEW is not loud enough with the $5 Panasonic on-ear headphones. Those Panasonic headphones are loud enough with A+USB. See excellent post above from Sleep Mode zZ on headphone sensitivity. I am sensitive (pun intended) to volume levels, because I am working with a hearing impaired population.

I did not try all of the above with Pi 2. But I did do some testing and results are consistent with the above. I have not tried any of this with a Pi 3. I might do some more Pi A+ testing Raspbian Lite or DietPi.

Thanks again to jdb for making such clear improvements in the audio quality from the built-in headphone jack.
Thanks for the testing (single-blind, even!) and positive feedback.

The A+/B+/Pi2 all share a common hardware with regards to the analogue audio output. Pi 3 is a slightly different story as we tweaked a few things to reduce component count, but should be the same as previous HAT-compatible generations for all practical purposes.

The pops at 100% output amplitude have been noticed by others. It's a known limitation, I'm ruminating on how to solve this elegantly.

Headphones are a bit of a quandry - for a relatively common 32 ohm output impedance (which we can transmit a reasonable output power to) it seems there are a wide array of sound pressure levels between models.

For the record, the 3.5mm jack is intended as a line-out jack, not a headphone jack. The source impedance of the jack is 50 ohms on HAT-compatible models, which will have some fun interactions with headphones that have input impedances around 32 ohms plus whatever frequency-dependent characteristics they have.
Rockets are loud.
https://astro-pi.org

jeverley
Posts: 2
Joined: Sun Mar 13, 2016 5:29 pm

Re: Analogue audio testing

Sun Mar 13, 2016 6:47 pm

I've been using the experimental driver on a RPi3 over the past few days, and can conform it offers a massive improvement over the stock driver! As noticed by others in this thread, with the latest firmware, I'm still finding that sound drops out after an irregular period of time.

edit: Should be worth noting that the only way to recover sound output is to restart the system.

I've been unable to pinpoint what's causing this myself, have you had any luck tracing the issue?
Last edited by jeverley on Mon Mar 14, 2016 11:00 am, edited 1 time in total.

cjan
Posts: 737
Joined: Sun May 06, 2012 12:00 am

Re: Analogue audio testing

Mon Mar 14, 2016 2:14 am

jeverley wrote:I've been using the experimental driver on a RPi3 over the past few days, and can conform it offers a massive improvement over the stock driver! As noticed by others in this thread, with the latest firmware, I'm still finding that sound drops out after an irregular period of time.
I've been unable to pinpoint what's causing this myself, have you had any luck tracing the issue?
confirm this issue.

kodi play youtube, sound drops 5 secs then go on.

User avatar
GTR2Fan
Posts: 1601
Joined: Sun Feb 23, 2014 9:20 pm
Location: South East UK

Re: Analogue audio testing

Mon Mar 14, 2016 10:25 am

@jdb: I'm designing a high quality add-on analogue audio filter and buffer circuit (for personal use at first, but I will share the schematics for free on the forum when built and tested) with a 20dB/decade roll-off above 22kHz. I was wondering if you are able to roughly calculate a minimum expected THD figure for the new driver at 1kHz and 10kHz with such a roll-off applied as this would help with capacitor type selection in the active filter. I can go the polypropylene route, but would settle for cheaper C0G MLCC type capacitors if we're still up above, say, 0.1% with little or no expectation of further improvement.

I'm trying to keep component cost down so that any keen electronics DIYer who can read a schematic and wield a soldering iron with reasonable proficiency has an interesting and affordable project to have a crack at. :)

TIA.
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.

elpeh
Posts: 1
Joined: Mon Mar 14, 2016 12:26 pm

Re: Analogue audio testing

Mon Mar 14, 2016 12:31 pm

@jdb: thanks for your work, it really gives usable output now.
One question though: Is "force_turbo=1" really necessary or a momentary restriction?
Could you elaborate a bit?

Lutz

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

Re: Analogue audio testing

Mon Mar 14, 2016 1:30 pm

GTR2Fan wrote:@jdb: I'm designing a high quality add-on analogue audio filter and buffer circuit (for personal use at first, but I will share the schematics for free on the forum when built and tested) with a 20dB/decade roll-off above 22kHz. I was wondering if you are able to roughly calculate a minimum expected THD figure for the new driver at 1kHz and 10kHz with such a roll-off applied as this would help with capacitor type selection in the active filter. I can go the polypropylene route, but would settle for cheaper C0G MLCC type capacitors if we're still up above, say, 0.1% with little or no expectation of further improvement.

I'm trying to keep component cost down so that any keen electronics DIYer who can read a schematic and wield a soldering iron with reasonable proficiency has an interesting and affordable project to have a crack at. :)

TIA.
THD measured experimentally on the Pi 3 output as
-55dB @1kHz, signal -3dBFS
-48dB @10kHz, signal -3dBFS

Crosstalk approx -60dB with signal at -3dBFS.
Pi2/A+/B+ are similar.

As an improvement over the "DAC" on Pi, I would:
- Use an audio-grade LDO for the AVDD supply, instead of our cost-optimised one
- Use C0G instead of X7R/X5R MLCC caps for the RC filter. X7R has a voltage-dependent capacitance which is the single biggest factor in output distortion. Alternatively, use high working voltage (50VDC) X7R to minimise the voltage dependence.
- Use a double-RC to improve roll-off and prevent chopping out a few dB from the high-frequency end. Pole frequencies of 25kHz/50kHz would be my preference.
- Implement analogue muting so it doesn't thump at startup
- Use a low component count headphone amp to trim the output to proper line levels and reduce source impedance to a few ohms
- Use electrolytics for DC blocking on the output.
Rockets are loud.
https://astro-pi.org

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

Re: Analogue audio testing

Mon Mar 14, 2016 1:32 pm

elpeh wrote:@jdb: thanks for your work, it really gives usable output now.
One question though: Is "force_turbo=1" really necessary or a momentary restriction?
Could you elaborate a bit?

Lutz
force_turbo is temporary. Switching SDRAM clock speeds causes minor dropouts which has the annoying effect of occasionally flipping left and right channels. SDRAM speed is still changed during an undervoltage or overtemperature event - so I'll find a way to work around it.
Rockets are loud.
https://astro-pi.org

pagenotfound
Posts: 78
Joined: Mon Mar 14, 2016 12:44 pm

Re: Analogue audio testing

Mon Mar 14, 2016 2:04 pm

@jdb: In my experience the best way to mitigate clipping problems is a fast lookahead limiter. I have been able to get up to 14 db gain on already normalized audio (peaks at 0 db FS) with practically inaudible distortion.

This introduces some delay (i think no more than 5 ms, but don't quote me on this). I don't know how long the feedback loops in your driver are, but you may be able to get at least some of that for free. Detect the peaks at the earliest summation point but of course start reducing gain after the last tap.

There are some decent open source implementations available as LV2 and LADSPA plugins so you can see how it's done.

User avatar
GTR2Fan
Posts: 1601
Joined: Sun Feb 23, 2014 9:20 pm
Location: South East UK

Re: Analogue audio testing

Mon Mar 14, 2016 2:48 pm

jdb wrote:THD measured experimentally on the Pi 3 output as
-55dB @1kHz, signal -3dBFS
-48dB @10kHz, signal -3dBFS

Crosstalk approx -60dB with signal at -3dBFS.
Pi2/A+/B+ are similar.
Wow! Much more info than I was expecting. Thank you so much.
As an improvement over the "DAC" on Pi, I would:
- Use an audio-grade LDO for the AVDD supply, instead of our cost-optimised one
This is designed purely as a plug-in solution for the 3.5mm jack socket, so I can't improve on what's already there, but I should have a PSRR of approaching 100dB across at least the DC to 20kHz range with my current design. I'm guessing this is better than the currently available source signal by a fair margin so should be insignificant in the grand scheme of things.
- Use C0G instead of X7R/X5R MLCC caps for the RC filter. X7R has a voltage-dependent capacitance which is the single biggest factor in output distortion.
I can source C0G specced MLCCs from Farnell fairly cheaply, so I'll go with those. I'm estimating a worst case of roughly 0.03% THD (-70dB-ish) at 10kHz with them, so they should be fine. I could probably get down into the double-zeroes with all polypropylene, but that would be massive overkill in this instance.
- Use a double-RC to improve roll-off and prevent chopping out a few dB from the high-frequency end. Pole frequencies of 25kHz/50kHz would be my preference.
It's actually a 3-pole Chebyshev filter with +/- 0.15dB passband ripple that's only 0.5dB down at 20kHz, then -3dB at 22kHz, -20dB at 44kHz, -40dB at 92kHz, and -60dB at 196kHz. Phase linearity and step response are worse than a typical 2 or 3-pole Bessel, but it's still pretty good for a budget solution with such a steep slope. The use of 1% resistors and 5% capacitors keeps it repeatable enough to be a workable design.
- Implement analogue muting so it doesn't thump at startup
I'd love to do this for the Pi thumps if possible. Could a custom dtoverlay(?) be created to drive an I/O pin high a few milliseconds before driver startup and low a few milliseconds before driver shutdown? I could fairly easily implement a mute from such a control signal if that can be done.
- Use a low component count headphone amp to trim the output to proper line levels and reduce source impedance to a few ohms
It currently performs as a unity-gain buffer with an output impedance of around 0.3 Ohms and should be capable of driving 32 Ohm headphones at up to around 30mW RMS per channel. This should give a damping factor of around 100 into 32 Ohms so should please the audio purists in this respect. I believe output power is currently limited to around 3mW into 32 Ohms by the 270R series resistor in the Pi analogue output stage?
- Use electrolytics for DC blocking on the output.
It's currently a DC-coupled design as it's running from its own internally generated +/- 4.5V rails. Output DC offset should be below +/- 0.5mV in practice. This avoids the need for (at least) 470uF capacitors at the output (the minimum required to maintain the design's present lower -0.5dB point of 20Hz into 32 Ohms) and should help prevent the circuit from introducing its own large thump at initial power-up. Its power-up behaviour should be fairly civilised, but I'll check this when the first prototype is up and running in the real world.

Thanks for your detailed response and advice. It's much appreciated. :)

EDIT: I've substituted the suggested C0G MLCCs for all but the most critical of the filter capacitors (the one that's likely to have the largest voltage swing across it) and total component cost is down to just £5.05 excluding the Farnell enforced multi-buys on some components that inevitably bump the price up. It's amazing what you can still do with a fiver and careful circuit design. ;)
Last edited by GTR2Fan on Mon Mar 14, 2016 7:01 pm, edited 4 times 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.

dom
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5354
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

Re: Analogue audio testing

Mon Mar 14, 2016 4:12 pm

elpeh wrote:One question though: Is "force_turbo=1" really necessary or a momentary restriction?
An alternative to force_turbo=1 is to set sdram_freq=400. This means sdram frequency doesn't change on a turbo/non-turbo switch which also avoids the potential for a glitch.
Also this is only required for Pi2/Pi3. Pi1 runs with sdram_freq=400 by default so doesn't have the issue.

basj
Posts: 14
Joined: Tue Mar 03, 2015 1:37 pm

Re: Analogue audio testing

Mon Mar 14, 2016 5:38 pm

@jdb, is it possible to make the driver natively work as 44.1Khz? (instead of 48khz)

Context:

I'm the author of the project http://www.samplerbox.org (Hardware sampler based on RPi, see here).

Even with the new driver (which, by the way, is a wonderful step for audio on RPi!), the software SamplerBox (using PyAudio) doesn't work when it is started in 44100 Hz. It does work for ~ 2 minutes when I start it in 48000 Hz and then starts to lag (anyway your driver seems to like 48000 much more than 44100).

If someone has a few minutes to test : https://github.com/josephernest/SamplerBox

jeverley
Posts: 2
Joined: Sun Mar 13, 2016 5:29 pm

Re: Analogue audio testing

Mon Mar 14, 2016 6:10 pm

jeverley wrote:I've been using the experimental driver on a RPi3 over the past few days, and can conform it offers a massive improvement over the stock driver! As noticed by others in this thread, with the latest firmware, I'm still finding that sound drops out after an irregular period of time.

edit: Should be worth noting that the only way to recover sound output is to restart the system.

I've been unable to pinpoint what's causing this myself, have you had any luck tracing the issue?
An update on this, I was able to restore sound output by running the command "sudo /etc/init.d/alsa-utils restart", then reopening the audio application, this fix works until the problem recurs around an hour or so later.
Last edited by jeverley on Mon Mar 14, 2016 6:53 pm, edited 1 time in total.

masa-aud
Posts: 144
Joined: Fri Feb 26, 2016 9:20 am

Re: Analogue audio testing

Mon Mar 14, 2016 6:37 pm

reply to db on clipping to 0..127
It is right algorithm in line with the delta modulation scheme you think, I agree with.

camdv
Posts: 1
Joined: Tue Mar 15, 2016 2:06 am

Re: Analogue audio testing

Tue Mar 15, 2016 2:10 am

I'm having an odd problem after installing this patch. speaker-test works fine with pink noise, but it starts a regular clicking that persists when the test is cancelled. This is a steady click at 120 bpm, constant volume. Headphones plugged into the 3.5mm jack.

any ideas?

diegofromparis
Posts: 2
Joined: Sun Mar 06, 2016 11:49 am

Re: Analogue audio testing

Tue Mar 15, 2016 6:33 am

I have the same problems of audio jack output stops randomly after some times (30 minutes to 1h20).
Only solution to recover is to reboot. Sound and Video on HDMI remains ok.

Did you have some ideas to resolve this bug ?

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

Re: Analogue audio testing

Tue Mar 15, 2016 6:06 pm

Latest rpi-update firmware should fix a few things:

- Dropout/underrun on a large set of playback media (primarily interlaced SD video) should now be fixed, as we no longer spend ages contending a lock for the vector logic that we didn't really need.
- Audio modulation has been moved to VPU1 which should level out computation loads a bit.

As for running at 44.1kHz, I have no idea why this should be broken. I've played back 44.1kHz-encoded MP3 files without issue. In theory we can support arbitrary sample rates from 8kHz to 48kHz. I can only suggest trying again with the newer firmware.
Rockets are loud.
https://astro-pi.org

cjan
Posts: 737
Joined: Sun May 06, 2012 12:00 am

Re: Analogue audio testing

Wed Mar 16, 2016 1:48 am

cjan wrote:kodi play youtube, sound drops 5 secs then go on.
#858, no sound.

m-h
Posts: 18
Joined: Sun Jan 11, 2015 10:36 pm

Re: Analogue audio testing

Sun Mar 20, 2016 1:54 am

@jdb, I assume your improved audio output driver is also applicable to Pizero Audio output over GPIO.?
But I have not seen any testers with a pizero jet. So can I help on that part ?

@GTR2Fan, If you design an analogue add-on filter ,can you also look into connecting it via the GPIO ?
I reckon it is simpeler and more stable to connect it from the gpio pins with a protoboard .
And I assume it is possible to redirect the audio signals on greater than zero pies too, although I have not seen any reports on that.
I would like to copy your design onto my future protoboard.

MH

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

Re: Analogue audio testing

Sun Mar 20, 2016 3:59 pm

You will need to modify dt-blob.bin (devicetree listing GPIOs used by the firmware) to reroute PWM outputs to the GPIO header - this is true for any HAT-compatible Pi model as PWM1 isn't accessible on B/A models.
Rockets are loud.
https://astro-pi.org

Return to “Advanced users”