High-res on RPi3 HDMI

Roon Software Discussion Linux
1

I ‘burned’ Raspbian Lite (latest download) to a clean micro sd card then booted my Raspberry Pi off it. Logged in the Pi then ran the three lines of the Express install i.e. curil…, chmod…, sudo… These appeared to go fine and the last line caused the software to install (arm version). The Pi appears as a Roon device but only 44.1k and 48k are green and the rest of the frequencies are red. I have my Pi connected to my Marantz processor by HDMI. Not surprisingly give the above Roon downsamples anything above 48k and 16 bit. When I use an sd card with PiCoreplayer installed all the HD recordings play at full definition as confirmed by the processor. I have also tried the whole process but with full Raspbian but the result is the same

Can you please advise what I am doing wrong?

Thanks
CJ

1 Like
2

I’d like to join the chorus of thank yous for version 1.2, and am very much enjoying this release.

That said, in my Raspberry Pi experiments, I am running into the same issue reported by CJ. Specifically, I have installed Raspbian Lite on a Raspberry Pi 3, then used the Easy Installer scripts to install Roon on the Pi 3. Miraculously, given my limited Unix skills (haven’t really touched Unix since college in the 80s…and didn’t really know what I was doing with it then…), this worked, and the Pi 3 shows up as a Roon zone on my system. I can play to it but, like CJ, am finding that only 44.1k and 48k are “green,” and anything at higher resolution is downsampled to 44.1k or 48k. 24 bit files are also truncated to 16 bits when I play to the Pi 3. The Pi 3 is hooked up to a Linn Akurate DSM via HDMI, and the Linn is capable of accepting higher resolution PCM via the HDMI input.

Of course, Linn should just support RAAT directly and eliminate the need to plug a $35 Raspberry Pi into their expensive streamer, but in the meantime any help in getting Roon and the Raspberry Pi 3 to cooperate in handling higher resolution files without downsampling/truncating would be welcome.

Thanks,
Stuart

3

Hey guys,

I pulled this out of the other thread because it’s more of a support issue. It’s on my list to investigate in the next couple of days…I’ll let you know what turns up.

4

@CJ1045 @StuartB:

I did some poking around: it appears that the current RPI sound drivers (for on-board sound and HDMI) in Raspbian still limit Alsa to 48kHz. Fixing this would involve applying patches and/or kernel recompiling.

I upgraded my Pi to the 4.4.x kernel branch

sudo BRANCH=next rpi-update

which has these patches already applied. It appears that all rates up to 192kHz are now available on HDMI:

Screen Shot 2016-04-17 at 10.28.19.png1090×1468 70.4 KB

I don’t have the equipment to test, but this will probably work.

One word of warning: the next branch is not a stable release and in active development. If things happen to break, you can revert to the currently supported 4.1.x branch:

sudo rpi-update

@Brian: this is where the most recent action appears to be with HDMI audio on the RPI. They’ve moved on to multichannel, but fixed the bitrate issues first.

2 Likes
5

Rene, you are a legend.

After applying that fix, have you been able to access RoonBridge by WiFi on the Pi3 ?

1 Like
6

Not quite working for me.

Needed to boot off full Raspbian rather than Lite for rpi-update to run. That was fine and it run and seemed to update to 4.4.x just fine. It said the system needed a reboot. I did this but just after auto-login when it fires up the desktop I just get a cursor intermittantly flickering in the top left corner of the screen and the device is not visible in Roon.

Tried a couple of times and the same result. I should say that this is on a RPi 2 if it makes any difference.

CJ

7

@andybob Not quite… :wink: I don’t have a Pi 3 yet, but it should work. I think I’ll order one just for fun.

@CJ1045 I used a Pi 2 as well, with Raspbian Jessie Lite. Can you start over with a fresh Lite image, install RoonBridge the usual way and apply the branch=next rpi-update afterwards?

Lite is plenty sufficient to run RoonBridge and will save you some overhead. If rpi-update is not present by default, you can get it with

sudo apt-get install rpi-update

8

Well again progress but no cigar!!

Clean Raspbian Lite image
Roonbridge install fine
rpi-update not present so figured out how to install it before your edit above
executed rpi-update but failed to write to card as No space left on device!!!

So close but don’t know how to tell the install image to leave more free space on card

CJ

9

Almost there now: it appears you have not told Raspbian to use the full capacity of your SD card:

sudo raspi-config

Choose 1 (Expand Filesystem), finish and reboot. Afterwards you’ll have plenty of space available.

10

That has done the trick, thanks. I now have the higher frequencies enabled.

However, it is truncating to 16 bit rather than let 24 bit and 32 bit through - any ideas on that?

I suspect that I need to tell ALSA to use 32 bit as I do in PiCorePlayer - not sure how in Raspbian Lite yet but am googling it.

Thanks
CJ

11

Rene,

Just a quick thank you! I’ll try this out when I next get some time to fiddle with the Pi 3.

Cheers,
Stuart

12

Interesting – this stuff is clearly not fully baked yet. What happens when you set Max Bits per Sample (PCM) to 24 of 32 in Roon zone settings > Playback? (Probably not much, but it won’t hurt to try).

Can you show your Signal Path in Roon?

13

Roon only gives the options for max bits as disabled or 16 . Neither 24 or 32 bit are shown further in PiCorePlayer there are some ALSA parameters you can enter for Squeezelite - one is the buffer but one is the bit depth and I had that on 32. The Roon settings do not give that as an option.

audio.jpg541×749 53.9 KB

CJ

14

Was afraid so. Output of alsacap does not look better:

Device 1, ID ‘bcm2835 ALSA’, name ‘bcm2835 IEC958/HDMI’, 1 subdevices (1 available)
2…8 channels, sampling rate 44100…192000 Hz
Sample formats: S16_LE
Subdevice 0, name `subdevice #0’

So Alsa only sees 16-bit in this config – and Roon uses what Alsa offers. I’m afraid this is it for now with the Pi. I will look into 24/32-bit, but don’t have much hope for now – all media players (Kodi and the likes) appear to bypass Alsa for highres-over-HDMI, while RoonBridge is dependent on Alsa.

At least it’s never boring. :slight_smile:

15

@RBM, thanks for all of the help here.

all media players (Kodi and the likes) appear to bypass Alsa for highres-over-HDMI

Do you have more information on this?

PiCorePlayer uses ALSA too, as far as I can tell–I toyed around with the Pi’s driver, and from what I can see, if I pump 32bit audio into it using the ALSA speaker-test tool, the hw_params file in procfs reflects S16_LE as the hardware format–that tells me that the driver is truncating silently somewhere in its guts.

RoonBridge reads the devices hardware capabilities as part of its startup sequence in order to determine what format to send. Our goal is always to minimize any conversions that may accidentally happen after RAAT. So we are noticing that the device only does S16_LE and performing the truncation on our end.

Squeezelite works differently–it tries to open the device with the desired format, and is OK with whatever happens if that succeeds. So it probably thinks it’s getting 24 or 32bit output because (as proven by speaker-test) the driver is capable of accepting it, but the driver is throwing away some bits.

Annoying…this isn’t an HDMI limitation or an ALSA limitation. Both are capable of >16bit output–it’s probably just a shortcut someone took in the driver implementation.

16

Why has this been tagged as solved as it isn’t!! How are you determining that the driver is throwing away the bits?

CJ

17

@Richard_Crozier_Jobb It’s called ‘Premature tagging’. :wink: Don’t worry about it.

@brian There’s some wisdom here, including references to media players bypassing Alsa / using omx. It gets interesting near the end.

Agreed on the Squeezelite hypothesis – though someone with the right equipment could probably read out the actual signal going out.

18

As I explained above, I looked at the hw_params in procfs after verifying with speaker-test. None of these are Roon tools–I’m investigating using the normal ALSA tooling + data exposed by the kernel.

Notice that speaker-test says that it is sending S32_LE to the kernel:

speaker-test 1.0.28

Playback device is default
Stream parameters are 192000Hz, S32_LE, 1 channels
Using 16 octaves of pink noise
Rate set to 192000Hz (requested 192000Hz)
Buffer size range from 512 to 32768
Period size range from 512 to 32768
Using max buffer size 32768
Periods = 4
was set period_size = 8192
was set buffer_size = 32768
 0 - Front Left
Time per period = 2.831619
 0 - Front Left

This is what the kernel is reporting in the hw_params for the device while that is going on. This says that the kernel is sending a 16bit stream to the hardware:

access: MMAP_INTERLEAVED
format: S16_LE
subformat: STD
channels: 1
rate: 192000 (192000/1)
period_size: 8192
buffer_size: 32768

@RBM’s alsacap output is consistent with my findings:

Device 1, ID 'bcm2835 ALSA', name 'bcm2835 IEC958/HDMI', 1 subdevices (1 available)
2..8 channels, sampling rate 44100..192000 Hz
Sample formats: S16_LE
Subdevice 0, name `subdevice #0'

Drivers that support 24 or 32 bit output report more sample formats than S16_LE–things like S32_LE, S24_LE, S24_3LE, etc.

What that tells me is: even if Roon sent 32bit audio to this driver, it would be truncated to 16. So there’s no point. There is nothing that we could change in our ALSA implementation to make this work because this limitation is in the driver, not in RoonBridge.

I’m going to keep poking my head in because I’m interested in how this turns out. If it starts to look like this is a problem with RoonBridge, we are interested in fixing it. Right now, it looks like the next step here is to get the driver advertising support for a 24 or 32bit sample format. If that’s fixed and it’s still not working, we’ll certainly have another look.

19

The original driver source (sound/arm/bcm2835-pcm.c) reads:

.formats = SNDRV_PCM_FMTBIT_U8 | SNDRV_PCM_FMTBIT_S16_LE,
.rates = SNDRV_PCM_RATE_CONTINUOUS | SNDRV_PCM_RATE_8000_48000,
.rate_min = 8000,
.rate_max = 48000,
.channels_min = 1,
.channels_max = 2,

Which explains the 48kHz / 16bit limits. The supposed change + recompile is:

.formats = SNDRV_PCM_FMTBIT_U8 | SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S32_LE,
.rates = SNDRV_PCM_RATE_CONTINUOUS | SNDRV_PCM_RATE_8000_192000,
.rate_min = 8000,
.rate_max = 192000,
.channels_min = 1,
.channels_max = 2,

It appears the 4.4.6 kernel has one but not the other – and/or the S32_LE addition is not working as it should.

Source (5th post). Interesting:

I have 192kHz/32bit HDMI audio working with kernel 3.2.27+. I tried 24bit but no go, decided 32bit was good enough, just zero the least significant byte and get 24bits.

1 Like
20

Frustratingly my processor only shows the frequency of the stream and not the bit depth.

However, it was showing 192kHz when playing from the Raspberry Pi using a standard PiCorePlayer install and regular kernel. I did not need to ‘upgrade’ the Kernel for 192kHz music to play at 192 kHz. It does seem, therefore, that it sidesteps the bcm driver (if I am using the correct terms). Roonbridge would not do the same thing.

CJ