Analogue audio testing

[tzapu]

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]

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

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.

[Taxicletter]

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??)

[m-h]

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'

[davidcoton]

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.

[jdb]

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/

[m-h]

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]

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

[nigelr]

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.

[jdb]

What do I need to do to a fresh Raspbian Jessie image to replicate the results you are seeing with Chromium?

[nigelr]

Thanks, responded via pm.

[linux_author]

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]

Is this likely to move status from experimental to production at some point?

[jdb]

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.

[Muximize]

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]

Does this also happen if you simply run aplay <file> in multiple terminal windows?

[Muximize]

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]

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.

[SnowToad]

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]

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]

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.

[puzzola]

Howdy jdb, please add mine to the pile of thanks

[evilkitty]

Is there a command i can use to check what audio_pwm_mode is set to?

[jdb]

Code: Select all

pi@raspberrypi:~$ vcgencmd get_config audio_pwm_mode
audio_pwm_mode=2
pi@raspberrypi:~$

Default is 1, high quality mode is 2.

[evilkitty]

Thanks, odd it gives 514 for me after a reboot

Code: Select all

pi@raspberrypi:~ $ 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
pi@raspberrypi:~ $ vcgencmd get_config audio_pwm_mode
audio_pwm_mode=514
pi@raspberrypi:~ $ uname -r
4.4.13+
pi@raspberrypi:~ $