Raspberry Pi - The Audio Engine - Part 3 - audio interface and squeezelite setup

In Part 3 of The-Audio-Engine series I'd like to write some lines about the audio interface and the squeezelite setup. 

squeezelite in conjunction with the audio interface of choice are the key elements of the entire Audio-Engine project. 
We better make sure to get that setup right!  

The Audio Interface

The audio interface is the audio related key hardware element of the whole project. 

For the RPI we basically look at two relevant types of external audio interfaces.

  • USB audio devices
  • I2S-HAT devices
  • (Bluettooth and HDMI audio devices not in scope)

Internal Audio Device

The RPI also offers an internal audio device, which is of lowest entry level quality. I won't  touch upon that subject more than showing how to disable this device.

USB Audio Devices

USB audio devices attached to the RPI will be driven by the standard Linux class compliant USB audio driver. Pretty much all modern USB DACs will therefore work on the RPI. 

USB DACs will offer not much control features via the generic driver. Most HW related settings will have to be done on the DAC itself.

There are two powering modes for USB DACs.

  • bus-powered - which use the RPI USB connection as power source.
  • self-powered - which need a separate power supply

Attaching a bus-powered device to the RPI is not such a good idea. You'll put quite some
extra load&stress on the rather weak RPI infrastructure. If you want to attach a bus-powered USB DAC better try to get the device externally powered.  

Last but not least. The RPIs major weakness is the joint USB-Ethernet infrastracture.
USB and Ethernet share a single USB2.0 link towards the SOC (CPU). 
If you want to run a USB DAC on the RPI, I strongly recommend to use the OnBoard WLAN as network access. This than will separate network and USB.

That rather weak USB implementation is also a reason why a locally attached USB storage device and a USB DAC shouldn't be used at the same time.

Bottom line. Running USB DACs on a RPI is not the best of all solutions.

I2S-HAT Audio Devices

The RPI offers an I2S interface right from its SOC towards the GPIO pins. And that opens
a great opportunity to attach I2S audio devices, so called I2S-HATs.

I2S-HATs need dedicated kernel drivers though. Writing and maintaining drivers is a
hell of a job. Not every small company is capable of writing a driver or able to afford it.

That leads to different approaches.

  • some I2S-HATs work with generic I2S drivers - no special features
  • some come with dedicated drivers - because of special features
  • and others simply make use (piggyback) of the dedicated drivers

That lead to the availability of numerous I2S-HAT audio interfaces. You'll find everything
from entry level devices to audiophile audio devices out there.

The audio quality you can achieve heavily depends on the quality of audio device you'll attach. 

Many of the I2S - HATs offer special features. Such as

  • Oversampling filter selection
  • Internal volume control
  • Certain operational modes
  • Output selection
  • ...

It's IMO very important NOT to neglect these options. The right feature selection can make quite a difference to the resulting performance of your audio device. 

Let's get started.

Audio Device selection

Select your audio output device.  And save the setting immediately.
pCP must and will reboot to enable the audio device driver for your audio device.

After the reboot you can continue.

Card Control

Many audio DAC devices offer "Card Control" setting options.The audio card driver makes these available/accessible.  Basically you can program settings right on your audio device.
That's the main reason why there's no need to have a display or controls on your DAC!

pCP does not necessarily offer all card control options!!! To lookup and to access all options you'd need to ssh into pCP and run a program called "alsamixer" or "amixer". 
Most basic options are usually covered through pCP though!

A widely used DAC family for the RPI is the Texas Instruments PCM51xx DAC family.
It's being used on the Allo Piano2.1, Allo Boss, several HifiBerrys, IQAudios asf. 

For these DACs you'll find several parameters/features to play with. 

Below printout shows my preferred "Card Control" settings for the IMO excellent Allo Piano 2.1 in Dual-Mono mode in conjunction with the Allo Kali I2S reclocker.

(Update: I turn "Toggle a 0.8dB increase..." OFF - and not as shown below "ON". I'd suggest to untick it! )

        Image 1: Allo Piano 2.1 in DUAL-Mono  example

Before you continue. If you have enabled HW volume control (-V) in the squeezelite settings section, take it out before you start doing changes in the "Card Control" section. I ran into a very strange behavior during the setting process.

To do the initial setup properly follow below order:

  1. Disable the "RPi Builtin Audio"
  2. Now you configure the Dtoverlay parameter options - if applicable
  3. Now you do the Alsamixer settings

You better now reboot the RPI and verify that all settings are loaded as you've selected them! 

The setting process is a bit awkward. Lot's of SAVE and reboots.

At the bottom of the blog article I'll outline setting options for specific DACs. Currently covered are

  • Allo Piano 2.1
  • Allo Boss
  • AudioPhonics iSabre 9038Q2M (work in progress)
  • ...
(I'd be happy to put more devices to the list - just get in touch with me)

Squeezelite parameters

There's quite a number of squeezelite parameters to look at. Let's do it.

     Image 2: Allo Piano 2.1 in DUAL-Mono  - Full File buffering example

1. Name

    Choose whatever you like (1 string - alphanumeric - no spaces)

2. Output setting 

    Usually picoreplayer fills in the default audio device name automatically, once you're
with the Audio card control settings.

    These automatic default settings can also be replaced with standard Alsa terminology
    as shown above.


3. Alsa setting

    These are Alsa - The Linux soundlayer specific settings. These settings define
     the Alsa interactions with the Audio device.     
    The first field takes the Alsa Buffer setting. That buffer is the last buffer between
    the RPI OS and the audio device. It can get very important. E.g. if you experience clicks,
    pops or XRUNS. 

    One of the main subjects is that I2S-HATs and USB DACs need completely different


    Buffersize     =   65536    (=2^16 bits) 
    Periods         =   4            (buffer will be divided into "4" chunks (=periods))
    Bit depth       =                 (empty = automatic)
    MMAP          =   1             (enabled  -> device memory access)

    These settings work for pretty much al I2S HATs I tried.

    USB DACs 

    Buffersize     =   160        (= 160 ms) 
    Periods         =   4            (buffer will be divided into "4" chunks (=periods))
    Bit depth       =                 (empty = automatic)

    MMAP          =   1             (enabled  -> device memory access)

4. Buffer size settings

    These Buffer settings shouldn't be mixed up with the Alsa buffer settings.

     squeezelite offers two buffers 

  1.      The stream buffer
  2.      The output buffer (output from squeezelite to Alsa!)

     How it works. squeezelite puts the received audio data stream into the stream buffer first.
     The internal processing stages e.g. flac-pcm conversion, resampling or
     volume control will 
then be executed. 
     The result - the almost fully processed data get stored in the output buffer.
     The data will be stored at 32bit in that output buffer - always 32bit.
     The two things that'll still happen after the data leaving the output buffer is 

  1. the SW volume control
  2. bit-depth adjustments

     If you look at below setup proposal, you'll see 20000:500000.
     That means we look at a 20MBytes stream buffer and a 500MByte output buffer.
     What happens is that squeezelite reads and processes the entire file
     as soon as you push the PLAY button. You'll see a high peak load
     in the first couple of seconds of playback and then the fully processed file
     is played back from a RAM buffer. A typical CPU load during RAM playback will be
     around 1% on a 3B+.

     Note: For streaming services like Tidal, Qobuz etc., FullFile RAM playback doesn't work.
     Just use 10000:20000 or similar.

5. Restrict codec setting

    The order of codecs as listed in the "Restrict Codec Setting" field for squeezelite,
    defines the order of streaming/conversion rules applied by the LMS server towards the
    streaming client. Here we have pcm,flac,mp3. pcm gets first priortity, because it's first on
    the list.
    I usually recommend to run PCM streams.  Such a FLAC->PCM rule will be
    used for the streaming-client 
if "pcm" is first on the client AND mulitple options are
    enabled in the LMS routing setup.
 Got it ?? OK. Once more.

As you can see 3 rules are active. Without using this "Restrict Codec Setting" field
to redefine codec priorities a flac-file would be send as "FLAC-Native".
That's hardcoded inside squeezelite.

You'd never know what's hardcoded in whatever client. By using this field you 
can control these priorities without having to disable any rule. You might want to run 
mp3 towards another wireless client. Then just change the order of codecs listed 
in this field on that client.

6. Various input

    1. "-W" = Read stream parameters from PCM header

     Basically "-W" allows server based resampling and still sending out PCM streams.
     Since I use (and recommend) server based 352k8/384k resampling to PCM for the
     Piano2.1/Boss. I have written another article of how to accomplish the server based

     2. Use HW/DAC internal volume control

     Basically "-V Master" controls the "Master" volume control as being offered by the driver.
     The name "Master" is freely chosen by the designer who wrote the driver.
     For the Allo Boss it would be "-V Digital".
     I use this HW VC  to avoid having two digital volume controls (squeezelite+DAC) in
     the loop



That'll be it for now.

Make sure you don't miss the LogiTechMediaServer setting article. There are certain overlaps and dependencies (e.g. under "Advanced Settings - File Types")

It's mandatory for a complex system to have all parts involved aligned and under control. 
This way and only this way you'll end up with a great performing audio streaming system!

And again. Once in a while check your card settings  - these somehow tend to get changed over time!




Allo Piano2.1 Setup

Now I would like to discuss some specific settings for the Allo Piano2.1

The Allo Piano2.1 IMO is an excellent DAC - if used with the Allo Kali reclocker!!!
I'd stay away from it without having a Kali in place.
Without Kali the Piano would face 
the pretty poor I2S performance of the RPI.
Beside that the Piano doesn't have the best 
onboard clocks. Adding the Kali is IMO a must if you look for quality audio.
If you just look for a standalone DAC HAT, the Boss1.2 would be the much better choice. The Boss comes with outstanding jitter and clock specs. The Kali/Piano combo IMO still has a little edge over the Boss.

Now. We do have several more options to get the Piano21 performing rather well.

1. We'll  enable "glb_mclk" in the Dtoverlay settings.  Basically we'll make the Kali
    the clock master. That's a crucial setting! We'll get the PI jitter somewhat under control
    this way.
2. We select "Ringing less low latency FIR". To my taste that filter sounds best.

    NOTE: At this point there's another IMO must-do (for the more ambitious readers).
    You should "synchronously" upsample 
your data on LMS to 352.800 (44.1x) or
    384000 (48x). 
Doing this will bypass these rather mediocre on-DAC filters, such as
    my favorite "Ringing less LL Fir" filter. 
    There's quite a nice and well maintained LMS plugin which could do the usampling job.
    It's called C-3PO. Or you can simply add 3 lines to your LMS custom-convert.conf (see
    Case1 in the linked article).
    I would not recommend to do the upsampling with squeezelite!

3. Simple mixer controls. The "Toggle 6db" setting sets the DAC output to 2V. Turn that ON.
    It's a must! Having that option turned OFF would set a pretty low 1V output mode which
    IMO sounds extremely flat.

    Stay away from the 2nd "Toggle 0.8 db" setting. Keep it OFF.
    In above image it's still selected! Deselect it! If you had it ON.
    From my experience - if ON - it first sounds more dynamic. Soon I realized
just get bloated. Stay away from it - just turn it OFF!
4. Finally select Dual-Mono. The Piano comes with two DAC chips. In Dual-Mono
    one channel gets muted on each DAC. That'll reduce some crosstalk I'd guess.
    I havn't seen any measurements from Allo in this regard.
    Unfortunately Allo didn't manage to couple the outputs in parallel. Would have been a real
    Dual-Mono setting.

Now you're set on that side.

5. However. If you still experience problems with your settings, you can also try to set your  card mixer controls from commandline.

Just run below process step by step:


ssh login as user tc

export TERM=xterm
sudo sh -c "pkill squeezelite"
sudo sh -c "cat /dev/null > /var/lib/alsa/asound.state"


sudo sh -c "alsactl store"
pcp bu
sudo sh -c "sync ; reboot"


What are we doing here?

1. We set the terminal mode first.
2. We stop squeezelite, because if squeezelite is up'n running it might lock the DAC
    interface and certain settings might not
 get applied. 
3. Then we reset the alsamixer settings.
4. By using the program alsamixer we'll set the DAC parameters.
    Once finished setting all the params,  just press the "Esc" key on the keyboard
    to quit alsamixer. 

5. We'll then store the alsamixer settings on the pCP RAM-disk
6. Finally we backup the RAM-disk to SD-card - otherwise all settings will be gone after a reboot. 
7. Now we run a reboot, to give it all a clean start.

8. Just for fun, after the reboot you could have another look into alsamixer to see if everything is still there. 


  1. Replies
    1. Please, send my your e-mail - Please use the new contact form!

    2. Hi Klaus,

      What exactly is in the Binary ? It will work with rp2+Kali+AudioGD Hdmi output ?



  2. thanks for the write-up. i set alsa buffer as 44100 bytes (or multiples) for 16/44.1 material with very good results as per this article https://www.alsa-project.org/main/index.php/FramesPeriods. i am curious to know how you ended with 16384.

  3. That makes an impressive change! Thank you!!!