tzapu
Posts: 4
Joined: Thu Apr 28, 2016 3:05 pm

Re: Analogue audio testing

Thu Apr 28, 2016 3:10 pm

hi, just registered to say thank you very much
with
audio_pwm_mode=2
and latest rpi-update
the sounds from my pi2 sounds a million times better. playing through forked-daapd.

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

Re: Analogue audio testing

Thu Apr 28, 2016 4:16 pm

tzapu wrote:hi, just registered to say thank you very much
with
audio_pwm_mode=2
and latest rpi-update
the sounds from my pi2 sounds a million times better. playing through forked-daapd.

Thanks :)
marcel-heijkoop wrote:Hi JDB,
Many thanks for the updates in the firmware.
Audio is improved so much I am now enjoying the standard analogue output over big speakers in my living room.
For my tests I use a picoreplayer 2.04 setup with manually updated start.elf and only the audio_pwm_mode=2 switch.
I've had no stability issues, nor experienced the distorted single channel, but also have not tested all versions as the picore implementation lacks rpi-update.t.m.k.
Some stutters were due to the squeezelight buffer under runs and my Wi-Fi utilization and overcome by increasing buffers.
The distortion in peaks when playing at volume levels between 85 and 100% are obvious audible. And of course easy avoided.
A limited volume setting would help to use this 85-100 range.
Please try and avoid the clipping or wrapping in the final version.
Perhaps in a version "audio_pwm_mode=3" ? you could reduce the noise amplitude in the shaping when nearing the upper and lower limits. I think it woud come down to dynamic range compression, but with the benefits of max analogue output without obvious digital distortion.
Please help me to determine the exact firmware version from start.elf files. Or methods to pull such updates from picore.

Regards Marcel
vcgencmd version will give you the firmware build date and revision. Note that this is different from the hash you use for specific rpi-update versions, but the date string in vcgencmd version can be cross-referenced.

I've implemented signed saturating arithmetic for the noise shaping, which prevents egregious corruption of the signal but if you push the volume too high, the noise shaping is destroyed as there's no headroom - leading to steadily higher levels of white noise polluting the output.

You can set large positive gains using OpenMAX which breaks things under the previous driver as well, so this is generally filed under "don't do that". If you can get distortion by setting the ALSA volume control to max, then I'll have a look at squashing the volume table slightly.
Rockets are loud.
https://astro-pi.org

User avatar
Taxicletter
Posts: 218
Joined: Sat Mar 05, 2016 4:25 pm
Location: Antwerp, Belgium
Contact: Website

Re: Analogue audio testing

Thu Apr 28, 2016 6:43 pm

Still / Again having the problem that if I use PulseAudio, I can use Bluetooth audio but I CAN'T use the internal sound-card.

Is there an alternative to PulseAudio to get Bluetooth working?
Is there a solution to use the internal sound-card with ALSA and PulseAudio both installed?

(I don't understand that nobody else reports this problem. I guess I'm not the only one with an RPI3 and Raspbian, and I installed it more then 10 times, updated daily and tried different configurations. Is there something wrong with my Pi or does nobody use Pulseaudio/Bluetooth/BCM2835??)
--::--::- 3 x Raspberry Pi 3 - Raspbian Lite 9 - RuneAudio - one broke (wifi) - not in use -::--::--

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

Re: Analogue audio testing

Sun May 01, 2016 9:15 am

vcgencmd version will give you the firmware build date and revision. Note that this is different from the hash you use for specific rpi-update versions, but the date string in vcgencmd version can be cross-referenced.

I've implemented signed saturating arithmetic for the noise shaping, which prevents egregious corruption of the signal but if you push the volume too high, the noise shaping is destroyed as there's no headroom - leading to steadily higher levels of white noise polluting the output.

You can set large positive gains using OpenMAX which breaks things under the previous driver as well, so this is generally filed under "don't do that". If you can get distortion by setting the ALSA volume control to max, then I'll have a look at squashing the volume table slightly.
Signed saturating arithmetic is a good method, and probably the only reasonably achievable option
Driving the volume at 100 is my thing, as I listen though direct connected headphones , and their sensitivety could be better for good music.The max output is a limitation of the hardware , not from your code. I should get me a smal HP amp.

I do not use openmax , to my my knowledge, but alsa from the picoreplayer distro..Still using album or track gain and the alsaequal you can get the same issue "don't do that" also applies there.
The white noise at max amplitudes has not been noticed so far . I think your balance between 'clipping' and digital amplification is correct.
If the video core routines give you enough feedback, you could implement a small routine that will drive a led on the GPIO to show the clipping occurs. Real retro but fun to watch on a home made logitech player

Further I use a manual downloaded start.elf from github and just the audio_pwm_mode=2 directive i.c.w. overclocked b+ and 2B models. 2 cirrus logic audio cards have become decommissioned as this audio quality is great, and I never found good housing for those cards.

Next should be testing this on the pizero. I just need to find time to google a matching analogue filter , order the components online, and solder the stuf on a small board. It will cost more than a phat dac, but it could convince people the 2nd generation of pizero should have the analogue output again, on dedicated pins or pads to keep costs down

Again thanks for fixing this '4 year old bug' ;-)

User avatar
davidcoton
Posts: 4019
Joined: Mon Sep 01, 2014 2:37 pm
Location: Cambridge, UK

Re: Analogue audio testing

Sun May 01, 2016 11:29 am

marcel-heijkoop wrote:Next should be testing this on the pizero. I just need to find time to google a matching analogue filter , order the components online, and solder the stuf on a small board. It will cost more than a phat dac, but it could convince people the 2nd generation of pizero should have the analogue output again, on dedicated pins or pads to keep costs down
See here. The audio output of the 3B is shown bottom right of the page.
Adafruit tutorial on getting the PWM signals out here.
Signature retired

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

Re: Analogue audio testing

Thu May 05, 2016 12:14 pm

A note on residual harmonic distortion (Quoted as 0.3% THD, but is variable):

The output with the new driver still has in-band harmonic distortion despite having in-band quantisation noise maximally attenuated by the noise shaping. The in-band harmonics are caused by the way we generate output pulses - it's via trailing-edge pulse width modulation (i.e. all pulses are left-aligned with the sample period). This has the effect of slightly shifting the energy of the sample temporally depending on whether a low duty cycle or high duty cycle is being output.

The resulting distortion is both a function of the ratio of the frequency of interest (Fs) versus the carrier frequency (Fc) and the modulation factor (amplitude of Fs versus amplitude of Fc).

Therefore higher output frequencies will have a higher THD than lower output frequencies, globally adjusted by the volume setting. Reducing the output volume results in a trade-off between THD and quantisation noise, but if you run at -12dBFS (-8dB setting in alsamixer) then neither should be noticeable.

Also, if you're using headphones then a headphone amp is strongly recommended (due to the relative impedances resulting in poor damping factor) - I use a Topping NX1 which is a handy slimline device.

Further reading:

http://www.openmusiclabs.com/learning/d ... -analysis/
Rockets are loud.
https://astro-pi.org

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

Re: Analogue audio testing

Fri May 06, 2016 8:00 am

It seems I can hear the distortion at 100% output also when I am using a higher impedance load.
So a amplifier i.s.o. direct to headphones.The sources I used at first did not reveal this. But it is obvious in the lower frequencies.
I am using clean commercial CD rips without lossy compression.
Limiting the volume to 90 ( slimserver / squeezelight setting ) does make this go away.
I'll try to come back with more detailed volume settings , like alsamixer readings. After evaluating more sources and trying to find the exact maximum that does not distort the music.
It seems I need to come back on my previous remark where I mentioned the volume table setting is just right.
Marcel.

nigelr
Posts: 6
Joined: Sat May 07, 2016 5:18 am

Re: Analogue audio testing

Mon May 09, 2016 2:37 pm

Hi jdb, great work

I am testing a music player app for the RPi3 and very much want to use this new audio output method. I am testing an HTML version of the player in Chromium on Ubuntu Mate 16:04 and the latest vanilla Jessie. The sound is great on Ubuntu Mate but stutters rapidly on Jessie as if there is a resample conflict. Versions of Chromium are identical on both Pis (48.0.2564.82). omxplayer plays fine on Jessie. I am working with a developer who will port the music player app to Linux over the next few days. We'd rather use Jessie as Ubuntu Mate is very resource hungry out of the box.

Do you have any suggestions on what I could do to diagnose this?

Cheers
VME/B - written in Kidsgrove, VME/K - written in Bracknell. I miss ICL.

nigelr
Posts: 6
Joined: Sat May 07, 2016 5:18 am

Re: Analogue audio testing

Tue May 10, 2016 5:20 am

I installed pulseaudio, just as an experiment. That's all, no config changes. The sound is now perfect. I've no idea why. Maybe it's a Chromium thing but I'd like to understand it if anyone has any ideas.
VME/B - written in Kidsgrove, VME/K - written in Bracknell. I miss ICL.

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

Re: Analogue audio testing

Tue May 10, 2016 10:32 am

What do I need to do to a fresh Raspbian Jessie image to replicate the results you are seeing with Chromium?
Rockets are loud.
https://astro-pi.org

nigelr
Posts: 6
Joined: Sat May 07, 2016 5:18 am

Re: Analogue audio testing

Tue May 10, 2016 11:43 am

Thanks, responded via pm.
VME/B - written in Kidsgrove, VME/K - written in Bracknell. I miss ICL.

linux_author
Posts: 248
Joined: Sat Apr 02, 2016 7:04 pm
Location: Gulf of Mexico
Contact: Website

Re: Analogue audio testing

Sat May 28, 2016 4:11 pm

OK, i'll pile in here:

static in the analog audio output via Audacious with a plugged in mini-speaker was driving me nuts! my system is an RPI3 w/May 2016 (latest) Raspian

the audio_pwm_mode=2 edit to /boot/config.txt fixed the issue!

(i had also tested a Turtle Beach audio adapter previously, and the sound was clean through it - no static, but i don't like dangling dongles from my RPi3 so it wouldn't have worked as a workaround)

[btw, am still looking for an ultra-compact USB thumb drive for storage - my 128GB Sandisk Ultra Fit seems about the best the industry can do at this point]

so, thanks folks!

willie
on the 'clean-audio for old ears' Gulf of Mexico

nigelr
Posts: 6
Joined: Sat May 07, 2016 5:18 am

Re: Analogue audio testing

Wed Jun 01, 2016 11:13 am

Is this likely to move status from experimental to production at some point?
VME/B - written in Kidsgrove, VME/K - written in Bracknell. I miss ICL.

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

Re: Analogue audio testing

Wed Jun 01, 2016 7:15 pm

There are still a few edge-case regressions.

VPU deinterlace + SDM audio results in ~30fps performance on deinterlace due to some kind of vector core contention. VPU deinterlace is still enabled by default for interlaced media - there is a QPU-based HQ deinterlace that should in theory replace it but needs a bit more work before enabling that by default.

Aside from Chromium issues, there's also a case where rapid pause/unpause can sometimes get the audio buffer into a bad state.
Rockets are loud.
https://astro-pi.org

Muximize
Posts: 14
Joined: Sat Aug 30, 2014 2:57 pm

Re: Analogue audio testing

Sat Jun 04, 2016 9:43 pm

Thanks jdb for all you efforts! Amazing to get this quality after all (and after 4 years) in spite of the hardware constraints of the Pi to get it cheap.

I am however experiencing some difficulties due to either a regression or me not understanding ALSA:

Without audio_pwm_mode=2, I can play multiple sounds (multiple instances of aplay executed with nodejs) and they would get properly mixed. For example, looping background music with triggered sound-effects on top.

however, with audio_pwm_mode=2 any second (or third or...) aplay instance will play short (~100ms) chunks every 5 seconds or so, until it eventually has played the whole file. Seems like there is contention going on for the audio device.

Is this something that can be fixed in firmware, or should I be mixing my sounds on another level of abstraction?

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

Re: Analogue audio testing

Mon Jun 06, 2016 12:02 pm

Does this also happen if you simply run aplay <file> in multiple terminal windows?
Rockets are loud.
https://astro-pi.org

Muximize
Posts: 14
Joined: Sat Aug 30, 2014 2:57 pm

Re: Analogue audio testing

Mon Jun 06, 2016 6:42 pm

Yes, I tried with two separate ssh sessions, one playing a long (minutes) wav or mp3 file with either aplay or mpg123, the other playing a short (seconds) wav file with aplay. Verbose output shows the second aplay seemingly correctly trying to play on subdevice 1.

After some more testing the skipping/interlacing seems more random than I initially noted, with sometimes ~10 seconds of background sound, then interrupted every second or so by 10-500ms of foreground sound. This is happening on both a Pi 1 and 2.

Sometimes the foreground aplay process doesn't play any sound at all, quiting after about 10 seconds with:

Code: Select all

aplay: pcm_write:1939: write error: Input/output error
I played around with aplay --mmap and --nonblock options, no difference. Is there more testing I can do, or can you reproduce?

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

Re: Analogue audio testing

Tue Jun 07, 2016 2:08 pm

I can replicate this. Two instances of aplay will contend in turn playing samples over several seconds with one occasionally timing out. Mixing works correctly for !audio_pwm_mode=2.

Nothing obvious pops out as to why this is different - needs more investigation.
Rockets are loud.
https://astro-pi.org

SnowToad
Posts: 6
Joined: Mon Apr 11, 2016 7:24 am

Re: Analogue audio testing

Mon Jun 27, 2016 5:46 am

Hi guys,

I'm not having popping or interruption issues with Rpi audio, the only problem is that the volume is quite low through headphones (even when set to max)
I know the audio output is meant to be line level to be fed to an amp, but I just want to check if I'm missing out on anything.
Is it generally accepted that the volume through headphones connected directly to the jack is quite low (maybe 1/2 or 2/3 that of max from a mobile phone)

I'm currently using a USB sound card because the built in audio just can't go loud enough for headphones..

sylgar
Posts: 26
Joined: Wed Mar 23, 2016 10:39 pm
Contact: Website

Re: Analogue audio testing

Wed Jun 29, 2016 6:12 pm

Is audio_pwm_mode=2 the default these days (as of the time of writing - 2016-06-29)? Or should it still be set in config.txt?

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

Re: Analogue audio testing

Wed Jun 29, 2016 6:13 pm

sylgar wrote:Is audio_pwm_mode=2 the default these days (as of the time of writing - 2016-06-29)? Or should it still be set in config.txt?
It's not the default yet.

User avatar
puzzola
Posts: 5
Joined: Sat Mar 14, 2015 2:22 am

Re: Analogue audio testing

Mon Jul 18, 2016 9:56 am

Howdy jdb, please add mine to the pile of thanks :)

evilkitty
Posts: 370
Joined: Tue Apr 15, 2014 11:39 pm

Re: Analogue audio testing

Wed Aug 17, 2016 11:11 am

Is there a command i can use to check what audio_pwm_mode is set to?
My Pi Server: http://imgur.com/a/6xIUI | Thermostat: http://imgur.com/a/4LVnT

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

Re: Analogue audio testing

Wed Aug 17, 2016 11:43 am

Code: Select all

[email protected]:~$ vcgencmd get_config audio_pwm_mode
audio_pwm_mode=2
[email protected]:~$
Default is 1, high quality mode is 2.
Rockets are loud.
https://astro-pi.org

evilkitty
Posts: 370
Joined: Tue Apr 15, 2014 11:39 pm

Re: Analogue audio testing

Wed Aug 17, 2016 10:43 pm

Thanks, odd it gives 514 for me after a reboot

Code: Select all

[email protected]:~ $ cat /boot/config.txt
# For more options and information see
# http://www.raspberrypi.org/documentation/configuration/config-txt.md
# Some settings may impact device functionality. See link above for details

# uncomment if you get no picture on HDMI for a default "safe" mode
#hdmi_safe=1

# uncomment this if your display has a black border of unused pixels visible
# and your display can output without overscan
#disable_overscan=1

# uncomment the following to adjust overscan. Use positive numbers if console
# goes off screen, and negative if there is too much border
#overscan_left=16
#overscan_right=16
#overscan_top=16
#overscan_bottom=16

# uncomment to force a console size. By default it will be display's size minus
# overscan.
#framebuffer_width=1280
#framebuffer_height=720

# uncomment if hdmi display is not detected and composite is being output
#hdmi_force_hotplug=1

# uncomment to force a specific HDMI mode (this will force VGA)
#hdmi_group=1
#hdmi_mode=1

# uncomment to force a HDMI mode rather than DVI. This can make audio work in
# DMT (computer monitor) modes
#hdmi_drive=2

# uncomment to increase signal to HDMI, if you have interference, blanking, or
# no display
#config_hdmi_boost=4

# uncomment for composite PAL
#sdtv_mode=2

#uncomment to overclock the arm. 700 MHz is the default.
#arm_freq=800

# Uncomment some or all of these to enable the optional hardware interfaces
#dtparam=i2c_arm=on
#dtparam=i2s=on
#dtparam=spi=on
# Needed with newer kernerls than 3.12 to use thermel sensors
dtoverlay=w1-gpio

# Uncomment this to enable the lirc-rpi module
#dtoverlay=lirc-rpi

# Additional overlays and parameters are documented /boot/overlays/README

# Enable audio (loads snd_bcm2835)
dtparam=audio=on
#core_freq=250
#sdram_freq=400
#over_voltage=0
gpu_mem=16
audio_pwm_mode=2

#Enable IR LED/Reciever (also see /etc/modules)
dtoverlay=lirc-rpi,gpio_out_pin=26,gpio_pin_in_pin=none
[email protected]:~ $ vcgencmd get_config audio_pwm_mode
audio_pwm_mode=514
[email protected]:~ $ uname -r
4.4.13+
[email protected]:~ $
My Pi Server: http://imgur.com/a/6xIUI | Thermostat: http://imgur.com/a/4LVnT

Return to “Advanced users”