advertisement


Raspberry Pi as headless streamer

I am waiting for Wandboard hardware and started to play with Raspberry Pi.

piCorePlayer installation and configuration was very easy and it was very fast integrated in my Squeezebox world. It recognized my WaveIO/I2S/Buffalo without any problems.

At the begining the sq was not so good, but when i connected my diy ps with TeddySuperreg (which i made for my SBT), than the sound became very nice. Probably the small switched ps was very nasty and was poisoning everything.

Than i set some squeezelite parameters:

realtimepriority=70
alsabuffer = 32
periods =4
output bit depth = 24
streaming buffer input = 2048
streaming buffer output = 2048

I restarted squeezelite after each parameter change and IMHO the difference is small, but noticeable.

Those parameters where adviced by Soundcheck to run squeezelite on SBT instead of the jive(?) graphic gui interface.

The sound now is really good. Today is to late to compare it with my SBT and Daphile and squeezelite running on notebook with thin Linux with rt kernel, but i already know, that it will be one difficult task ...

It is crazy, that something so cheap and so small sounds so good. :D

My USB cable (Supra) connecting Pi with WaveIO was more expensive than Pi ...

But we don't want any new discussion about USB cables here and please do not ask me if i did blind ABX tests ...
 
Today with few friends after few hours of tests comparing Pi, SBT and Daphile i (and my friends) we have doubts.

Raspberry Pi + Picoreplayer (wired, no wifi) with diy Teddy ps (very important) and WaveIO/Buffalo 2 is a killer and the DAC feeded by Pi sounds better than with SBT or Notebook/Daphile.

The LMS server runs on Lenovo Notebook with W8 64 pro + fidelizer, all files are waves, so there is no decompressing on server or Pi, network connection is wired with small separated Cisco switch dedicated only for streaming.

I don't understand ...

added later - 16/44 causes ~80% of CPU load on Pi, when playing 24/96, than squeezelite causes 95% load, so it is not the player for hd audio, be aware :)

added alter - when i turned off the alsa memory management, than even playing 24/96 causes no more than 70% load.

My alsa settings now are 32:4:24:0 , before it was 32:4:24:1, 1 at the end means mmap on.
 
tomek said:
all files are waves
Click to expand...

There have been measurements (by Archimago) showing that at least the SBT (and probably the RPI too) has to work harder transferring the nearly double amount of data implied by wav files compared to decoding flac files on the fly.
 
Tomek,
are you aware you can take I2S directly off the Raspberry board? Thereby eliminating one step inbetween (the WaveIO). Have a look around the "HifiBerry" Page, they describe where to get the I2S from there. (it sounds easy to do).

Where and how do you see the CPU load of the Raspberry?

I hope I find some time to follow your listening test this coming week, the initial comparison was strongly in favor of Daphile, but no fancy power supplies were involved yet.

Cheers,
 
Bemused said:
Have you over clocked the Rpi
Click to expand...

No, i just used the piCoreplayer image without overclocking.

Now i turned mmap on, sounds better, playing 24/96 is without xruns, only 24/88.2 makes even higher load (why ?).

Anyway, i am waiting for Wandboard, but Pi is one nice exercise :)

Playing waves cause more load, but it is steady load, decompresiing on the fly causes more irregular load, maybe this makes more damage to regular data flow.

Make a test - copy one big file from network to your computer and look at cpu load, it will be steady. Than compress this file and decompress, you will see more cpu load peaks.

I tested it many times, for my ears playing waves from LMS sounds very little better, than playing flacs, even when they will be decompressed on the server side on the fly before sending them to SBT.

You can read more about setting properly the LMS here :
http://soundcheck-audio.blogspot.de/2011/11/touch-toolbox-30.html

you have to scroll down to IV. Modifications and Setup, 1. Logitech Media Server Setup

:)
 
@Topa - to see cpu load, you have to make ssh login on pi and then there is a programm called "top" showing actual cpu, ram etc load.

When playing the music you see in "top" the line with "squeezelite", this is the squeezelite process, even when you are not playing music, there will be load, because then squeezelite is sending nulls to dac to prevent clicks.

top is actually on nearly every Linux system and helps to see what is going on.
 
Code: 
top - 14:34:00 up 13 min,  1 user,  load average: 1.52, 1.61, 1.13
Tasks:  68 total,   2 running,  66 sleeping,   0 stopped,   0 zombie
%Cpu(s): 94.2 us,  3.6 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  2.3 si,  0.0 st
KiB Mem:    448776 total,   328844 used,   119932 free,    13948 buffers
KiB Swap:   102396 total,        0 used,   102396 free,   199808 cached

  PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+  COMMAND                                                                                                                                        
 2343 squeezeb  20   0  6220 2168 1308 R  81.5  0.5   6:15.11 sox                                                                                                                                            
 2234 squeezeb  20   0  121m  90m 5740 S  12.4 20.7   2:09.50 squeezeboxserve                                                                                                                                
 2342 squeezeb  20   0  5572  848  604 S   5.2  0.2   0:24.56 flac                                                                                                                                           
 2323 pi        20   0  9800 1640 1008 S   0.7  0.4   0:00.19 sshd                                                                                                                                           
 2347 pi        20   0  4688 1420 1024 R   0.7  0.3   0:00.07 top                                                                                                                                            
 2346 root      20   0     0    0    0 S   0.3  0.0   0:00.26 kworker/0:2                                                                                                                                    
    1 root      20   0  2144  728  620 S   0.0  0.2   0:01.80 init

top output
 
Bemused said:
Tomek, re 24/96. You sure its not down sampling, is Sox running?
Click to expand...

i don't see a sox process, only squeezelite and i didn't touched any upsampling options.
bit depth in alsa is set to 24 bit, but when i set it to standard, than the load doesn't change.

Mem: 67980K used, 411992K free, 0K shrd, 5448K buff, 29484K cached
CPU: 49.7% usr 23.8% sys 0.0% nic 18.6% idle 0.0% io 0.0% irq 7.6% sirq
Load average: 2.42 2.21 2.27 1/81 2307
PID PPID USER STAT VSZ %VSZ CPU %CPU COMMAND
2250 1 root S 10876 2.2 0 80.3 /mnt/mmcblk0p2/tce/squeezelite-arm
2307 2126 tc R 3016 0.6 0 0.4 top
2122 1892 root S 2900 0.6 0 0.2 /usr/local/bin/dropbear -w -g -b /
3 2 root RW 0 0.0 0 0.2 [ksoftirqd/0]
18 2 root SW 0 0.0 0 0.2 [kworker/0:1]
2126 2122 tc S 3016 0.6 0 0.0 -sh
1870 1 tc S 3016 0.6 0 0.0 -sh
1 0 root S 2932 0.6 0 0.0 init
2040 1 root S 2932 0.6 0 0.0 /sbin/udhcpc -b -i eth0 -x hostnam
1892 1 root S 2360 0.4 0 0.0 /usr/local/bin/dropbear -w -g -b /
90 1 root S 1912 0.4 0 0.0 /sbin/udevd --daemon
1540 90 root S 1908 0.4 0 0.0 /sbin/udevd --daemon
1541 90 root S 1908 0.4 0 0.0 /sbin/udevd --daemon
63 2 root SW 0 0.0 0 0.0 [kworker/u2:2]
68 2 root SW 0 0.0 0 0.0 [mmcqd/0]
7 2 root SW 0 0.0 0 0.0 [rcu_preempt]
17 2 root SW 0 0.0 0 0.0 [khubd]
20 2 root RW 0 0.0 0 0.0 [kworker/u2:1]
1080 2 root SW< 0 0.0 0 0.0 [loop21]
11 2 root SW 0 0.0 0 0.0 [kdevtmpfs]

Little wondering about this high cpu usage, without "mmap on" load is lower, but still high.
 
Julf said:
You have sox running and using a lot of cpu, so clearly some resampling going on.
Click to expand...

Sox is not resampling, unless you will configure it extra for it, or you want to play hd files on SB Radio which accepts only max. 48KHz, so 96 will be downsapled into 48, i don't think Bemused is playing SB Radio ...

On LMS server sox is used mostly for some other things:

1. When you are playing flac and you want to decompress it on server and not on the player, then sox is converting flac into wav on the fly and is sending wav to player, depends on LMS setting. Many people are doing so, because they believe ( or hear) that SBT sounds better with this setting.

2. When you play wav, than the standard setting is, that sox will compress it into flac and flac is sended to the player, than player is decompressing flac into wav/pcm. In this way the network traffic is minimzed (important for wlan), but you have extra sox process on the server and on the player.
Advice is to send wav as wav, in this way sox process on server and player will not cause any system load and influence the data flow.

I suppose Bemused is playing flacs and this is the reason for sox process.

3. When you play strange formats like vorbis, than sox will convert on the fly into something, that SBT understand.
 
tomek said:
i don't see a sox process, only squeezelite and i didn't touched any upsampling options.
...
bit depth in alsa is set to 24 bit
Click to expand...

If you're forcing a bit depth in Alsa I think you're forcing resampling. I know that when using the MPD music server the only way to achieve bit perfect sound without resampling is to configure it to bypass the mixer entirely. This means you get no software dithering, no volume control, and Alsa adjusts automatically to the bitrate of the file being played; i.e it sets itself to 96kHz, 44.1kHz, etc depending on your FLAC.

I'd look into the appropriate configuration options to disable all software mixing, etc and ensure that the mixer is either "hardware" or "disabled".

Having said all that, I don't know the squeezebox system very well (it's a couple of years since I abandoned it) and this is all based off the MPD system, which is amazing and (I think) much better than the squeezebox stuff.
 
Yes, i found it now. Bit depth 24 bit is causing the higher load. With standard alsa settings 80:::0 the load for 16/44 is less than 5%, for 24/96 is ~15%, when i am setting 80::24:0, than the load is ~70% and 90%.

Interesting is, that SBT inside is doing 16->24 bit to allow volume regulation without loss of the quality - over 80% of the volume we have still 16Bit resolution, i wanted the same here :), but i am not upsampling to higher frequences. SBT is using probably better alghorithm, and the load is not so big.
 
tomek said:
I suppose Bemused is playing flacs and this is the reason for sox process.
Click to expand...

Was that a typo? When playing flacs (and when configured for default behaviour) sox would not have to do any re-encoding work.
 
Julf said:
Was that a typo? When playing flacs (and when configured for default behaviour) sox would not have to do any re-encoding work.
Click to expand...

When you play flac and you want send wav to SBT, than sox has to decompress flac on the server, in this way it is sox process on the server and no sox on SBT.

With standard setting the server playing flac is sending flac to sbt and sbt is decompressing flac into wav/pcm, in this way you have less network traffic, no sox on server, but sox on sbt (or pi).

You can read more here :

http://soundcheck-audio.blogspot.de/2011/11/touch-toolbox-30.html
you have to scroll down to IV. Modifications and Setup, 1. Logitech Media Server Setup
 
So, i did more research, what is causing so much squeezelite CPU load on pi.

I was changing paramaters step by step.

1. Original settings, using built pi soundcard: 2-5%
2. Changing different settings (-p 70, alsa 32:4:24:1 etc) when using built in card is causing very little load changes.
2. Using WaveIO USB instead of pi soundcard: jump up to ~42%
3. Changing different alsa settings like alsa buffer, period count and bit depth IS not causing any additional load when using WaveIO. With alsa 32:4:24:0 it is still 42%
4. Turning on alsa memory management (better sound) - jump up to 90%
5. setting max. sampling frequency to 96000 - drop to 80%.
6. turning off alsa mmap 32:4:24:0 - drop to ~42% load

So i suppose, that when we are connecting WAveIO, than squeezelite is discovering WaveIO as 24/192 DAC and is probably sending 24/192 ? into dac, when i set sampling frequency to 96, than it is sending 24/96, thats why the cpu load is going from 90 to ~80%.

Hmm, strange, i was hoping that squeezelite when playing 44.1 is sending 44.1 to DAC, but it looks liks it sending 24/192, or 24/96 when i am setting max. frequency to 96, but i would like to have original values going into my DAC and leave DAC doing the rest ...

I want 24 bit depth, but changing sampling frequency ?

I have to write a letter to the developper, maybe it is something else.
 
Julf said:
You have sox running and using a lot of cpu, so clearly some resampling going on.
Click to expand...

The top output I posted was only an example that I grabbed for illustrative purposes regarding Topa whom enquired about how to see Linux CPU activity.
It was from an old thread when I tried to run LMS on an Rpi with Sox.
 
You must log in or register to reply here.


advertisement


Back
Top