Print

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

[Hilton]

Hi,

I'm a little determined to try and get SACD (DSD) decoding smoothly on the Pi2.
I captured some different stats of different file types playing and noted one anomaly between SACD and every other format.

The disk I/O is very low and I believe not getting enough thread priority to keep the buffer full.
Only seeing 300-500K/s reads with SACD compared with 1.6-3MB/s for other files.  Even when it's just buffering and not playing, the disk I/O never gets above 500K/s which is never going to be fast enough to keep the buffer full.  The I/O subsystem of the Pi2 is capable of a Raw 30MB/s from my disk and I can see it hit 6MB/s and higher when your scrolling through thumbnails on JRemote, so I know it can provide better throughput.
Maybe there's a bottleneck somewhere in the code for the SACD ISO reading that's throttling disk I/O? Of course it could be just the process thread being pegged at 100% but I don't know the inner workings of your code.

I know the decode/transcode thread is being smashed, but I was wondering if you can move the I/O or ISO reading to it's own thread whether that might improve things?
I understand it may not be possible and something we're stuck with due to the processing power of the Pi but thought I'd throw this out there just incase you can do something with it.

I ran HTOP and IOTOP with a bcmstat script to try see whats going on across all file types.
I didn't bother with MP3 because we all know it can do that with a couple cores tied behind it's back!

Native 44.1K FLAC - no transcode no DSP (bit perfect to my E17 DAC)


Native 96K FLAC - no transcode no DSP (bit perfect to my E17 DAC)


2ch SACD transcode to 96K - shot 1


2ch SACD transcode to 96K - shot 2

[bob]

The use of threads for particular tasks is probably a question for Matt (who just left for a vacation).

I can tell you though that the linux builds do not do thread priority since elevating thread priority requires root privileges.
We could map that to lowering privileges but haven't done so yet.

[Hendrik]

Audio decoding itself is usually not multi-threaded, although decoding and processing tend to run on different threads.
Not sure that moving IO to a different thread is going to help much. I imagine most of the CPU (as is 99%) going to decoding anyway.

I looked into multi-threading DSD decoding at some time, since all channels in a DSD are coded independently, you could just run one thread per channel without too much problems, but the overhead from that did seem to negate any performance improvements.

[bob]

I tried playing SACD on an original Core solo Mac Mini 1.5 ghz and it won't keep up either (it has thread priorities enabled).
The cpu is running 100%.
JRMark is 586

[Hilton]

It's not all bad news!
The Pi can push SACD from its local library to a MC20 client for decoding on the client. Crossfade works too.

It uses about 25-30% on 2 cores (~40%) that means if you can get a DSD DAC to work on the Pi you can theoretically play DSD to a local USB DSD DAC bit perfect.

Cross fading pushes CPU to 50% on 2 cores.

[bob]

It's not all bad news!
The Pi can push SACD from its local library to a MC20 client for decoding on the client. Crossfade works too.

It uses about 25-30% on 2 cores (~40%) that means if you can get a DSD DAC to work on the Pi you can theoretically play DSD to a local USB DSD DAC bit perfect.

Cross fading pushes CPU to 50% on 2 cores.

Cross fading is one of my pet peeves. It's the first thing I turn off!