Pi Audio improvements

They’ve reworked the analogue audio driver for the Pi making it significantly better:
https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=136445&p=911116

I think all the changes are in the firmware (start.elf) and config.txt so RISC OS benefits:-)

I won’t have time myself this week to give it a try. (New computer to launch!)

They’ve reworked the analogue audio driver for the Pi making it significantly better:

So long as you don’t want to listen to audio for a long time, it seems. Read the few posts directly above Chris’ question.

- Running the PWM engine at a 781kHz sample rate means the FIFO empties in ~12uS. Changing SDRAM frequencies or running PVT on the SDRAM takes at least 20uS which causes glitches. For now, disable things that may cause SDRAM accesses to get turned off

Is this liable to be interfered with by RISC OS’ propensity for disabling interrupts a lot?

- It’s about as fast as we can afford to pump samples into the PWM FIFO due to bus latency constraints

Yikes! So analogue audio is implemented by getting the GPU (?) to shove samples at a PWM GPIO port?

So long as you don’t want to listen to audio for a long time, it seems. Read the few posts directly above Chris’ question.

It is a beta!

Yikes! So analogue audio is implemented by getting the GPU (?) to shove samples at a PWM GPIO port?

Well they reckon it gives near CD quality!
I wonder how dedicated DACs normally do it?
I suspect cheap ones may use the same/similar method or worse!

Dom from the Pi Foundation has confirmed it should work on RISC OS:

Yes, nothing is in kernel/userland, so a firmware (start.elf/fixup.dat) update and config.txt settings should work on any distribution.

Well they reckon it gives near CD quality!
I wonder how dedicated DACs normally do it?
I suspect cheap ones may use the same/similar method or worse!

I tend to be wary of claims people make about “near CD quality”. Can mean almost anything! FWIW when Delta-Sigma first started to be used in commercial DACs/ADCs you might find 2nd order. But the chances are these days that a decent device would use a higher order. Takes more processing and harder to get working well, but tends to give better results when done OK.

Jim

- Running the PWM engine at a 781kHz sample rate means the FIFO empties in ~12uS. Changing SDRAM frequencies or running PVT on the SDRAM takes at least 20uS which causes glitches. For now, disable things that may cause SDRAM accesses to get turned off

Is this liable to be interfered with by RISC OS’ propensity for disabling interrupts a lot?

All the PWM audio processing is done GPU side, so it should be unaffected by ARM interrupt state.

- It’s about as fast as we can afford to pump samples into the PWM FIFO due to bus latency constraints

Yikes! So analogue audio is implemented by getting the GPU (?) to shove samples at a PWM GPIO port?

Yep. Not sure how much money it actually saved them (per unit), but I guess they figured that PWM audio was “good enough” that they could do without a dedicated DAC.

Wouldn’t the sound output be mostly thought of as legacy, like the composite output?

People would use the digital out via HDMI or an add on for high quality.

I tend to be wary of claims people make about “near CD quality”.

This is where something like Nightwish is useful. Symphonic metal with opera style vocals. A pretty good test for poor compression. I have a DVD player with a built-in CD ripping facility. For a laugh, I tried it. 128kbit CBR. It sounded like I’d put a speaker in a bucket on the other side of the room. The encoding made the bass sound dead, and struggled to provide the not-bass and do any justice to the violins at the same time.

FWIW, the copy on my phone was ripped to quality 2 VBR. WinAMP tells me that this is “around 300kbit” (it gives a periodic rate, which is always changing, so I just noted the sorts of numbers that were appearing). I don’t use quality level 1 because I’m listening with fairly inexpensive bluetooth headphones, so the extra file size doesn’t translate into extra audible quality.

Can mean almost anything!

Indeed. “CD quality” to me is 44.1kHz 16 bit uncompressed stereo. An acceptable source.

FWIW when Delta-Sigma first started to be used in commercial DACs/ADCs

I remember my first portable CD player proudly said “1 bit DAC” across the lid. I had a real “WTF? They’re bragging about what?” moment when I first saw that.

you might find 2nd order.

…which in English means?

Takes more processing and harder to get working well, but tends to give better results when done OK.

Isn’t this a bit of an obvious statement?
Consider the video world: MPEG1/VCD → MPEG2/DVD → H.263/XviD → H.264 → HEVC… Each one better than the one before, each one requiring considerably more processing power to handle (to the point where a quad-core 1.4GHz ARM mobile phone struggles to do HD HEVC in software (and can do FullHD H.264 effortlessly)).

but I guess they figured that PWM audio was “good enough” that they could do without a dedicated DAC.

It’s an interesting way to keep the price down.

(next you’ll be telling me the GPU outputs composite video by reading the framebuffer and directly wiggling the composite video output – not as crazy as it sounds!)

which in English means?

I should get around to adding this to the ‘Scots Guide’. However “for a limited time only” you can find a simple explanation at

http://jcgl.orpheusweb.co.uk/temp/Chapter22.pdf

It’s Chapter 22 of a book I wrote mumble years ago, based on an undergrad course I gave. Most of the chapters are on the Scots Guide, but didn’t get around to putting this one there.

Real practical delta-sigma systems are bit (pun alert!) more complicated. e.g. they tend to have a ‘noise generator’ to dither away any idler patterns. There is probably a much fuller explanation in Watkinson’s “Art of Digital Audio” which I’d recommend to anyone interested in digital audio. I only gave it a brief explanation so students had a start-point for learning more if they wished.

Modern pro delta-sigma systems tend to be from 3rd to 7th order I think. IIRC SACD ‘modulators’ and ‘demodulators’ use 5-th order, but Philips/Sony try to keep the details secret to spot naughty people like me from detecting the flaws. 8-]

Jim

(next you’ll be telling me the GPU outputs composite video by reading the framebuffer and directly wiggling the composite video output – not as crazy as it sounds!)

Indeed – AIUI that’s the approach the ZX80 took (albeit with RF output rather than composite). If a 3.25MHz Z80 can do it, I’d imagine a ~300MHz GPU would be able to do it without too much trouble. But I don’t know if that’s the approach they’ve taken (at least on OMAP, composite/S-Video is built into the SOC, without requiring an external DAC)

See also: Acorn cheaping out on a FIFO/DMA for the floppy controller by adding FIQ mode to the ARM.

See also: Acorn cheaping out on a FIFO/DMA for the floppy controller by adding FIQ mode to the ARM.

I had always assumed that was a direct carry over from the Beeb using NMIs to pick bytes from the 8271 disc controller (and later 1770) due to no FIFOs or DMA. When porting ADFS to the ARM it’d have made it less of a translation headache since the early Archimedes also had a 1770 in it. I could imagine the ARM’s design was in some way influenced by the 6502, and the Archimedes the Beeb.

Yes, it was almost certainly influenced by the way disc IO was handled on the Beeb. But I’m fairly certain the main reason for using the CPU in that manner (on both the Beeb and the Arc) was for reducing the cost of the machine (for the Arc I think I picked this up from an interview, but not sure where), rather than for simplifying the job of porting ADFS from the Beeb. Remember that originally the Arc was intended to run ARX, so ADFS compatibility might not have even been on the cards.

And to bring this back round to the Pi, judging by how much effort/hassle is going into the audio and USB drivers, I think it’s clear that the people who call the shots are more interested in reducing hardware costs than about making things easier for the OS developers :-)

Has anyone had a chance to check out the Audio improvements yet?
It would be good to be able to report back on the Pi Forums.

I have an external USB sound card hooked up to the Pi (based on a PCM2704 chip). Unfortunately I’m not sure if RO supports this (I haven’t tried it under RO though but am unsure of RO’s “USB Audio” support status).

At the moment USB Audio support comes from some third party modules that you’d have to softload. However these may not work on an R Pi as behaviour depends on the details of the USB hardware on the host machine. They also aren’t currently playable using the ‘usual’ playing applications.

Again, at the moment, R-Comp and possibly others may be adding the above to their versions of the RO ROM, but not for the R Pi ROM.

You can find some ‘test’ versions of the softloadable version, etc, from my software page

http://www.audiomisc.co.uk/software/index.html

if you wish to experiment. But note that I doubt they work on R Pi and I don’t have one to check. So proceed at your own risk and expect failure.

That said, if you can get it to work, that’s be excellent news.

I should add that the USB module softload linked to from Jim’s website should work on all RO machines. USB audio on my Pi B+ only works with USB1 devices up to 48000/24 without crackles. New faster pi’s may work better but it’s untested.

Apologies. I should have asked Colin about this! I’d thought the modules didn’t work on the RPi.

The demo players linked from my page come with source code. Anyone interested is welcome – in fact, encouraged! – to develop better players. :-)

The ROSSDocument (at http://jcgl.orpheusweb.co.uk/temp/ROSSDocument.pdf ) also explains how to use USB Audio via the API Dave’s module provides.

Jim.

Has anyone confirmed audio_pwm_mode=2 works on RISC OS yet?
A comparison of quality from someone into audio would be useful
More details:
https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=136445&p=911116

Is an HDMI Audio output selectable on the RPi? I don’t have one so don’t even know if it has HDMI! :-)

I ask because I’m getting some success from using an HDMI switch to ‘de embed’ spdif using my ARMX6. Wondering if the results would apply for RPi users.

A Pi defaults to sound output via HDMI if it senses an HDMI monitor connected, a setting in config.txt can force sound via the 3.5mm connector.
It is either sound never both.

Is an HDMI Audio output selectable on the RPi? I don’t have one so don’t even know if it has HDMI! :-)

The Pi does have HDMI – and can do audio over HDMI. You have to modify something in the one of the files on the SD card.

At Wakefield Tony kindly copied an emulator over to my Pi that he already had set up (having suggested a long time before that I try it… but I never got around to it), so I could run Floopy¹ on the Pi. I was a little surprised when I did, and heard the music coming through the not very good monitor speakers.

I remembered after the event that I had changed something in the configuration file to enable audio over HDMI not long after I first got the Pi – but never actually tried it to see if it worked. Clearly, it does. :)

I ask because I’m getting some success from using an HDMI switch to ‘de embed’ spdif using my ARMX6. Wondering if the results would apply for RPi users.

I don’t even know what I suspect are the most important words in that sentence (“‘de embed’ spdif”) mean. :)

¹ Source code long since lost, so only works properly (natively) on anything pre-StrongARM.

A Pi defaults to sound output via HDMI if it senses an HDMI monitor connected, a setting in config.txt can force sound via the 3.5mm connector.

Perhaps I misremembered, then – I thought I’d set it at some point to send audio over HDMI.

By de-embed I mean as follows:

I connected an HDMI ‘switch’ (Monoprice HDX401-TA) so that my ARMX6 fed one of its HDMI inputs and then ran another HDMI cable from the switch’s output to my monitor.

I then setup the system to output audio via HDMI.

Playing audio files with !DigitalCd, the audio now emerges for audio sockets on the switch. I’ve been using the optical digital and coax digital outputs. There is also an analogue output on the switch, but feeding the digital to a DAC I can get good results. This all works at sample rates up to and including 96k. So I can play ‘high rez’ audio as well as CD material, etc, via a decent audio setup.

The ‘de-embed’ refers to being able to get the audio out of the HDMI stream and provide it like this for a hifi amp, etc. In fact this switch lets me play out 96k material at 96k even though my monitor can’t cope with 96k.

I assume the same thing can be done with an RPi. So you can then use such a switch and get the RPi to play out an spdif digital stream for your hifi or amp.

In this case 192k almost worked. So should be possible after some firtling about. However most people mainly want decent audio format (44k1) which will be fine. This process bypasses the tendency of monitors to mess up the audio in various ways.

This is the first time I’ve been able to get a digital audio stream out of an RO machine when playing using !DigitalCD sending to SoundDMA. (I can get it via USB, but only some test players at the moment can play audio via USB.) This means any filetype DCD can play, can be output like this via a digital stream.

Jim