File-based audio playback - compressed vs. uncompressed

[bobbasrah]

If there is any sound difference due to processor use, would this not be shown up by encoding a track at different compression levels and comparing the result?

My recollection of Flac was that decode loading is virtually the same, it is the encode that loads the processor, but I may be mistaken Ali...

[AlexM]

Chris,

Good data - thanks for that. I'll comment on the TOP figures in a bit.

What leaps out at me is that CPU utilisation seems to be higher when playing Hi-Res LPCM than when playing Hi-Res FLAC. It seems that managing data coming over the network interface is a greater CPU overhead than decoding the FLACS - I didn't expect that!. Just to clarify, where you say 'PCM file downloaded to SBT as PCM' do you mean that the source FLAC was decoded to PCM by the server, or by you off-line?. What was your subjective experience?.
Cheers,
Alex

[Chops]

That is 12-14% playing a 24/88 FLAC with server decoding to WAV, and 20-27% with FLAC decoding on the SB Touch.

Alex, was that total CPU time or one of the components such as usr? My observations are a bit different, ie for the 24/88.1 track:

• WAV (PCM) on the SBT, total CPU 80-90%
• FLAC on the SBT, total CPU 55-65%

I bought the file as FLAC and converted to PCM in Foobar.


Quite a difference! Hope I haven't missed something?



Chris

[Chops]

It seems that managing data coming over the network interface is a greater CPU overhead than decoding the FLACS - I didn't expect that!

Agreed. I was quite surprised. On the basis of that, I'm wondering about going back to delivering FLAC files to the SBT and ignore the subject of this thread.

Chris

[AlexM]

Alex, was that total CPU time or one of the components such as usr? My observations are a bit different, ie for the 24/88.1 track:

• WAV (PCM) on the SBT, total CPU 80-90%
• FLAC on the SBT, total CPU 55-65%

I bought the file as FLAC and converted to PCM in Foobar.


Quite a difference! Hope I haven't missed something?

Chris

Chris,

below is my top screenshot while playing Mozart Symphony No. 38 in D major (‘Prague’), K.504 - I Adagio - Allegro - Scottish Chamber Orchestra, Linn (same as you!).

I was misinterpreting what we are seeing, so scratch my previous comments.

The CPU is CPU utilisaton at the time of the last screen refresh, split by process type. process %CPU refers to the percentage of the CPU cycles used by a process since the last screen repaint, excluding idle time (I think). My CPU utilisation for usr processes does range from 20-27 percentage (mainly JIVE), averaging 22% while playing this piece of music, without transcoding on the server. Idle time is 20-38%.

CPU utilisation with the same music does seem to be quite a bit higher when streaming PCM from the server. I conclude that I will go back to streaming FLAC, and that FLAC decoding is pretty light-weight!.

Cheers,
Alex

Mem: 76776K used, 49072K free, 0K shrd, 8736K buff, 19416K cached
CPU: 24% usr 11% sys 0% nic 18% idle 0% io 4% irq 41% sirq
Load average: 3.07 2.06 1.68 4/70 862
PID PPID USER STAT VSZ %MEM %CPU COMMAND
7 2 root SW< 0 0% 33% [sirq-net-rx/0]
731 1 root R 42440 34% 27% /usr/bin/jive
771 731 root S 7148 6% 9% jive_alsa -d hw:0,0 -c default -b 3400 -p 2 -s 24 -f 3
9 2 root SW< 0 0% 7% [sirq-tasklet/0]
49 2 root SW< 0 0% 2% [IRQ-34]
258 2 root SW< 0 0% 2% [IRQ-57]
862 861 root R 2728 2% 0% top
5 2 root SW< 0 0% 0% [sirq-timer/0]
860 635 root S 2532 2% 0% dropbear -i
635 1 root S 2808 2% 0% /usr/sbin/inetd
615 1 root S 2732 2% 0% /sbin/syslogd -S
.
.
.

[Vincent Kars]

Is this testing done using WiFi or is it Ethernet?

[bobbasrah]

Holy Toyah Wilcox...Itth a mithtawee....

[synsei]

[AlexM]

Is this testing done using WiFi or is it Ethernet?

Ethernet only in my case!

[Chops]

Alex, looks like you have 0% idle, ie the CPU is fully utilised. What sample rate did you use in top?

I've attached the top output from the same on my system. ssh.jpg. It show 7% idle (93% busy). I've found this varies according to what part of the piece you're playing, so later in this movement has a lower idle rate.

Have you applied the soundcheck mods? They change some process priorities. I think the effect of this will be that if there's CPU available (ie %idle > 0) then any process requiring it will get what it wants, but if there's a shortage then those with a higher priority win out. Now, even with a 2 sec sample rate in top, you wont see the real transient peaks in CPU demand - the 2 sec sample will smooth them out. If %idle is getting low (and I'm not sure what that figure is) then SQ could very well be affected.

Just to summarise what I think this means.

• 16/44.1 files appear to be dealt with comfortably by the SBT regardless of whether FLAC or PCM. This doesn't answer the debate about the ability of the DAC to convert them equivalently.
• With hi-res files, the SBT appears to become more stretched, especially PCM. The higher the resolution, the more this is apparant. Even the Pergolesi FLAC file showed 0% idle on a 2 sec sample, although generally it was >10%. This may affect SQ when the device runs out of processing power (here I will defer to someone with greater expertise of how SqueezeOs deals with this kind of situation). This could inform the debate about SQ of FLAC vs PCM.

Chris