Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[hans4712]

Hardware: I have a Raspberry 4 with 4Gb, clocked at 2000 MHz, with the lastest raspOS, on JRiver 27. I use the HDMI output of the Raspberry to my AVR-9.1 receiver.

Playback problem:
with .dsf files or .dff files with 7.1 or 5.1 channels, the playback always stops every few seconds and "buffering ..." appears., and the cpu is very busy for a short time, then the Raspberry plays a few seconds again ( cpu more or less normally busy), then playback stop again, "buffering ..." and cpu again briefly busy. So a playback with constant buffering and "reloading".

All music formats are routed through HDMI as standard, provided that the receiver decodes them directly (most of them), some files (too high bit rate / bit depth) have to be decoded by the driver so that the receiver can play them.

The same files (dsf / dff / dsd 7.1 channel) can be played back on the pc without any problems via hdmi to my receiver! However, from the raspberry to the receiver via hdmi there are problems outlined above.

my question:
1) is it due to the hardware (Cpu) of the Rasbperry?
2) Is my external hard drive too slow on the USb or the Raspberry does not like the UASP?
3) is it due to the audio processor of the raspberry 4b?

please help me find the cause.

[Awesome Donkey]

Since you're outputting via HDMI you're likely converting the DSD to PCM on-the-fly, since it's not possible to bitstream DSD via HDMI from any computer, which is likely the cause of your issue (as DSD to PCM conversions are resource heavy operations). Your described symptoms are exactly what happens when this is the case.

Your first question is the correct assumption, if you're doing on-the-fly DSD to PCM conversions the Raspberry Pi is not powerful enough to handle it. Basically the Pi is trying to do the on-the-fly conversion and play it back at the same time, but it's not fast enough to keep ahead of current playback position, so when it reaches the point where there's not enough buffered it'll stop and buffer until it can convert more of it to resume playback, only for it to happen again.

If you need to do on-the-fly DSD to PCM conversions, it'd be best to avoid using a Raspberry Pi.

[hans4712]

Since you're outputting via HDMI you're likely converting the DSD to PCM on-the-fly, since it's not possible to bitstream DSD via HDMI from any computer, which is likely the cause of your issue (as DSD to PCM conversions are resource heavy operations). Your described symptoms are exactly what happens when this is the case.

Your first question is the correct assumption, if you're doing on-the-fly DSD to PCM conversions the Raspberry Pi is not powerful enough to handle it. Basically the Pi is trying to do the on-the-fly conversion and play it back at the same time, but it's not fast enough to keep ahead of current playback position, so when it reaches the point where there's not enough buffered it'll stop and buffer until it can convert more of it to resume playback, only for it to happen again.

If you need to do on-the-fly DSD to PCM conversions, it'd be best to avoid using a Raspberry Pi.

thanks for your quick reply.
Does it make sense to take the latest raspberry with 8Gb (instead of 4gb) and 64bit RaspOS (instead of 32bit) and tack a little higher, or does it seem completely pointless because the computing power of the Raspberry is too weak to decode DSD ? (The raspberry / JRiver does not have to decode everything and everything. DSD64 works via bitstream, e.g. but some files have a very high bit rate / bit depth because a bit has to be decoded e.g. from 192,000hz down to 96,000 then the receiver takes this directly via bitstream.

[Awesome Donkey]

Nope. The Raspberry Pi, even the Pi 4 model B 8GB with 64-bit Raspberry Pi OS is still not powerful enough. No Raspberry Pi is powerful enough to handle it. It's too weak.

Also like I said, you can't bitstream DSD over HDMI via any computer so it has to convert it to PCM and output that to play it back on the receiver. It's that unavoidable conversion (with your current setup) which is causing your issues because the Pi can't handle it. DSD to PCM conversions (or PCM to DSD conversions), especially multichannel conversions, are the most resource intensive tasks Media Center can do requiring a pretty decent CPU to handle it, which all Raspberry Pis lack.

If you had a DSD-capable USB DAC connected via USB to the Raspberry Pi and you output all audio and bitstreamed DSD to that, it would avoid the conversion (unless you're converting PCM to DSD, which isn't going to work with a Pi). From there you can output from the USB DAC to your receiver. But DSD converted to PCM output via HDMI to a receiver from a Raspberry Pi isn't going to be an enjoyable experience at all because of the Pi's bottleneck.

Hopefully that makes sense.

[hans4712]

Nope. The Raspberry Pi, even the Pi 4 model B 8GB with 64-bit Raspberry Pi OS is still not powerful enough. No Raspberry Pi is powerful enough to handle it. It's too weak.

Also like I said, you can't bitstream DSD over HDMI via any computer so it has to convert it to PCM and output that to play it back on the receiver. It's that unavoidable conversion (with your current setup) which is causing your issues because the Pi can't handle it. DSD to PCM conversions (or PCM to DSD conversions), especially multichannel conversions, are the most resource intensive tasks Media Center can do requiring a pretty decent CPU to handle it, which all Raspberry Pis lack.

If you had a DSD-capable USB DAC connected via USB to the Raspberry Pi and you output all audio and bitstreamed DSD to that, it would avoid the conversion (unless you're converting PCM to DSD, which isn't going to work with a Pi). From there you can output from the USB DAC to your receiver. But DSD converted to PCM output via HDMI to a receiver from a Raspberry Pi isn't going to be an enjoyable experience at all because of the Pi's bottleneck.

Hopefully that makes sense.

in the long term I have to get an Intel Nuc anyway. just thought if I have a raspberry anyway, I'll try it. an intel nuc would of course be better suited for "audiophiles" (sacd) anyway. there is probably no way around it. * smile *

as a second device I can keep the raspberry as a mini music server to play simple flac with 7.1 or stereo 2.0. in another room e.g.

many thanks you for the clear information. 

[hans4712]

If you had a DSD-capable USB DAC connected via USB to the Raspberry Pi and you output all audio and bitstreamed DSD to that, it would avoid the conversion (unless you're converting PCM to DSD, which isn't going to work with a Pi). From there you can output from the USB DAC to your receiver. But DSD converted to PCM output via HDMI to a receiver from a Raspberry Pi isn't going to be an enjoyable experience at all because of the Pi's bottleneck.

Hopefully that makes sense.

i will most likely get a mini pc and send the signal via hdmi directly to the receiver via bitstream. Ac3 e.g. The receiver decodes files in multichannel itself, as well as all of the bluray soundtracks. SACD files (dsf / dsd / dff) unfortunately have to be decoded by the mini-pc / jriver to such an extent that the receiver accepts this. some files have to be downscaled from 192,000hz to 96,000hz in order to be decoded by the receiver. Much is possible via bitstream and "hdmi trough", but of course not everything.

I had of course already considered such a mini-pc in the living room and an external dac, but you often think about it, move it and then play around with a raspberry. these raspberries are not bad. but now I seem to be completely in line. it won't work with the raspberry.

I don't know if you happen to know that, but can a mini pc like the intel nuc (sorry actually don't want to advertise here) also output via hdmi 9.1 or 11.1? Shouldn't it work theoretically? Or could it shine on the hardware of the mini-pc? (Good is a bit heavy because it's already heading towards auro and dolby atmos)

[Dennis in FL]

Since you're outputting via HDMI you're likely converting the DSD to PCM on-the-fly, since it's not possible to bitstream DSD via HDMI from any computer, which is likely the cause of your issue (as DSD to PCM conversions are resource heavy operations). Your described symptoms are exactly what happens when this is the case.

I also have  a Raspberry 4 with 4Gb with the lastest raspOS and MC27 on SSD. I also use the HDMI output of the Raspberry to my Marantz 6013 receiver

I don't have audio problems with SACD --- I'm listening to some Jazz right now (see screen shot)

[Awesome Donkey]

Since it's stereo, the Pi 4 might barely be fast enough to handle the on-the-fly conversion. But since you're using HDMI output, it is converting DSD to PCM.

[Dennis in FL]

I forgot to add --- My main library is on an desktop iMac external HDD.   The Raspi MC gets the music from the Mac MC library over WiFi.  My receiver is reporting the source at 44.1kHz PCM.   

And - I increased my Raspi swap file to 1024 (but when I ran off a SD card and the default buffers - it was also OK)

[Awesome Donkey]

Even so, I still wouldn't recommend using a Raspberry Pi for DSD to PCM (or PCM to DSD) conversions.

[Dennis in FL]

Even so, I still wouldn't recommend using a Raspberry Pi for DSD to PCM (or PCM to DSD) conversions.

I just gave a longer test....an hour of DSD playback through HDMI.....and sure enough I had a long dropout.....maybe 10 seconds. 

I haven't tried overclocking but I can easily switch to a USB DAC and try again.   

PS:  Has anyone tried Windows 10 WOR on a Raspi 4 with JRiver?  Does it work?

[Wheaten]

Haven't tried it, as far as I am aware:
ethernet, Wifi and Bluetooth will not work.
It performs the same like an atom processor, So I doubt it will be suitable to run JRiver in a decent matter.

https://www.tomshardware.com/how-to/install-windows-10-raspberry-pi
 

[Dennis in FL]

Haven't tried it, as far as I am aware:
ethernet, Wifi and Bluetooth will not work.
It performs the same like an atom processor, So I doubt it will be suitable to run JRiver in a decent matter.

https://www.tomshardware.com/how-to/install-windows-10-raspberry-pi

I believe you can put a splitter on USB-C ( https://youtu.be/h0_kEV-gdtI ) and get around some of that...or use a Raspi 3.   I was curious - not as to actually using it but from a geeky perspective.

[Wheaten]

Then just try it and let me know 

[tdot]

In my opinion, it is best to go with the standard topology and separate the server and the endpoint.  The server does all the heavy lifting (conversion, upsampling, etc.) and the endpoint's only job is to receive data and send the output to the DAC.

I use my gamer's PC as an MC server, and a cheap used Atom CPU fanless Windows 10 pc (Minix brand) as my endpoint.  It works like a charm.  Raspberry Pi should be the same.

[Dennis in FL]

In my opinion, it is best to go with the standard topology and separate the server and the endpoint.  The server does all the heavy lifting (conversion, upsampling, etc.) and the endpoint's only job is to receive data and send the output to the DAC.

I use my gamer's PC as an MC server, and a cheap used Atom CPU fanless Windows 10 pc (Minix brand) as my endpoint.  It works like a charm.  Raspberry Pi should be the same.

That's similar to my setup except I have an HDMI output from the Raspi and I get occasional dropouts with DSD playback.   I have the server on my iMac and I also have a DAC from the Mac to the reciever.   I'm going to rearrange it so the Raspi has the DAC ..  and see if I still get dropouts.   

[Awesome Donkey]

Well, if you're using HDMI you likely will, because you can't playback DSD over HDMI from a computer without converting it to PCM (which is where and why the dropouts occur). The Pi isn't fast enough to handle the DSD to PCM conversion so you'll encounter dropouts.

Now, if you have a DSD-capable DAC directly connected to a Raspberry Pi via USB (or DoPE via DLNA/ethernet if that's supported) and you're using DSD bitstreaming in MC, that shouldn't have issues with dropouts.

[Dennis in FL]

Understood.

I have a Oppo HA-2 DAC ready to go.   

[jlee700]

I also had dropout issues on my rpi4, which got fixed when I checked “Disable audio buffer to disk” in options/Media Network. Maybe worth a try?