Monday, September 2, 2013
Bake me some Pi - perhaps a Raspberry Pi !?!?
I had some discussions on the RaspiFy thread at DIY-Audio questioning the quality of the RPi as a rather serious audioserver/streaming client earlier this year.
My rather negative position related to the chosen (cheap) HW platform first of all.
Obviously the RaspiFy designers were not that happy about pointing out my opinion about it.
They quickly promised to provide images for different ARM HW platforms sooner or later.
The RaspiFy folks use the term "audiophile". The term "Audiophile" has a certain meaning to me. Obviously most parties who put together some apps and a bit of system tuning use it as hook for selling/marketing purposes nowadays.
When looking at the chosen HW, it couldn't be anything more then marketing from my perspective.
At least that's how I positioned myself towards them, without ever having a RPi in my hands... ...at that point in time.
Of course I had to face comments like "you're promoting ARM devices (Squeezebox Touch) since years and an RPi wouldn't be any different". Hmmh. Wait a minute.
These Logitech devices were build for audio purposes only. These were not built as general
purpose toys targeted for mainly educational purposes.
Not to forget. I didn't promote Logitech products as such, not intentionally at least.
I rather promoted ""modified"" Logitech products -- my "Touch Toolbox " instead.
A Squeezebox Touch IMO needed heavy HW and SW modifications to sound excellent,
There are still people out there who still think (or sell) just SW tweaks get you into "Audiophile" spheres. People tend to forget that it is always a mix of HW and SW making the solution.
And at least from experience I can tell, that the worse the HW, the more SW tweaks will have an impact and the better the HW the less impact you'll see from software optimisations. Of course there are systems and ears that do not exeperience anything from anything. There's a reason for everything.
And that we have that disucssion at all, is mainly related to the fact that almost any DAC, at any price, out there can not cope with "a little jitter and noise" caused by the transport. The manufacturers of audio interfaces need to be blamed to fail in getting the mess under control
after a half a decade ignoring and another half a decade of fiddling around with it. They are asking thousands of $ for audiodevices and do not even have the input section under control.
Anyhow. Back to this project.
For the time being I left "audiophile" RaspyFi alone.
Mainly because they use MPD.
I do have plenty of experience with MPD (see 2007 -- Linux Audio The Way to Go thread.)
MPD is a local headless player, or better, server first of all. It can't really be compared with a streaming network/client like squeezelite.
The remote control apps (Android/OSX) are not comparable to iPeng
or Orange Squeeze on Android.
And then I'd need to run a local webserver on the RPi to be able to fetch my cover-arts from local file folders.
The only argument PRO MPD would have been its DSD playback capability.
(I btw tested the whole thing. Just to make sure. I tested functionality, performance and soundquality and even spent money for those rather simplistic control apps on iOS and Android.
Conclusion: At this point in time not anybody could convince me to stay with MPD)
This led me to PiCorePlayer.
I installed PiCoreplayer first. That one uses famous Squeezelite and MicroCore Linux.
I know TinyCore Linux (same family as MicroCore) from the past. It comes with a very small footprint and resides 100% in RAM (25MB). Changed data can be made persistent at shutdown.
In case you have a HW failure or unexpected Powerdown, all actual changes will be gone.
On the TinyCore OS side I found managing apps was driving me nuts. Keeping it up2date becomes a nightmare. Something like PiCorePlayer is IMO a "take-it-as-it-is" or "leave it" choice.
Otherwise you'll burn endless hours of waiting for the designer to do some corrections, updates or hacking.
The first thing that happened with PiCorePlayer after 3 times power up/power-down was a corrupted SD-card. I don't want to blame PiCorePlayer for this mess at this point.
I googled "RPi corrupted SD cards". I found endless threads about SD-card corruption issues. Some blamed poor PS, some blamed poor drivers or kernels, others blamed SD-card accesses or the SD-cards itself, or if nothing of that would apply people called it bad luck. Hmmh!?!?
More thorough research would have taken me a day or two. Initial research led me to kernel/driver/setup issues. I also stepped over quite some conversations that do criticize the power situation on the RPi.
There are tons of rather poor 5V power supplies sold for the RPi. It's getting worse if we talk power and USB devices. I stepped over stuff like "never pull a USB device, if the OS is up'n running, that'll knock your system down". "Avoid buspowered devices", because of 120mA current limitation of RPi USB and and an overall 700mA RPi current limitation. asf. asf.
People figured that simple stuff like the buffer capacitance for the USB power rails would not comply to USB 2 standards (47uf vs 120uf). The 220uf buffering of the main 3.3V supply would be much too low. Asf. Asf.
This unstable power situation can obviously cause some serious breakdowns. That this can leave a SD-card broken/corrupted is not that far fetched.
The next thing I figured, was that the RPi uses a SoC USB hub controller (LAN9512) which also provides an internal networking controller, which is hooked up the USB bus controller.
Yep. The network controller seems to be tight to the USB bus. Hmmh.
What does that mean? It means that if you use any kind of networking (fileshare or streaming, network remote control...) somehow the Ethernet has to share the USB bus with your USB audio interface. That's probably not the best idea for serious USB Audio applications, especially if an external audio interface is a must. And that's the case here.
For audio purposes you should leave the bus exclusively to the audio device. At least that's kind of common sense developed over the last couple of years. However. It needs to be verified.
An alternative solution might be to use HDMI as audio interface of choice. Though there are not
too many devices supporting it. Many HDMI breakoutboxes that you'll find, tend to limit your samplerates to e.g. 48khz max and might not comply to audiophile standards..
However. I do have the RPi on the table now. I'll give it a chance.
I obviously got rid of PiCorePlayer. Though you might try it. You'll have a nice sounding squeezebox client up'n running in 5 minutes.
I also skipped Rasbian. I don't like pure Debian systems. These Debians usually never run up2date SW.
However. Raspberry firmware and drivers seem to be up2date though.
If we talk kernel and audio drivers as well as filesystem drivers etc. you might end up at a dead-end pretty quickly with a Debian system.
That led me to ArchLinux -- Arm.
From RaspiFy over PiCorePlayer and Rasbian I got to Archlinux and installed Squeezlite (took me roughly 30 minutes to get it all running) and that includes a pretty up2date 3.10 kernel and a lot of RPi tweaks already included on the Arch image. Nice.
On a first glance there's not much to tune. the implemented quite some optimizations already. A pretty good base.
ArchArm actually comes with a similar small RAM footprint as TinyCore (25MB!).
The software used though is usually lightyears ahead of the stripped down TinyCore stuff and even Debian (Rasbian) systems.
Arch got the RAM share already configured for terminal/command line usage, which basically gives the audio daemon more air to breathe.
The RPi comes with a major disadvantage, if you run a GUI. Much more RAM and CPU power gets allocated for graphics! If RPi, then go headless.
Meanwhile I got a rather solid headless system running. I do have the feeling that I'm on the rather safe side when it comes to software now.
Still, I have the feeling that the system runs on the edge all the time. I'm still not 100% sure if all pops and clicks are gone, especially on HiRez material.
I tested the RPi with a Teac UD-501 (async), a M2TECH Hiface 2 (async) and an
Audio-GD DI V1 (adaptive). The SPDIF devices were feeding my HifiMeDIY Full
Digital Amp and the Teac fed my Adam A5s speakers.
I'm using btw. 5V linear/battery supplies for RPi and audio interfaces. There's no way to get the Hiface working via buspower. You'd need an external supply and a special USB cable with external power option.
For 7 days now with RPi+Arch my SD-card is still not corrupted. That's promising.
I got more accustomed to Arch Linux every day (been running Ubuntu for years).
Obviously I now follow strict handling rules to avoid breakdowns:
* I always properly shutdown the OS
* I do make sure that I never unplug the power cable
* and never pull or plug a USB cord if the device is UP.
* I always have a backup SD-card at hand
(* I'm in the process to build a shutdown button)
Now to summarize it.
The main RPi issues:
1. shared USB hub/bus for audio and ethernet (No.1 NOGO -- impact needs to be verified)
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 (WorkinProgress)
7. requires proper RAM share setup (only headless - no GUI - operation recommended)
8. 1+7 potentially cause instabilities and
9. chance to corrupt your SD card
10. no (save) powerup/shutdown button
11. no Toslink and
12. poor internal audio chip ( you will have to use an external audio device)
My audio system goal is to get rid of as many devices and peripherals incl. cables as possible.
That won't happen with the RPi. You'd at least need an external audio interface with external power supply. These bus powered audio interfaces won't work!! -- unless you modify the powerrails ( what I did in the meanwhile - I can run the Hiface 2 now from the RPi USB port ).Compared to the SB Touch, you'd need two devices.
Then. What's on the positive side? It's difficult.
* There's a huge community out there. That'll keep such a project going.
* There are tutorials to improve the power situation, if you're a skilled DIY person.
* There's a lot of hacking potential -- a nice playground
* It's got some potential to make a nice little streaming client, if you get it stabilized.
* It's a fun toy that'll allow for endless nice little projects you wouldn't have done otherwise.
For my main purpose - a no frill streaming client as replacement for a SB Touch or SB Duet - considering the experiences I made, even 60$ (RPi, box, chip cooling, power) are too much.
Don't forget to add a good PS and an audio-interface to the bill.
I wouldn't consider this gadget a bargain at this price/performance ratio.
The stock device is IMO pretty much unusable. I wouldn't recommend it.
I'd rather say. Stay away.
So. Better watch out when reading about the next "audiophile" mini OS on RPi.
The situation might change if the RPi designers do something about the rather flawed Power Supply/Rail situation and at least add a Toslink interface.
I'm sure some minor changes would be sufficient to get things stabilized and wouldn't even increase the production cost.
Luckily there are much higher quality products out there. ;)