IQAudio I2S Pi-DAC+

I received this a while back but had not had time to set it up previously.

IQAudio Pi-DAC+

Setup

I had a new RPi3, set it up with Rune which is a Volumio equivalent on a different Linux platform (ArchLinux - only 32 bit) but already compatible with Pi3. Works wonderfully well, doing everything  I set up for myself with MPD etc. in a flash. The Pi3 built-in wireless works a treat, but has crappier reception than the USB plug-ins.

Rune does UPnP OOTB, so I was able to test with the headphone output and the MinimServer on my Mac as a music data source. Very impressive that it all worked perfectly in a stress-free manner.

Plugged the DAC+ into the RPi GPIO pins no problem, using the supplied stand-offs and screws. Powered up - recognised immediately by Rune interface, told it to use it.

Plugged my USB drive into the RPi, restarted things. Drive and music recognised, Rune UI showed Library updating. All good.

Evaluation Approach

My approach to evaluating DACs is simple.

1. Plug the DAC for evaluation into the Disc2 input of the Chord pre-amp
2. The Naim CD2 is meanwhile plugged into the Disc1 input
3. Disc1 and Disc2 have the same gain setting - this makes sense as long as the DAC and Naim have the same nominal output, I check this in the specifications
4. Using the 80s vintage HiFi News Test Disc, which has some very nicely recorded music on it, play the same track on both my Naim CD2 and the DAC, starting at approximately the same time
5. Switch between Disk1 and Disk2 using the Chord preamp remote control, sitting in the main listening position 

This allows me to A/B the two sources pretty easily, and when there's an interesting bit, switch conveniently from one to the other. "Interesting" usually means spatially amusing, or transiently brisk.

Observations

In isolation, the DAC sounds fairly bright, and does have space around instruments. I've only listened to some classical at this point, including some Hildegarde of Bingen, as that is probably more critical than most rock in respect of the factors I'm interested in i.e. soundstage, spatial location, "air", timing.

Listened to against the Naim, the Naim sounds dull initially, and not so immediate, almost boring. However, listen harder and for longer, and the acoustic of the Naim sounds deeper and more detailed. The instruments sound woody, and less brazen, sibilant. This is on only two tracks so far, so it's a bit unrepresentative, so more listening to do.

At this point, I'd not swap the Naim out for this DAC. at least, not for the main stereo setup.

I also have to compare this to the ObjectiveDAC (a USB-connected unit) - I'll be able to do that from the Pi directly, as it allows for both to be plugged in at the same time, and switched between. Cables are a bit of a problem as I don't have two identical sets of RCA cables, so I'll have to try with one setup and then switch the cables and try again.

How much have I allowed Rob Watts' presentation to influence me? Quite a bit probably, but then, he is a long-time listener and digital dude, so that's not necessarily a bad thing. Of course, I'd like to hear Mojo/Hugo/Dave in this setup. Maybe I can if I nip along to Audio-T...

Digital Audio Principles and Techniques

Digital Audio Principles and Techniques

This page is just a place to keep some notes about various concepts that appear to be important in the sonic quality of digital audio processing. It's been triggered by the excellent presentation by Rob Watts, Chord Electronics' digital audio consultant responsible for Hugo, Mojo and Dave. He uses lots of terms which I didn't really understand, and it's in the interest of grasping the DAC process that I started this investigation.

Noise Shaping

One of the effects of quantisation is noise i.e. the difference between "reality" and the numeric representation of that reality manifests itself as random noise. Example: Assume allowable values in digital system are 0-9; sample at time t has value 5.4, which is quantised to 5. The difference (0.4) will manifest itself as noise, and clearly varies randomly (or is it random??) across samples.

Reducing bit depth i.e. the number of bits being used to represent a signal [not yet sure why you'd want to do this - seen it referred to as part of DAC construction/design] results in quantisation noise also, however, by using a feedback loop such that the noise value for the preceding re-quantised sample is used to alter the quantisation of the current sample. The way in which the feedback is applied can be used to "shape" the energy spectrum of the noise, such that although the total energy is the same, the visible/audible/perceptible effect is reduced because the energy is lower in the more sensitive areas. Phew. Cool though.

See this Wikipedia entry for more specifics.

Dither

Actually, quantisation error is not random... It generates harmonics i.e. non-random distortion. Adding random noise of some spectrum to the signal prior to sampling makes the noise more random, and reduces the maximum level of the distortion/noise, although again I suspect the overall energy is constant.

1 Bit Conversion (!)

It's easy to understand multi-bit e.g. 16 bit ADC. Conceptually, the analogue signal is a continuously fluctuating voltage. The voltage is measured at the "sample rate" e.g. for Red Book CD 44.1k times/sec, and the resulting measurement is "quantised" to the current bit depth i.e. to fit in the number of possible values. So for 16 bit audio, the value can vary between 0 and 65535 i.e. 0 to 2^16-1. So how would a 1 bit ADC work?! I've always struggled with that...

Apparently, by using a colossal sampling rate e.g. 2.4MHz in the case of DSD, and 1bit (with a dynamic range of 6 dB!), then doing (serious!) noise shaping to push the noise out of the 20-20kHz region into the ultrasonic, you can get > 100dB SNR/dynamic range. However, it is hard (impossible?!) to add reasonable amounts of dither in the feedback loop in the pure 1 bit case, so most realistic systems use more bits to enable better and more effective dither. Sounds like DSD is crap to me... Fundamentally flawed. Especially as it gets turned into PCM anyway...

Decimation

The process of reducing the bit depth or sampling frequency, for whatever reason. Interestingly, this requires two steps

• Reduce high-frequency information so that fmax is < new sample rate; this is to prevent aliasing in the resulting digital output; this can be done with a digital filter, using IIR or FIR techniques
• Resample the data i.e. chuck away all the unwanted bits/samples

Obviously this reduces the effective bandwidth and dynamic range, but you'd expect that. Rob Watts describes using downsampling as part of the DAC process, not sure why yet, maybe it's to simplify the conversion i.e. by requiring fewer steps.

[Infinite|Finite] Impulse Response Filtering

Digitally represented signals can be filtered for frequency response i.e. low/band/high-pass filtered using two approaches

• Infinite Impulse Response
• Finite Impulse Response

Analogue electronic filters are necessarily IIR i.e. their components always retain some trace of an impulse input in their state. Thus capacitors retain some charge, however long you wait (although admittedly vanishingly small) and this necessarily impacts the working of the filter.

The presence of feedback in a digital filter generally creates an IIR filter and its "z domain transfer function" contains a denominator in its sequence of terms. An FFR series contains only a numerator. 

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]