Thinking so far...

My thoughts on potential technologies at this point are:

• Disk store
• Dunno yet! Ideally, I'd like something very quiet. Should I conflate the audio and other possible stores e.g. films, photos? 
• Synology, other RAID off-the-shelf kit, but if so probably one that will support running a media server
• A simple RAID box - loads cheaper, + a lightweight computer to run the media server (RPi?)
• Initially, a USB disk attached to a RPi!
• Media Server
• Looking at uPnP, largely because it's there, not sure I have really looked at the alternatives
• I quite like, and am running, Minimserver, not least because its tagging is supposed to be useful for classical, and it runs on NAS boxes if/when there is one (it's Java)
• Update: I've now installed and run Rune, which is a Volumio-alike but based on a different Linux (ArchLinux 32 bit), and which runs on RPi3 just fine. It's very good, and does everything I want with no installation stress or problems. Lovely!
• Renderer platform
• Currently working on RPi 3
• Provided we go with Open Source, then it can run on lots of platforms
• Renderer software
• Initially examined volumio, but 1.55 doesn't run on RPi3, although v 2 might Real Soon Now
• Currently working with mpd, which is the basis of volumio anyway
• Incorporated upmpdcli, which provides a uPnP interface to mpd
• Control software
• Linn Kinsky loaded on phone and Mac, not very impressed so far!
• Not looked at others yet
• Speakers
• Linkwitz LXMini
• These use a miniDSP DSP 2x4 to implement the active crossover; this is available in a box or kit
• If a kit, could be driven at 24/48k directly, but then needs a miniDigi to enable this; however, that is SPDIF/TOSLink in only, and then does sample rate conversion to 48k, using an Asynchronous Rate Converter chip
• Potentially, might be worth looking at the miniDSP 2x4 HD kit, since it could be driven directly in digital, skipping a DAC/ADC step to get data into the DSP
• Amps - now there's a question... Since I need 4, around 50w, there are a few options
• Re-use: Chord 1200C + Myst TMA5? Quad 405-2 + another from EBay?
• Buy - Thomann 4 channel power amp? £180 ish
• Buy - just missed a NAD 916 6 channel 70w/channel amp on EBay - £80! Although someone is selling NAD 906 (same thing) for £140 cash hmm. 
• Build - vast array of options!
• Chip Amp LM3886 derivatives
• Audiophonics - loads of options on there, including some interesting Class D (€40 per 2x100w amp, SMPS maybe €100, other parts whatever), but still expensive compared with Thomann!

Why?

Yeah, John, why??

Always a good question. In fact, one can make a continuing reputation for oneself and become highly regarded just by asking this question continuously - e.g. Socrates. Of course, one also risks becoming known as a PitA, in which case not everything may be entirely positive cf. Socrates.

I have acquired over time but not more recently than 10-15 years ago

• A large, relatively expensive stereo system, set up in the front room
• Chord CPA3200E, 1200C pre/power - it's a monster!
• Naim CDS 2 - two boxes
• Quad ESL63 - incredible sound, but large and tricky to place
• A number of remote controls
• A collection of CDs, probably <= 1000 - never enough, but space...?!

Meanwhile, things have moved on. 

• Computer disk style storage for digital recordings
• Cheap, powerful DACs
• Cheap, powerful DSP - even tiny single board computers like RPi have enough power to run many processing algorithms in (pretty close to) realtime
• Distributed, network "software" storage, processing and rendering
• Media management and replay management "apps", usually on smart phones and tablets
• Internet streaming of all sorts of material

So I thought it would be instructive to investigate the possibilities of these things, with the potential to supplement or even replace the big stereo, and certainly to open up the CD collection to easier browsing and even serendipitous random playing!

So - things to work on, in no particular order (which maybe in itself is a problem!):

• Disk array for storage
• Ripping of CDs to disks
• Audio file format for the ripped material, or separately acquired material
• Media server to present files to consumers
• Tagging, Indexing etc. - this is crucial, it would be great to have genres or moods that meant something, and performers too; sufficient flexibility to handle the classical world would be wonderful
• Networking; wireless is easiest, but it's not really necessarily sufficiently high bandwidth; the bit depth and sample rate has an impact, although 16/44.1k is probably not too strenuous and most material will be that
• Rendering device(s); this is basically the front end streamer and the DAC; lots to look at here, including the base platform of the device (a computer!) and the DAC, its connection to the render, and the material it can convert - this is really important because that has an effect right back to the audio file format and storage 
• Control application(s) to browse and cue up music
• Amplification and speakers; these are mentioned together because it's likely that I would want to use an active speaker setup, so the amps are intimately tied into the speakers
• DSP usage; this is basically two topics, the active crossovers required to drive the active speaker amplifiers, and any speaker / room equalisation 

Of course, this is a journey, and it's likely that some bits will be sketched out, and get replaced later. I can see that disk storage could be conflated with the media server platform e.g. USB disks stuck on an RPi, maybe migrating to a "proper" RAID setup with built-in processing, like Synology in the future. But it's important that big things are done right to prevent lost of re-work, so it's unlikely that I'd rip a lot of CDs to a specific format until I've ensured that it's the "right" one, otherwise there's a big investment in rework if I've ripped loads already!

I2S DACs

The Pi-DAC+ I2S DAC arrived today. Maybe I'll have time to check it out, maybe not. Lots cheaper than the ODAC, so a good value item if it sounds as good or better.

In principle, I2S-connected DACs can sound better than equivalent USB-connected DACs because

• They don't have to reconstruct the clock etc. - the data is presented directly across the I2S interface, without conversion into/out of USB and streamed across a wire in-between
• The RPi uses far less CPU to drive the DAC, since it's not doing conversion, allowing it to track the data better with less chance of drop-outs

We'll see...

Big ends and little ends and socks

Today's theme is endian-ness... Mr. Bowie's AIFF tracks are S24_3BE, which is exactly how all AIFF files will be! Scary, and I didn't realise that. Before they can play on my DAC they need to be S24_3LE. My options are:

• Convert them as files to 3LE, so that they are like that for ever, hopefully they will then play with mpd
• Convert them on the fly using plughw; this already works with aplay but not with mpd

This is where sox comes into play, maybe... I tried converting to WAV, which in principle allows LE - I already tried to a new AIFF but SoX wasn't having that because AIFF is BE only - see here.

pi@raspberrypi:/media/pi/David Bowie/Blackstar $ sox -V3 -B 02-\'Tis\ a\ Pity\ She\ Was\ a\ Whore.aif -x 02-\'Tis\ a\ Pity\ She\ Was\ a\ Whore\ LE.wav 

http://stackoverflow.com/questions/1111539/is-the-endianness-of-format-params-guaranteed-in-riff-wav-files

sox:      SoX v14.4.1

sox INFO formats: detected file format type `aiff'

sox INFO aiff: Unity MIDI Note: 0

sox INFO aiff: Low   MIDI Note: 0

sox INFO aiff: High  MIDI Note: 0

Input File     : '02-'Tis a Pity She Was a Whore.aif'

Channels       : 2

Sample Rate    : 96000

Precision      : 24-bit

Duration       : 00:04:52.63 = 28092161 samples ~ 21947 CDDA sectors

File Size      : 169M

Bit Rate       : 4.61M

Sample Encoding: 24-bit Signed Integer PCM

Endian Type    : big

Reverse Nibbles: no

Reverse Bits   : no

sox INFO formats: `02-'Tis a Pity She Was a Whore LE.wav': overriding file-type byte-order

sox INFO wav: Requested to swap bytes so writing RIFX header

Output File    : '02-'Tis a Pity She Was a Whore LE.wav'

Channels       : 2

Sample Rate    : 96000

Precision      : 24-bit

Duration       : 00:04:52.63 = 28092161 samples ~ 21947 CDDA sectors

Sample Encoding: 24-bit Signed Integer PCM

Endian Type    : big

Reverse Nibbles: no

Reverse Bits   : no

Comment        : 'Processed by SoX'

sox INFO sox: effects chain: input        96000Hz  2 channels

sox INFO sox: effects chain: output       96000Hz  2 channels

The bit in bold looks bad - it seems to have retained the byte order and put an instruction in the header instead! This doesn't work.

Aha...

The AES31 specification for BWF (Broadcast Wave Format) references this specification for RIFF: http://www.tactilemedia.com/info/MCI_Control_Info.html

From this:

RIFF has a counterpart, RIFX, that is used to define RIFF file formats that use the Motorola integer byte-ordering format rather than the Intel format. A RIFX file is the same as a RIFF file, except that the first four bytes are 'RIFX' instead of 'RIFF', and integer byte ordering is represented in Motorola format.

Looks like I'm screwed, unless the conversion to FLAC has done the trick. For that, I'd have to get mpd to see the damn FLAC file.

OK! Used the alas-configure script to create a new mpd.conf file that uses the music directly, rather than via minimserver, and started things with mpc. Loaded the Bowie Blackstar.flac file and bingo!! Plays fine on the hw:1,0 setting. Looks like that's what I have to do - convert the AIFF to FLAC. Blimey.

Tagging! Sound Files!

Right. I've worked out (duh!) that the reason why the reformatted tracks aren't appearing, and the Thomas Dolby WAV tracks aren't showing as an album is because they have incorrect or non-existent metadata. So, a quick download, and we'll be fixing them up and retrying them!

Update: Nope. Hard to find a Mac OS X tag editor that doesn't crash that's free... The only one I've found is not very intuitive!

No idea yet why the 24/96 Bowie material is not playing on my 24/96 DAC. I have the IQAudio PI+ I2S DAC arriving shortly, let's see if that works. The Thomas Dolby stuff plays, but I'm not sure why...

mpd.conf has the following output entry:

audio_output {

        type            "alsa"

        name            "ODACverB"

        device          "hw:1,0"        # optional

#       mixer_type      "software"      # optional

#       mixer_device    "default"       # optional

#       mixer_control   "PCM"           # optional

#       mixer_index     "0"             # optional

}

i.e. I'm using the direct hardware interface, no means of converting - see below!

The ODAC has the following support embedded (using the cool scripts here):

pi@raspberrypi:~ $ ./alsa-capabilities -s -l usb

 0) USB Audio Class Digital alsa audio output interface `hw:1,0'

 - device name       = ODAC-revB                                                   

 - interface name    = USB Audio                                                   

 - usb audio class   = 1 - isochronous adaptive                                    

 - character device  = /dev/snd/pcmC1D0p                                           

 - rates per format  = S24_3LE:             96000Hz 88200Hz 48000Hz 44100Hz 32000Hz 

                       S16_LE:              96000Hz 88200Hz 48000Hz 44100Hz 32000Hz 

 - monitor file      = /proc/asound/card1/pcm0p/sub0/hw_params                     

 - stream file       = /proc/asound/card1/stream0        

So it does 16/24 bit, at 32/4.1/48/88.2/96 KHz. Anything else is a no-no, unless it's converted to one of those first.

Checking out the actual file content...
WAV files have the following header structure:

The format for a wave file is as follows:

     Offset    Description

     ------    -----------

      0x00     chunk id 'RIFF'

      0x04     chunk size (32-bits)

      0x08     wave chunk id 'WAVE'

      0x0C     format chunk id 'fmt '

      0x10     format chunk size (32-bits)

      0x14     format tag (currently pcm)

      0x16     number of channels 1=mono, 2=stereo

      0x18     sample rate in hz

      0x1C     average bytes per second

      0x20     number of bytes per sample

                    1 =  8-bit mono

                    2 =  8-bit stereo or

                        16-bit mono

                    4 = 16-bit stereo

      0x22     number of bits in a sample

      0x24     data chunk id 'data'

      0x28     length of data chunk (32-bits)

      0x2C     Sample data

Thomas Dolby WAV Oceana.wav has the following data:

     Offset    Value      Description

     ------               -----------

      0x00     'RIFF'(!)  chunk id 'RIFF'

      0x04     524C 2704  (69,684,306) the file size! chunk size (32-bits)

      0x08     'WAVE'     wave chunk id 'WAVE'

      0x0C     'fmt '     format chunk id 'fmt '

      0x10     1000 0000  (65,536) format chunk size (32-bits)

      0x14     0100       (1) format tag (currently pcm)

      0x16     0200       (2) number of channels 1=mono, 2=stereo

      0x18     80BB 0000  (48000) sample rate in hz

      0x1C     0065 0400  (288,000 i.e. 48k*3) average bytes per second

      0x20     0600       (6 i.e. 24*2=48) number of bytes per sample

      0x22     1800       (24) number of bits in a sample

      0x24     'data'     data chunk id 'data'

      0x28     7C46 1B04  (68,896,380) length of data chunk (32-bits)

      0x2C     blah blah  Sample data

Note: This is WAV, so the entries are "little endian", so 524C 2704 is actually 04274C52. 

The mpd log has entries for these WAV files like:

Mar 22 12:09 : playlist: play 0:"http://192.168.1.3:9790/minimserver/*/pi/Thomas

*20Dolby/Oceanea*20EP/01*20Oceanea.wav"

Mar 22 12:09 : client: [0] command returned 0

Mar 22 12:09 : client: [0] process command "status"

Mar 22 12:09 : client: [0] command returned 0

Mar 22 12:09 : client: [0] process command "currentsong"

Mar 22 12:09 : client: [0] command returned 0

Mar 22 12:09 : client: [0] process command "playlistinfo "1""

Mar 22 12:09 : client: [0] command returned 0

Mar 22 12:09 : decoder_thread: probing plugin sndfile

Mar 22 12:09 : decoder: audio_format=48000:32:2, seekable=true

Mar 22 12:09 : alsa_output: opened hw:1,0 type=HW

Mar 22 12:09 : alsa_output: format=S24_3LE (Signed 24 bit Little Endian in 3bytes)

Mar 22 12:09 : alsa_output: buffer: size=96..174762 time=2000..3640875

Mar 22 12:09 : alsa_output: period: size=48..87381 time=1000..1820438

Mar 22 12:09 : alsa_output: default period_time = buffer_time/4 = 500000/4 = 125000

Mar 22 12:09 : alsa_output: buffer_size=24000 period_size=6000

Mar 22 12:09 : output: opened plugin=alsa name="ODACverB" 

Mar 22 12:09 : output: opened plugin=alsa name="ODACverB" audio_format=48000:24:2

Mar 22 12:09 : output: converting from 48000:32:2

48000 ok, but 32 bits? WTF?! Anyway, the Dolby tracks play. Hurrah. I'll check the sndfile plug-in to see why it thinks it's 32 bit. [Update: Ouch - C is horrible, and if course it's hard to get past the literals!]

Let's see what the Bowie stuff looks like...

mpd.log has

Mar 22 12:18 : playlist: play 0:"http://192.168.1.3:9790/minimserver/*/pi/David*

20Bowie/Blackstar/02-*27Tis*20a*20Pity*20She*20Was*20a*20Whore.aif"

Mar 22 12:18 : decoder_thread: probing plugin sndfile

Mar 22 12:18 : decoder: audio_format=96000:32:2, seekable=true

Mar 22 12:18 : alsa_output: opened hw:1,0 type=HW

Mar 22 12:18 : alsa_output: format=S24_3LE (Signed 24 bit Little Endian in 3byte

s)

Mar 22 12:18 : alsa_output: buffer: size=192..174762 time=2000..1820438

Mar 22 12:18 : alsa_output: period: size=96..87381 time=1000..910219

Mar 22 12:18 : alsa_output: default period_time = buffer_time/4 = 500000/4 = 125

000

Mar 22 12:18 : alsa_output: buffer_size=48000 period_size=12000

Mar 22 12:18 : output: opened plugin=alsa name="ODACverB" audio_format=96000:24:

2

Mar 22 12:18 : output: converting from 96000:32:2

Mar 22 12:18 : player: played "http://192.168.1.3:9790/minimserver/*/pi/David*20

Bowie/Blackstar/02-*27Tis*20a*20Pity*20She*20Was*20a*20Whore.aif"

Mar 22 12:18 : playlist: stop

and then it doesn't play!

Minim server log has the following info:

12:19:39.463 Thread-459: HTTPConnection: reading HTTP request

12:19:39.463 Thread-459: GET /minimserver/*/pi/David*20Bowie/Blackstar/02-*27Tis*20a*20Pity*20She*20Was*20a*20Whore.aif HTTP/1.1

12:19:39.463 Thread-459: User-Agent: Music Player Daemon 0.19.1, Host: 192.168.1.3:9790, Accept: */*, Icy-Metadata: 1

12:19:39.463 Thread-459: HTTPConnection: reading HTTP request

12:19:39.463 Thread-458: HTTPConnection: writer thread processing request

12:19:39.467 Thread-458: HTTP/1.1 200 OK, Accept-Ranges: bytes, Date: Tue, 22 Mar 2016 12:19:39 GMT, Content-Length: 168631966, Content-Type: audio/x-aiff, Connection: keep-alive, Last-Modified: Sat, 19 Mar 2016 17:32:32 GMT

12:19:39.467 Thread-458: writing data: total=168631966 from file David Bowie/Blackstar/02-'Tis a Pity She Was a Whore.aif

12:19:39.467 Thread-458: writing 16384 bytes: total=168631966

12:19:39.468 Thread-458: writing 16384 bytes: total=168631966

12:19:39.468 Thread-458: writing 16384 bytes: total=168631966

12:19:39.468 Thread-458: writing 16384 bytes: total=168631966

12:19:39.469 Thread-459: HTTPConnection: connection closed by client

12:19:39.469 Thread-459: ServerResourceBase: forced socket close: Socket[addr=/192.168.1.3,port=41180,localport=9790]

12:19:39.470 Thread-459: HTTPService: removing connection org.jminim.lib.HTTPConnection@1d5878e

So we ask ourselves - why is MPD closing the stream?? There's nothing in the log to indicate why... Is it Kinsky?

Trying VLC from my Mac, it has no problem playing the Bowie stuff through the ODAC... Here's the listing from the Media Info panel. That also says that the data is 32 bit, but the codec is Big Endian!

http://192.168.1.3:9790/minimserver/*/pi/David*20Bowie/Blackstar/02-*27Tis*20a*20Pity*20She*20Was*20a*20Whore.aif

Thomas Dolby 

David Bowie

Interesting! Someone has to fix this. I'm assuming that the DAC has to get it in the right order, and it expects S16_LE and S24_3LE, not BE. Maybe that's why??

Experimenting with play reveals all.

24 bit 48k LE works on raw hardware:

pi@raspberrypi:/media/pi/Thomas Dolby/Oceanea EP $ aplay -D hw:1,0 -f S24_3LE -r 48000 01\ Oceanea.wav 

Playing WAVE '01 Oceanea.wav' : Signed 24 bit Little Endian in 3bytes, Rate 48000 Hz, Stereo

Declaring BE doesn't work on the hardware interface, because it doesn't support it: 

pi@raspberrypi:/media/pi/David Bowie/Blackstar $ aplay -D hw:1,0 -f S24_BE -r 96000 02-\'Tis\ a\ Pity\ She\ Was\ a\ Whore.aif 

Playing raw data '02-'Tis a Pity She Was a Whore.aif' : Signed 24 bit Big Endian, Rate 96000 Hz, Mono

aplay: set_params:1233: Sample format non available

Available formats:

- S16_LE

- S24_3LE

This produces white noise!! 

pi@raspberrypi:/media/pi/David Bowie/Blackstar $ aplay -c 2 -D hw:1,0 -f S24_3LE -r 96000 02-\'Tis\ a\ Pity\ She\ Was\ a\ Whore.aif 

Playing raw data '02-'Tis a Pity She Was a Whore.aif' : Signed 24 bit Little Endian in 3bytes, Rate 96000 Hz, Stereo

This produces white noise, because it's not LE input 

pi@raspberrypi:/media/pi/David Bowie/Blackstar $ aplay -c 2 -D plughw:1,0 -f S24_3LE -r 96000 02-\'Tis\ a\ Pity\ She\ Was\ a\ Whore.aif 

Playing raw data '02-'Tis a Pity She Was a Whore.aif' : Signed 24 bit Little Endian in 3bytes, Rate 96000 Hz, Stereo

This produces white noise, presumably because the byte size is wrong 

pi@raspberrypi:/media/pi/David Bowie/Blackstar $ aplay -c 2 -D plughw:1,0 -f S24_BE -r 96000 02-\'Tis\ a\ Pity\ She\ Was\ a\ Whore.aif 

Playing raw data '02-'Tis a Pity She Was a Whore.aif' : Signed 24 bit Big Endian, Rate 96000 Hz, Stereo

This works, because the plug interface converts the BE to LE... 

pi@raspberrypi:/media/pi/David Bowie/Blackstar $ aplay -c 2 -D plughw:1,0 -f S24_3BE -r 96000 02-\'Tis\ a\ Pity\ She\ Was\ a\ Whore.aif 

Playing raw data '02-'Tis a Pity She Was a Whore.aif' : Signed 24 bit Big Endian in 3bytes, Rate 96000 Hz, Stereo

This doesn't work because there's no decompressor for the FLAC - more white noise!! 

pi@raspberrypi:/media/pi/David Bowie/Blackstar $ aplay -c 2 -D plughw:1,0 -f S24_3BE -r 96000 01-Blackstar.flac 

Playing raw data '01-Blackstar.flac' : Signed 24 bit Big Endian in 3bytes, Rate 96000 Hz, Stereo

And you can see the plug plug-in doing its thing...

pi@raspberrypi:/media/pi/David Bowie/Blackstar $ aplay -v -c 2 -D plughw:1,0 -f S24_3BE -r 96000 02-\'Tis\ a\ Pity\ She\ Was\ a\ Whore.aif 

Playing raw data '02-'Tis a Pity She Was a Whore.aif' : Signed 24 bit Big Endian in 3bytes, Rate 96000 Hz, Stereo

Plug PCM: Linear conversion PCM (S24_3LE)

Its setup is:

  stream       : PLAYBACK

  access       : RW_INTERLEAVED

  format       : S24_3BE

  subformat    : STD

  channels     : 2

  rate         : 96000

  exact rate   : 96000 (96000/1)

  msbits       : 24

  buffer_size  : 48000

  period_size  : 12000

  period_time  : 125000

  tstamp_mode  : NONE

  period_step  : 1

  avail_min    : 12000

  period_event : 0

  start_threshold  : 48000

  stop_threshold   : 48000

  silence_threshold: 0

  silence_size : 0

  boundary     : 1572864000

Slave: Hardware PCM card 1 'ODAC-revB' device 0 subdevice 0

Its setup is:

  stream       : PLAYBACK

  access       : MMAP_INTERLEAVED

  format       : S24_3LE

  subformat    : STD

  channels     : 2

  rate         : 96000

  exact rate   : 96000 (96000/1)

  msbits       : 24

  buffer_size  : 48000

  period_size  : 12000

  period_time  : 125000

  tstamp_mode  : NONE

  period_step  : 1

  avail_min    : 12000

  period_event : 0

  start_threshold  : 48000

  stop_threshold   : 48000

  silence_threshold: 0

  silence_size : 0

  boundary     : 1572864000

  appl_ptr     : 0

  hw_ptr       : 0

I wonder if the HDTracks website is aware of this kind of thing? Can I convert BE to LE without any resampling - in principle it's easy, in fact I could write a program to do it! But I don't want to.

Spent a LOT of time reading the plug.c source, but not obvious where format conversion is done. I can't be arsed. However, although aplay -D plughw:1,0 works for the Bowie S24_3BE material, that same setting doesn't work in mpd!! How strange. Let's try mpd on its own, pointed to the material, rather than minimserver, and see if that works. 

[Update: haven't made that work yet - still looking at the file format stuff]

Story so far...

I've obtained

• A Raspberry Pi 3, from The Pi Hut, along with an 8GB SD card and a development box
• An ODAC USB DAC from Head n Hifi, which is pretty cool
• Maybe I should have considered an I2S-connected DAC, but I figured that one I could re-use with any computer would be handy
• MinimServer as a UPnP-enabled media server
• Linn Kinsky as a UPnP control point
• MPD as a renderer, with upmpdcli as a UPnP interface
• My initial thinking, based on this article, was to use volumio, but that isn't supported on RPi 3 yet, not sure why it's so different from RPi 2 but hey... Other packages are available, but for the moment so I understand what's going on, I'm going to hand-roll it. Maybe in future I'll just use a package.

I also need hard drives for holding music files, so I'm currently using a 2.5" format 250GB drive that was my MacBook Pro drive until I got an SSD :-), connected via a SATA-USB cable. I've formatted this as exFAT, which was the option on the MacBook, but it proved slightly tricky to mount on the RPi... Problem solved with HTPC Guides, a wonderful site that I think I will live at for a while...

Steps so far:

• Tried ODAC with main hifi - sounds really good, using Audirvana Pro on free trial
• Music disk
• Formatted 250GB drive as exFAT on MacBook
• Copied some files to it - I need to work out how best to label and index these, lots of room for experiment there!
• iPhone
• Loaded Kinsky - seems to find Minimserver just fine
• Now I need a "room" for it to play in!
• RPi
• Until my additional RPi arrives, I'll put everything on one, rather than having a separate media server and renderer...
• Loaded with latest Raspbian jessie, and updated to latest
• Installed MinimServer - can be detected by Kinsky!
• Attached drive - can see files; I wonder if I need to do anything about the power supply, since it's running on USB power
• Following the guide here, but the setfacl commands are apparently not supported on this device type?!
• Installed MPD and upmpdcli
• I attempted this but I suspect that this build is set up for Debian wheezy, not jessie, I'm getting errors...
• The originator of the revised upmpdcli expected a 0.19 version MPD instead of the 0.16 that existed when wrote the note; checking www.musicpd.com they are up to 0.19..x..x.x, so we'll revert
• So renamed the mpd.list in /etc/apt/sources.list.d so it's ignored...
• Did a sudo apt-get update
• Did a sudo apt-get install mpd
• That worked ok - now for upmpdcli...
• Requires upmpdcli.list in the sources.list.d directory, so renamed the old mpd one for that!
• Did sudo apt-get update; sudo apt-get install upmpdcli
• Damn....
• Reading package lists... Done
• Building dependency tree       
• Reading state information... Done
• E: Unable to locate package upmpdcli
• Mistyped... mdp vs mpd...
• Still doesn't work!
• Reading the MPD installation instructions, it appears that I need to use "jessie" instead of "unstable" in the sources list file...
• No, I don't! I need ".../debian/..." not ".../mpd-debian/..." and "unstable" not "jessie" i.e.
• deb http://www.lesbonscomptes.com/upmpdcli/downloads/debian/  unstable main
• deb-src http://www.lesbonscomptes.com/upmpdcli/downloads/debian/ unstable main
• Now running... Hurray!
• pi@raspberrypi:/etc/apt/sources.list.d $ ps -ef |grep mpd
• mpd       4326     1  0 11:44 ?        00:00:00 /usr/bin/mpd --no-daemon
• upmpdcli  5367     1  0 12:15 ?        00:00:00 /usr/bin/upmpdcli -D -c /etc/upmpdcli.conf
• I may still need to switch to the upmpdcli version of MPD to resolve some bugs, in which case I'll need to review the sources files

Working!! At least, Kinsky is seeing both the server and the renderer, and in principle I'm playing some music, but I need to connect it to the stereo...

It transpires that MPD can't see the DAC! Now I need to check I've got that configured right...
OK, reconnected ODAC - now it can be seen, and I can use
aplay -D plughw:1,0 /usr/share/sounds/alsa/Noise.wav 
to play white noise. -D hw:1,0 doesn't work though!!
Also, speaker-test -c2 -D hw:1,0 works ok as well. WTF?? [Later: Realised clever old speaker-test generates a pink noise signal that suits the DAC, because it clearly enquires what the DAC can do and gives it to it!]

Tried alsamixer -c 0 which displays the ncurses control - raised volume to top of green, did same for -c 1, now aplay -D hw:[0|1],0 FrontCentral.wav seems to work.

Current state:

pi@raspberrypi:~ $ amixer -c 1

Simple mixer control 'PCM',0

  Capabilities: pvolume pswitch pswitch-joined

  Playback channels: Front Left - Front Right

  Limits: Playback 0 - 110

  Mono:

  Front Left: Playback 79 [72%] [-15.50dB] [on]

  Front Right: Playback 79 [72%] [-15.50dB] [on]

so I've got some volume on there. I wonder if I should go to 0db?

More interesting info about ALSA and RPi here... I've set the ODAC to 100% volume, so let's see what happens.

Tried

aplay -v -c 2 -D plughw:1,0 /media/pi/Thomas\ Dolby/Oceanea\ EP/Lossless/03\ To\ The\ Lifeboats.wav 

Playing WAVE '/media/pi/Thomas Dolby/Oceanea EP/Lossless/03 To The Lifeboats.wav' : Signed 24 bit Little Endian in 3bytes, Rate 48000 Hz, Stereo

Plug PCM: Hardware PCM card 1 'ODAC-revB' device 0 subdevice 0

Its setup is:

  stream       : PLAYBACK

  access       : RW_INTERLEAVED

  format       : S24_3LE

  subformat    : STD

  channels     : 2

  rate         : 48000

  exact rate   : 48000 (48000/1)

  msbits       : 24

  buffer_size  : 24000

  period_size  : 6000

  period_time  : 125000

  tstamp_mode  : NONE

  period_step  : 1

  avail_min    : 6000

  period_event : 0

  start_threshold  : 24000

  stop_threshold   : 24000

  silence_threshold: 0

  silence_size : 0

  boundary     : 1572864000

  appl_ptr     : 0

  hw_ptr       : 0

with success! But why?? Note it's plughw, not hw. 

Found out! hw provides direct unmediated access to the hardware driver, so if the sample rates etc. are not supported by the device, it just errors. plughw provides an intermediate software layer that converts the data stream to match the modes provided by the card. Hurray. so 

aplay -v -c 2 -D hw:1,0 /media/pi/Thomas\ Dolby/Oceanea\ EP/Lossless/03\ To\ The\ Lifeboats.wav 

works just fine! So how do I make sure all this works from mod?

Easy... just modified /etc/mpd.conf so that it has hw:1,0, and Robert is your father's brother. Ridiculous. I think the main points are

• Make sure the DAC is properly plugged in! Check using the ALSA utilities
• Check the replay volume
• Know your format - if the format is not supported by the DAC, then plughw will be required - critical if I'm to get a straight-through path organised
• I have some nominal 24/96 material in AIFF (CD) (Bowie's Blackstar) but it appears to be 3 bytes when the card is claiming it supports only 2 i.e. 16 bits?! So it doesn't play..
• Curiously, the ODAC web site says  "Audio Formats 16/44, 16/48, 16/88.2, 16/96, 24/44, 24/48, 24/96" - that includes 24/96!!

This blog talks about sndfile as a possible decoder choice - put that in mpd.conf, makes no difference, I suspect mpd has all the modules/plug-ins it needs, and only needs to be configured for the ones that change its behaviour from an i/o point of view.

Tried converting Blackstar.aif to Blackstar.flac - now Kinsky appears to be having trouble forgetting the old one! Checked the file content, it appears to be 24 bit, according to Apple mdls.