BeagleBone Black as an MPD server

[rdale]

I've been talking about the BeagleBone Black on the recent 'Raspberry Pi. Yum' thread, and I thought I should summarize my experiences so far and give some instructions for building an MPD server customized to talk directly to ALSA, rather than via Pulse Audio like the Debian packaged version.

WHAT TO BUY

You can get a BeagleBone Black from Farnell UK for 30.99 UKP:

http://uk.farnell.com/circuitco/bb-bblk-000/beaglebone-black-cortex-a8-dev/dp/2291620

Farnell sell a suitable linear power supply for 10.60 UKP:

http://cpc.farnell.com/1/1/84869-ac-dc-linear-psu-5v-1a-universal-s2226st-stontronics.html

I bought my linear power supply from Item Audio for 19 UKP:

http://www.itemaudio.com/index.php/power-supplies/linear-psus/detail/28-linear-psus/flypage/1080-5v--1a-linear-psu.html?sef=hcfp

It may be the same model as the Farnell one, I'm not sure.

I bought my case from Tigal for 29 euros + VAT:

http://www.tigal.com/product/3458

Logic Supply do another type of metal case:

http://www.logicsupply.com/blog/2013/05/23/beaglebone/

Both Tigal and Logic Supply sell BeagleBone Blacks, although I don't think they sell any suitable linear PSUs.

INSTALLATION

Initially I used the Angstrom Linux distribution that comes with the BeagleBone. I found a few annoying things with it though. If you added an NFS mount to /etc/fstab it wasn't mounted on startup. Getting the ntp time server working took about half an hour of fiddling around whereas once you install it on Debian it just works. I was getting quite frequent dropouts at the end of tracks with ALSA errors in the log. Another advantage of using Debian Wheezy is that it is the same Linux distribution as Raspian on the Raspberry Pi, and so any software setup tips and howtos will be much the same.

These notes are adapted from the RaspyFi instructions here:

http://www.raspyfi.com/raspyfi-rc2-how-its-made-and-list-of-all-the-optimizations/

Follow the instructions here on how to install Debian Wheezy onto an SD card:

http://avedo.net/653/flashing-ubuntu-13-04-or-debian-wheezy-to-the-beaglebone-black-emmc/

You will need a Linux computer with an SD card reader/writer to setup the BeagleBone's SD card. If you haven't got one,

you will need to buy a USB SD card reader/writer and attach it to the BeagleBone and follow the instructions with Angstrom

Linux running off the flash card.

You could install Wheezy on the internal 2Gb flash memory, but I prefer to keep that as standard Angstrom Linux as provided with the BeagleBone.

# Set up the locale.

# I use American en_US.UTF-8 as I'm not bothered about British English

sudo apt-get install locales

sudo dpkg-reconfigure locales

# Tweak ALSA to buffer more packets for USB (that's what I think this does)

sudo apt-get install alsa-utils

sudo nano /etc/modprobe.d/alsa-base.configure

# Add this line at the end:

options snd-usb-audio nrpacks=1

# Install mpd and the mpc command line utility.

# We are going to build our own MPD, but it is easier to use an existing

# configuration and just change the mpd binary to a custom one.

sudo apt-get install mpd mpc

# Install the dependencies for building mpd:

sudo apt-get install libfaad2 libfaad-dev libflac8 libflac-dev libogg0 libogg-dev \

libvorbis0a libvorbis-dev libid3tag0 libid3tag0-dev libmad0 libmad0-dev \

libcue-dev libcue1 libasound2 libasound-dev libasound2-dev \

libao-dev libwavpack-dev libwavpack1 libsamplerate0 \

libsamplerate-dev libmikmod2-dev libmikmod2 libmikmod-dev \

libshout-dev libavformat-dev libavcodec-dev libavutil-dev \

libcurl4-openssl-dev libmms-dev libmms0 \

libtwolame-dev libtwolame0 libmp3lame-dev

# Get the mpd sources from git:

cd /home/debian

git clone git://git.musicpd.org/master/mpd.git

cd mpd

# The most recent release is 0.17.4, and so check out that version

git checkout release-0.17.4

# Configure mpd, it will be installed in /usr/local:

./autogen.sh --disable-bzip2 --disable-iso9660 --disable-zzip \

--enable-id3 --disable-sqlite --enable-ffmpeg --enable-alsa \

--disable-wave-encoder --enable-pipe-output --enable-httpd-output \

--disable-recorder-output --disable-sndfile --enable-oss \

--enable-shout --disable-pulse --disable-ao \

--disable-mad --disable-inotify --disable-ipv6 --enable-curl \

--disable-mms --disable-wavpack --disable-lame-encoder \

--disable-twolame-encoder --enable-vorbis --enable-lsr \

--with-zeroconf=auto

When the configuration has finished, you should see something like this:

########### MPD CONFIGURATION ############

Archive support:

(-bzip2) (-ISO9660) (-ZIP)

Client support:

(-IPv6) (+TCP) (+UNIX Domain Sockets)

File format support:

(+AAC) (-C64 SID) (+FFMPEG) (+FLAC) (-FluidSynth) (-GME) (-libsndfile)

(-MikMod) (-MODPLUG) (-MAD) (-MPG123) (-MP4) (-Musepack)

(-OggTremor) (+OggVorbis) (-WAVE) (-WavPack) (-WildMidi)

Other features:

(+libsamplerate) (-inotify) (-SQLite)

Metadata support:

(+ID3)

Playback support:

(+ALSA) (-FFADO) (+FIFO) (-File Recorder) (+HTTP Daemon) (-JACK)

(-libao) (-Media MVP) (+OSS) (-OpenAL) (-OS X) (+Pipeline)

(-PulseAudio) (-ROAR) (+SHOUTcast) (-Solaris) (-WinMM)

Streaming encoder support:

(+FLAC) (-LAME) (+Ogg Vorbis) (-TwoLAME) (-WAVE)

Streaming support:

(-CDIO_PARANOIA) (+CURL) (-Despotify) (-Last.FM) (-Soundcloud)

(-MMS) (-SOUP)

##########################################

# Build and install:

make

sudo make install

# Change the mpd config to pick up the mpd program from /usr/local/bin/mpd:

/etc/init.d/mpd stop

echo DAEMON=/usr/local/bin/mpd >>/etc/default/mpd

/etc/init.d/mpd start

# Remove apache as it isn't needed:

sudo apt-get remove apache2

sudo apt-get remove apache2-mpm-worker apache2-utils apache2.2-bin apache2.2-common

# Install lighttpd instead for serving cover art:

sudo apt-get install lighttpd

# Edit /etc/lighttpd/lighttpd.conf

server.document-root = "/var/lib/mpd/music"

# Install NFS client software in order to NFS mount a disk with music tracks

sudo apt-get install nfs-common

# Edit /etc/fstab and add a line similar to this to NFS mount a disk at startup

192.168.1.104:/mnt/Music04 /mnt/Music04 nfs soft,intr,ro,rsize=32768 0 0

# Create mount point:

sudo mkdir /mnt/Music04

# I use a large read buffer with 'rsize=32768' as we are reading large music

# file sequentially

Comment out these lines in /etc/inittab to stop the 7 getty processes

being started:

# 1:2345:respawn:/sbin/getty 38400 tty1

# 2:23:respawn:/sbin/getty 38400 tty2

# 3:23:respawn:/sbin/getty 38400 tty3

# 4:23:respawn:/sbin/getty 38400 tty4

# 5:23:respawn:/sbin/getty 38400 tty5

# 6:23:respawn:/sbin/getty 38400 tty6

# Example how to put a getty on a serial line (for a terminal)

#

#T0:23:respawn:/sbin/getty -L ttyS0 9600 vt100

#T1:23:respawn:/sbin/getty -L ttyS1 9600 vt100

# Example how to put a getty on a modem line.

#

#T3:23:respawn:/sbin/mgetty -x0 -s 57600 ttyS3

# Change the CPU frequency governor from 'ondemand' to 'performance'

sudo nano /etc/default/cpufrequtils

# Add this line:

GOVERNOR="performance"

# Create symbolic links in /var/lib/mpd/music to your NFS mounted music disk:

cd /var/lib/mpd/music

sudo ln -s /mnt/Music04/Music/Music Music

# Find out the name of your USB device with the 'aplay -l' command.

# This is what I get for my V-Link:

$ aplay -l

**** List of PLAYBACK Hardware Devices ****

card 0: Black [TI BeagleBone Black], device 0: HDMI nxp-hdmi-hifi-0 []

Subdevices: 1/1

Subdevice #0: subdevice #0

card 1: VLink [Musical Fidelity V-Link], device 0: USB Audio [uSB Audio]

Subdevices: 1/1

Subdevice #0: subdevice #0

# Edit /etc/mpd.conf and change the output section for your DAC or other USB device

# Here is the entry I use for my V-Link:

audio_output {

type "alsa"

name "Musical Fidelity V-Link"

device "hw:VLink" # optional

# format "44100:16:2" # optional

# mixer_device "hw:MM1" # optional

# mixer_control "PCM" # optional

# mixer_index "0" # optional

mixer_type "none"

}

Restart with 'sudo reboot', and debug anything which goes wrong.

SOUND

The sound once everything is set up is really good. I was using an old MacBook with Decibel and BitPerfect before, and I think the BeagleBone has clearer, higher resolution treble.

NEXT STEPS

I'm looking an RFI/EMI shielding sheets to use in the BeagleBone case. There may be a version of the Voyager Linux music distribution available soon which would simplify setting up an MPD server. I may switch to that, but I'm pretty pleased with my set up as is.

 

[gjm]

Thanks Richard.

Do you know if there is a 'Ramplay' feature available, or likely to be (perhaps in Voyager?) available similar to that implemented in RaspyFi?

 

[rdale]

Thanks Richard.Do you know if there is a 'Ramplay' feature available, or likely to be (perhaps in Voyager?) available similar to that implemented in RaspyFi?

I didn't know about 'Ramplay', I just leave the MPD default buffer size setting as it is. I've tried increasing it, but it seemed a bad idea as MPD would do a giant disk read at some arbitrary point, and think it is better to do smaller reads more frequently. If it was possible to read an entire track into memory before playing it, that might be a good idea. I'll go off and search for details of what Ramplay does.

 

[gjm]

Ramplay really comes into it's own with the 512mb (Model B) Pi. It can download an entire lossless album into memory, and playback from there.

Of course, it can also download individual tracks.

This seems, to me, an excellent idea.

 

[rdale]

Ramplay really comes into it's own with the 512mb (Model B) Pi. It can download an entire lossless album into memory, and playback from there.Of course, it can also download individual tracks.

This seems, to me, an excellent idea.

Right, so is that built into the standard version of MPD and just needs configuring? The BeagleBone Black has the same 512 Mb of RAM as the Pi.

 

[Chumpy]

Thankyou for this thread/good luck. My wife has a Beagle/is currently puppysitting 5 of the little beasties.

 

[rdale]

Thankyou for this thread/good luck. My wife has a Beagle/is currently puppysitting 5 of the little beasties.

Sounds a bit of a handful. Any pictures of small beagles would be very welcome in this thread of course.

 

[gjm]

Right, so is that built into the standard version of MPD and just needs configuring? The BeagleBone Black has the same 512 Mb of RAM as the Pi.

I lack the knowledge to say one way or another!

From Raspyfi:

"Ramplay modeThis is an experimental funcion, it works basically by copying your music files to a virtual drive on the RAM Memory. Then we clear the play queue, then we add the music we copied to the play queue and we tell mpc to play it.

In these version, Ramplay is quite unconfortable, in next release it will be more user friendly. Please note that you’ll need a 512 Model B to use this feature.

This mode will provide the highest quality out of the little pi, so this trick is well worth the hassle.

1- Download FileZilla

2- Install it, then configure it as follows:

Host: 192.168.your raspberry pi ip

Protocol: SFTP SSH File Transfer Protocol

Access Type: Normal

Username: pi

Password: raspberry

Then click on connect. You only have to set this configuration the first time you connect to the Pi. If you save this profile, next time it will be a matter of seconds to connect to the pi. With this you can browse the file on the Raspberry. We will use this to transfer the files to the virtual disk on Ram. You’ll find 2 main tabs on File Zilla, the one on the left shows your local drive, the one on the right the Raspberry Pi.

Just Browse the files on your hard drive and drag&drop them on this folder on the Raspberry:

/run/shm/

Please note that total filesize should not exceed 250 mb. You can exceed those file limit by increasing /run/shm size, but this can have undesired effects. You can resize the ram partition by editing /etc/fstab

none /run/shm tmpfs defaults,size=256M,noexec,nodev,nosuid 0 0

Changing the size= value. I suggest not setting more than 380 mb. This should be good for an entire flac album.

When transfer is finished. You’re ready to go. Just type this commands (your play queue will be overwritten)

sync;echo 3 > /proc/sys/vm/drop_caches

mpc clear

mpc update ramplay

mpc ls ramplay | mpc add

mpc play

Now, the pi will start to play. Enjoy RamPlay mode, possibly the best audio quality you can get on Pi!

Please note that you’ll lose the files you copied everytime you reboot."

 

[Guest]

For the uninitiated, can you tell us what MPD and ALSA are?

Ta.

 

[rdale]

I lack the knowledge to say one way or another!From Raspyfi:

"Ramplay modeThis is an experimental funcion, it works basically by copying your music files to a virtual drive on the RAM Memory. Then we clear the play queue, then we add the music we copied to the play queue and we tell mpc to play it.

In these version, Ramplay is quite unconfortable, in next release it will be more user friendly. Please note that you’ll need a 512 Model B to use this feature.

This mode will provide the highest quality out of the little pi, so this trick is well worth the hassle.

1- Download FileZilla

2- Install it, then configure it as follows:

Host: 192.168.your raspberry pi ip

Protocol: SFTP SSH File Transfer Protocol

Access Type: Normal

Username: pi

Password: raspberry

Then click on connect. You only have to set this configuration the first time you connect to the Pi. If you save this profile, next time it will be a matter of seconds to connect to the pi. With this you can browse the file on the Raspberry. We will use this to transfer the files to the virtual disk on Ram. You’ll find 2 main tabs on File Zilla, the one on the left shows your local drive, the one on the right the Raspberry Pi.

Just Browse the files on your hard drive and drag&drop them on this folder on the Raspberry:

/run/shm/

Please note that total filesize should not exceed 250 mb. You can exceed those file limit by increasing /run/shm size, but this can have undesired effects. You can resize the ram partition by editing /etc/fstab

none /run/shm tmpfs defaults,size=256M,noexec,nodev,nosuid 0 0

Changing the size= value. I suggest not setting more than 380 mb. This should be good for an entire flac album.

When transfer is finished. You’re ready to go. Just type this commands (your play queue will be overwritten)

sync;echo 3 > /proc/sys/vm/drop_caches

mpc clear

mpc update ramplay

mpc ls ramplay | mpc add

mpc play

Now, the pi will start to play. Enjoy RamPlay mode, possibly the best audio quality you can get on Pi!

Please note that you’ll lose the files you copied everytime you reboot."

It all looks a bit of a hack to me.

Ramplay would certainly work exactly the same on the BeagleBone if you wanted to do it. To me it would make more sense to change MPD to read an entire track into memory before playing it. I really haven't started looking at the MPD sources all that much, but it shouldn't be too hard, although I'm surprised nobody has done that already.

 

[rdale]

For the uninitiated, can you tell us what MPD and ALSA are?Ta.

MPD stands for 'Music Player Daemon':

http://www.musicpd.org

It runs on a server and has no UI of its own. You use MPD client programs to tell the MPD server what music to play. There are MPD client apps for Windows, Mac OS X and Linux. I use the mPod app on my iPod Touch and the MPDroid app on my Nexus 7 tablet. You can create playlists, view your music by album, artist, and see cover art.

ALSA stand for 'Advanced Linux Sound Architecture':

http://www.alsa-project.org/main/index.php/Main_Page

It handles low level audio functionality in Linux, such as driving a USB DAC. There is a higher level audio framework in Linux called 'Pulse Audio' which allows more than one application to share the Linux output audio amongst a lot of other features.

For audiophile Linux audio you just want a single device (your DAC) and a single application (MPD), and the path between the two to be as simple as possible. That is why it is worth building a custom version of MPD that doesn't use Pulse Audio and talks directly to ALSA for maximum sound quality.

 

[gjm]

For the uninitiated, can you tell us what MPD and ALSA are?Ta.

MPD is the 'Music Player Daemon'.

ALSA is the 'Advanced Linux Sound Architecture', and is what provides audio functionality to the Linux subsystem.

I kind-of get what they do, but I'm still trying to clarify the details in my own mind.

Edit: What Richard said. ^

 

[Guest]

Right, thanks guy, very helpful.

 

[PegLeg]

A couple of points and questions for Richard. I assume you've worked with the beaglebone black as you were dissatisfied with the limitations of ethernet on USB of the raspberry pi. I'm surprised you felt it necessary to re-compile MPD with a “–disable-pulse” flag. Surely “pulse audio” is not a dependency of MPD, and having a “pulse audio” capable MPD doesn't mean you have to use “pulse audio”. I suppose compiling MPD with just the flags you think are necessary may give it a slightly lighter footprint, but then why did you leave oss support enabled?

This setting may have no benefit.

# Add this line at the end:

options snd-usb-audio nrpacks=1

See the discussion in this long thread at DIY audio:

http://www.diyaudio.com/forums/pc-based/93315-linux-audio-way-go-92.html

I would pay particular attention to what phofman has to say about it.

Of MPD you said: “It runs on a server ...”. I think that's open to misinterpretation. Perhaps you meant MPD “runs as a server”, meaning the software uses a client/server model, rather than you need to run the software on a hardware server platform. And you don't have to run MPD as a service, but for this application it's obviously convenient to do so.

You could of course have audio apps sharing an audio device before the days of “pulse audio” by using the ALSA dmix. But certainly you want to give MPD exclusive use of your audio device so “pulse audio” is best avoided.

VoyageMPD has been ported to the cubox, so an ARM version may yet surface.

http://linux.voyage.hk/blog/1

So how does the SQ of the Beagleboard Black cf to the raspberry PI? Is it free of the raspberry PI's USB problems? Does it work with UAC2 devices?

 

[rdale]

A couple of points and questions for Richard. I assume you've worked with the beaglebone black as you were dissatisfied with the limitations of ethernet on USB of the raspberry pi. I'm surprised you felt it necessary to re-compile MPD with a “–disable-pulse” flag. Surely “pulse audio” is not a dependency of MPD, and having a “pulse audio” capable MPD doesn't mean you have to use “pulse audio”. I suppose compiling MPD with just the flags you think are necessary may give it a slightly lighter footprint, but then why did you leave oss support enabled?

The Debian packaged version of MPD certainly links against Pulse Audio, but you may be right that if you configure it to not use Pulse Audio it will just use ALSA. I copied the configure flags from the RaspyFi howto that I gave as a link. It is quite possible there are errors, but it certainly works for me with the AIFF and Apple Lossless files that I have tried. I removed 'libaudiofile' as it seemed to be used for a looking at AIFF files, and I just wanted to use the ffmpeg libraries.

One further reason for building a custom version of MPD is to use the newest version of the ffmpeg libs from the master branch. With the Debian version of was getting errors in extracting the meta data tags, and was getting errors which said something like 'Invalid RIFF chunk' or similar. With the latest ffmpeg the meta data seems 100% perfect as far as I can see. I didn't mention that in the build instructions as I thought it would make them a bit too complicated.

git clone git://source.ffmpeg.org/ffmpeg.git ffmpeg

./configure --prefix=/usr --enable-shared

make

make install

However you need to remove the existing ffmpeg libraries:

sudo apt-get remove libavcodec-dev libavcodec53:armhf libavformat-dev libavformat53:armhf libavutil-dev libavutil51:armhf

And unfortunately that would remove MPD as well. I couldn't think of a simple way to explain how use the Debian MPD configuration files, but without actually installing MPD as a package. I copied the config files across from my Raspberry Pi installation.

This setting may have no benefit.

# Add this line at the end:

options snd-usb-audio nrpacks=1

See the discussion in this long thread at DIY audio:

http://www.diyaudio.com/forums/pc-based/93315-linux-audio-way-go-92.html

I would pay particular attention to what phofman has to say about it.

I have read that discussion as I had a big problem on my Raspberry Pi with the log files being filled with huge numbers of spurious ALSA messages. Adding that option fixed the log messages problem. I don't get the messages on the BeagleBone, but still added that option as it appeared to make more room for buffering USB packets from my understanding of the discussions I came across. I could be wrong, but it doesn't seem to do any harm at least.

Of MPD you said: “It runs on a server ...”. I think that's open to misinterpretation. Perhaps you meant MPD “runs as a server”, meaning the software uses a client/server model, rather than you need to run the software on a hardware server platform. And you don't have to run MPD as a service, but for this application it's obviously convenient to do so.

You could of course have audio apps sharing an audio device before the days of “pulse audio” by using the ALSA dmix. But certainly you want to give MPD exclusive use of your audio device so “pulse audio” is best avoided.

VoyageMPD has been ported to the cubox, so an ARM version may yet surface.

http://linux.voyage.hk/blog/1

So how does the SQ of the Beagleboard Black cf to the raspberry PI? Is it free of the raspberry PI's USB problems? Does it work with UAC2 devices?

I may not have been completely clear about what I meant by MPD 'running as a server', but I think the most important thing to explain it that it is designed to run on a headless machine without a screen. Nearly all other music players expect to have some GUI front end.

I did mention in the 'NEXT STEPS' that I would like to try the Voyage distribution when it reaches the fine release state - as far as I know they are still working on the ARM port. But that should be the perfect canned solution when it comes out, and I'll be interested to find out if it sounds any different to my 'home brewed' setup.

I can't compare the sound quality of the BeagleBone and Raspberry Pi in my main system as the Pi doesn't work with the V-Link that I use. The Pi does't work with my HRT Music Streamer II+ either. Or at least the Pi didn't work with those two devices last time I tried. I haven't tried both with my B&W MM-1 speakers apart from briefly testing the BeagleBone to see if it worked at all. When MPD is running and I look at the processes with 'top' I don't see any particular difference. With AIFF, MPD is typically use 0.7 - 2.0% of the CPU on the BeagleBone and may 1 - 2% on the Pi, there isn't really any significant difference.

I've been exchanging emails and talking on #beaglebone with Kelvin, a guy from the Computer Audiophile forum. He has a dCS Debussy which has a class 2 USB input and he says that he get occasional clicks and pops. I may be possible to get that fixed, but for now I think is best to assume that the BeagleBone works very well with class 1 USB devices, and may be able to drive class 2 USB devices with a bit more work. I believe the Raspberry Pi USB support is still significantly buggy and one of the main reasons for using a BeagleBone is to avoid that. Also the Raspberry Pi's ethernet goes through the USB bus, whereas the BeagleBone has proper native ethernet support with no USB involved.

 

[PegLeg]

Thanks for the additional feedback and info. You've had a fair bit of extra work to do.

I may not have been completely clear about what I meant by MPD 'running as a server', but I think the most important thing to explain it that it is designed to run on a headless machine without a screen. Nearly all other music players expect to have some GUI front end.

This is where we disagree. MPD is/was definitely not designed to run on a headless system and nothing else, it's running on my desktop now. By adopting a client/server model, MPD + client can be deployed in a wide variety of configurations. One of which is to run MPD on one network node, and the client on another. Of course you have the option to run MPD as a service on a headless machine if you wish.

I did mention in the 'NEXT STEPS' that I would like to try the Voyage distribution when it reaches the fine release state - as far as I know they are still working on the ARM port. But that should be the perfect canned solution when it comes out, and I'll be interested to find out if it sounds any different to my 'home brewed' setup.

I can't imagine it would sound any different. Voyage MPD may only have the advantage of a filesystem that is designed to run of flash media partly mounted read-only and using tmpfs etc. But you may have already configured your system with this in mind.

My guess is that the raspberry pi and beagleboard black would sound no differnet at 16/44 res, and it doesn't seem that the beagleboard black is capable of driving UAC2 without glitches. There are reports that both the Cubox and Wandboard dual/quad can drive a UAC2 DAC, but then these ARM devices are more expensive. So there really is no audio advance over using something like a tried and tested ALIX board. Plus the x86 based ALIX board allows for a more straightforward linux install.

 

[rdale]

Thanks for the additional feedback and info. You've had a fair bit of extra work to do.This is where we disagree. MPD is/was definitely not designed to run on a headless system and nothing else, it's running on my desktop now. By adopting a client/server model, MPD + client can be deployed in a wide variety of configurations. One of which is to run MPD on one network node, and the client on another. Of course you have the option to run MPD as a service on a headless machine if you wish.

I don't think we disagree. But to me an important advantage of MPD is the running a UI on the same machine is not mandatory. Audiophiles often buy expensive headless Mac Minis and communicate with them via VNC (or the Mac equivalent?) on their iPads, in order to run Audivarna, Amarra or whatever. Or they use an iPhone with the iTunes remote control app, but to me the whole thing is a kludge, and iTunes isn't really designed to work that way.

I can't imagine it would sound any different. Voyage MPD may only have the advantage of a filesystem that is designed to run of flash media partly mounted read-only and using tmpfs etc. But you may have already configured your system with this in mind.

Yes, you might be right. I don't know how much the Voyage Linux kernel differs from Wheezy. I don't want a local filesystem with my music tracks on SSD, I think it is a better idea to NFS mount your music tracks and read them from a NAS. I have a Raspberry Pi based NAS which works great for that, but something like a Synology NAS makes a lot of sense for people who aren't Linux experts.

My guess is that the raspberry pi and beagleboard black would sound no differnet at 16/44 res, and it doesn't seem that the beagleboard black is capable of driving UAC2 without glitches. There are reports that both the Cubox and Wandboard dual/quad can drive a UAC2 DAC, but then these ARM devices are more expensive. So there really is no audio advance over using something like a tried and tested ALIX board. Plus the x86 based ALIX board allows for a more straightforward linux install.

' it doesn't seem that the beagleboard black is capable of driving UAC2 without glitches' - I think it is too early to say that in my opinion. I only have Kelvin's experiences with his dCS Debussy as a single data point in using USB class 2 audio with the BeagleBone Black. I don't particularly see why a Cubox or Wandboard should have better UAC2 USB audio support than the BeagleBoard. I am very interested in comparisons between x86 based ALIX boards and the various equivalent ARM based solutions. I have no pre-conceived ideas about which works best or sounds best. That is why we need threads like this to share experiences and make a start in sharing what we have to allow non-geeks to build cheap computer based audio systems.

 

[PegLeg]

I certainly agree about the value of sharing info about the use of these devices for audio apps and always read your posts with interest. A kind of comparision between ARM Cubox and x86 ALIX:


If you interested in tweeks which may or may not have influence on SQ, then these pages might be worth reading:

http://www.symphonic-net.com/kubotayo/articles/voyagempd.html

 

[Chumpy]

Very interesting - thanks.