Hi.

I've  been testing Raspberry PI Rev2 512 - Squeezelite-git and MPD and
quite some distros lately.

I had also serious problems to get things going. Pops and clicks do hit
in most occasions.
I also ran into corrupted SD-cards (You'll find roughly a million of
posts about it) 

The main issues:

1. shared USB bus for audio and ethernet (No.1 NOGO) 
2. pretty poor (onboard) powersupply, rails and buffering/filtering ( as
bad as 1.)
3. shielding (EMI/RFI) issues (don't put your RPi close to your router
or mobile phone.)
4. Requires a good external supply
5. External devices only via USB hub
6. requires latest patches to increase stability and to lower danger of
SD corruption
7. requires proper RAM share setup
8. 1+7 can cause  instabillities  and
9. chance to corrupt your SD card
10. no (save) powerup/shutdown button
11. no Toslink and poor internal audio chip ( you will have to use an
external audio device)

For audio purposes I tried distros like PiCoreplayer (based on
Tiny-/MicroCore Linux), RaspiFy, Debian and Arch.

I stayed with Arch, since most other distros are not always leading
edge, up2date and a little complex to maintain. 
Especially Debian based systems are known to be pretty outdated. 
TinyCore Linuxes need a high amount of administration and are rather
inflexible. I couldn't find any advantage in using this one.
My ARCH setup occupied just 8MB more (33MB) then the 25MB PiCoreplayer
footprint.

IMO Arch is the best bet, (alsa better then Fedora/Ubuntu/etc.)
especially if you go the headless route. They ususally have the most
up2date and least complex OS.

squeezelite from git I compiled myself (I highly recommend to to compile
it manually) .


I've been trying the TEAC UD501 (async), Hiface 2 (async)  and AudioGD
DI -V1 ( adaptive USB ). 
All gave me hickups first. It required serious tweaking of HW and SW to
get things rather satisfactory going. 
The best setup was feeding the Teac via SPDIF from Hiface 2. That was
better then RPi->Teac via USB. Just to mention it. 

Squeezelite vs. MPD.

MPD is a "server" and player. I feed data via NFS (do not use Samba/Cifs
on RPI! It requires more resources!) .

In comparision MPD has much less realtime traffic via network going on
compared to squeezelite. Especially when looking at the
shared USB bus this can make a difference. 
Squeezelite requires the continous server interaction and MPD just reads
the files via NFS. This might be improved if you run your input buffer
of squeezelite like a full-file buffer (32Meg or similar). (Triode can
you confirm or explain please -- if the file is fully buffered what will
happen to the network traffic? What happens to gapless playback?)

However. With sqeezelite and PCM streaming I measured a CPU load of
around 1.5%. MPD gave me >3.5% on .wav. More then twice as much.
When running flacs with MPD I had a load of >7.5% !! From that
perspective squeezelite should be the better choice. Very interesting I
found the difference between flac and wav with MPD.

Beside that MPD needs a local webserver running, if you want to use your
cover-arts. 

The rather  basic remote control tools (Android/OSX) of MPD compared to
iPeng are bretty basic. Especially the cover art mess and the radio
station handling of MPD is bugging me most.


What I failed at was getting the resampling properly run. After fiddling
around to get libsoxr lib on my Arch Arm compiled and installed,  I
managed to get squeezelite with resampling  compiled. 
When trying it my RPi ran immediatly out of steam. A NoGo. Trying local
resampling on a RPi is a waste of time --- better do it on the server.


Basically I wouldn't recommend neither the RPi nor MPD. 

Even with my tweaks and rather stabil 44.1/16 operation and a 1.5% CPU
load, you'll always have the feeling to run the RPi on the edge.

IMO the RPI needs a serious HW upgrade respectively redesign. IMO 35$
are too expensive for such a poor performance and design. 

Though wandboards at 125$ without everything (PS/box) are IMO much too
expensive for what they offer.



Wishes @ Triode :

For improved  daemon handling it would be very nice if you could
introduce a --pidfile <file.pid> and --kill option. With these options
handling of the daemon can be much improved in e.g. a systemd
environment.



Cheers



::: ' Touch Toolbox and more' (http://soundcheck-audio.blogspot.com) :::
by soundcheck
------------------------------------------------------------------------
soundcheck's Profile: http://forums.slimdevices.com/member.php?userid=34383
View this thread: http://forums.slimdevices.com/showthread.php?t=97046

_______________________________________________
unix mailing list
[email protected]
http://lists.slimdevices.com/mailman/listinfo/unix

Reply via email to