Linux USB Audio - Trouble Shooting

(Latest update: Mar-6-2022)

USB audio interfaces are pretty much commodity products nowadays. Usually these are plug'n play

on whatever rather recent system.

In the early days people were facing a lot of hiccups with USB audio. This situation has greatly improved over the last 10 years though.

However. From time to time you still see discussions popping up about this or that issue related to USB-audio. 

Situation

With the huge number of ARM based Single Board Computers (SBC) - such as the Raspberry Pi - around, Linux and Linux Audio in particular gets more into the focus in recent years.  You'll find numerous commercial audio devices - streamers etc. - that run a Linux based SBC inside.  

Not to forget. Android. Meanwhile the Android mobile devices market-share  counts ~71% (2022)  nowadays. Meaning. A huge chunk of tablets and phones run Android and therefore Linux Audio.

However. Many audio device manufacturers still do not commit (by naming it) to support Linux or Android. They rather refer to "Class Compliance". It means a device works without a dedicated or proprietary driver under Windows and OSX. Usually a "class compliant" generic USB Audio driver of either operating system is being used. The great (old) news. The generic Linux USB audio driver is also "Class Compliant". Since the vast majority of USB audio interfaces are Class Compliant nowadays most devices will also work on a Linux (or Android) system. 

There are exceptions. 

1. Pro-Audio Interfaces
   Even if companies like RME market "Class Compliant" audio interfaces, it's not the full story.
   The "Class Compliant" - let's call it  "Mode" - usually offers a subset of features that these devices are able to provide. To get full access to all the fancy features you'd have to install a proprietary driver again - usually available for OSX and Windows only.
   My advise. Stay away from these devices. Beside not being able to use the advanced features, you'd also have to pay for features that you won't ever get to use.
   
   
2. Almost-Compliant Class Compliant Interfaces
   Some audio device manufacturers try to push the audio device firmware to its limit. E.g. by making use of rarely used sub features of the Class Compliancy spec. This can and does lead to malfunctions under certain conditions. The Linux Sound Layer developers maintain a so-called list of "quirks" coping with issues for interfaces that were reported to them by the manufacturers. 
   These quirks are an extension to the generic USB Audio kernel driver and cope with these "almost" class compliant audio interfaces. Each of these devices requires its own quirk. Almost compliant devices usually exhibit weird behavior if working at all. 
   
   
3. Flawed Interfaces
   Yes, these also exist. There's no guarantee that a device firmware is flawless. Make sure any device you purchase offers a firmware upgrade option.

Early NOTES: 

1. Check with the manufacturer or store about compliance and/or known issues
2. Check with the Operating System provider about compliance and/or known issues
3. Check with Google or the community

Make sure you can return the device. I would do it rather quickly. Hoping for a quick solution for too long might get you hooked up to a device that'll never really work under Linux.

Overall things are getting better. However. There are still plenty of cases where you'll experience NO SOUND or choppy sound or so called XRUNS (buffer underruns).

That doesn't necessarily mean that your device won't work under Linux.

This article tries to give some guidance for troubleshooting your USB audio interface under Linux.
You should gets certain hints what to look for and what to try before returning your device.

Alsa - The Linux Sound Layer

Linux comes with the Alsa soundlayer. It's the operating system layer that manages the low level audio processes and talks through the drivers to the audio device. The audio application uses function-calls provided by the Alsa library (API)  to talk to Alsa .  And Alsa then talks to the audio interface on the other side.

There's a lot of ping-pong going on on that interface. And that's probably the reason why you're reading this article. From an a Alsa perspective one thing needs to be explained. The device handling towards the user. What the user sees from Alsa.

Alsa differentiates between and offers Devices and so called PCMs.

The Alsa Device reflects the actual direct HW access. The Alsa PCMs are virtual Alsa devices, basically, an abstraction layer on top of the device layer. These PCMs were introduced to cope with application and device mismatches. An application would e.g. deliver a 24-bit stream and the audio device would support 32-bit only. A PCM called "plug" would have to cope with it. For obvious reasons these PCMs are not necessarily bit-perfect. These PCMs could also get access to some advanced or hidden functions. I usually stay away from using these. If your application outputs the format the Device can read, there's no need for a PCM. You need to configure your application yourself of course.

Applications, such as squeezelite, do most of it automatically.

With most modern DACs and up2date OS, kernel and applications there'd be no need for that PCM abstraction layer.

Unfortunately all these PCMs causing a lot of confusion out there. Most applications (squeezelite/Moode-mpd/asf)  list numerous PCMs to choose from.  99% are not only useless, no,  they even do not work properly.

Let's do some work.

Checklist

When running into trouble it's always good to have a guideline

Analyze the issue

• What are you experiencing?
• When did it happen, when did you notice it the first time?
• Was it working before?
• Is it working on different computers or operating systems? 
• What did you do before running into the issue? Changing HW? Or SW? Or firmware?

All these questions help to isolate and to describe the problem much better.

Make sure you note these things down. It gets you structured and you'll need

these infos when getting in touch with others about it. Without asking structured questions you, won't get proper answers.

You should also note down, the HW and SW and corresponding versions of it.

Of course if you've seen error messages - store and don't ignore them!

Basic Troubleshooting

• Check the cables and power supplies. You might re-plug or swap them.
• Make sure that the RPi power supply is able to deliver sufficient power.
• Re-power the system.
• Rollback to the last working setup.
• Try different USB ports ( e.g. on RPi USB3 vs. USB2 ports)
• Try an external powered USB HUB in between your DAC and computer.
• Basically, make sure that your audio device HW and cabling is OK. 

Class Compliancy

Let's have a look a the bigger picture.

Make sure that your device is fully Class Compliant. Sometimes also called UAC2 or UAC1

compliant. Ask the manufacturer or dealer. Or google it. Check if a Linux operation should work.

Ask if a special "customized" Class Compliant mode is implemented. Manufacturers who intend to walk the extra mile by writing custom firmware might have missed something. 

If anything of that turns out to be an issue, get rid of that audio device! Do not count on somebody getting a firmware fixed for a Linux device. Case Closed!

Audio Device Selection 

As explained earlier, usually you'll be shown a huge list of these virtual audio devices = PCMs within your favorite application or OS.  

As an example, the PCMs list for my iFi DAC look like this:

• sysdefault
• default
• plugequal
• equal
• hw:CARD=AudioDOP2,DEV=0
• plughw:CARD=AudioDOP2,DEV=0
• sysdefault:CARD=AudioDOP2
• front:CARD=AudioDOP2,DEV=0
• surround21:CARD=AudioDOP2,DEV=0
• surround40:CARD=AudioDOP2,DEV=0
• surround41:CARD=AudioDOP2,DEV=0
• surround50:CARD=AudioDOP2,DEV=0
• surround51:CARD=AudioDOP2,DEV=0
• surround71:CARD=AudioDOP2,DEV=0
• iec958:CARD=AudioDOP2,DEV=0

That even confuses me. "surround71" for a 2 channel device!?!?

For a modern DAC, that doesn't require a PCM device, this setting

• hw:CARD=AudioDOP2,DEV=0

should do. 

For your device you'd find "AudioDOP2" replaced with your DAC ID.

This setting addresses the audio device directly and passes by the PCM layer.

You could also use the most basic device IF Linux as to offer:

• hw:0,0

The first 0 means, it's the first audio device on the system. Replace it with 1 and you talk to the 2nd audio device on the system. You can enter it manually.

You might also try

• plughw:0,0

If the "hw" approach causes issues.

I hope that gets you there.

Operating System 

Kernel 

The key element on every Linux system is the kernel.  The Audio driver comes with the kernel.

It actually doesn't really matter if you run a Moode, Volumio, pCP, Diet-Pi or whatever RPi OS.

What really matters is that you run an OS with the latest kernel - the latest RPi Foundation kernel.

For a RPi I prefer the Raspberry Pi OS by a large margin. The kernel and firmware is simply the best

and most reliable out there.

The great thing with RPis in particular is: Pretty much all related OSes run the same kernel base, which is provided by the RPi foundation. However. Not all Audio OS derivatives are as up-to-date and well integrated and tested as RPi OS. There are differences!

However. The chance that you run into a kernel related issue I'd consider rather low though.

Firmware

HW related firmware can very well be a source for USB related issues.

We look at two different firmware angles.

Computer firmware

First the firmware that resides on your computer. The RPi requires firmware for the USB controller.

Make sure that you have the latest firmware installed! The RPi4 introduced a new USB controller.

There've been a lot of hiccups in the beginning. It took them about a year to get things stabilized.

Audio Interface firmware

The other firmware angle is related to your audio device. E.g. the widely spread USB receiver from XMOS requires a firmware. This firmware interacts with the computer and the DAC internal electronics. It's crucial to the inter device communication.

Especially if new XMOS versions pop up or new and less experienced DAC manufacturers are programming such a firmware issues can pop up. Usually these things very quickly pop up on the WEB though. And therefore get fixed rather quickly. Google will be your best friend again.

Most audio interface related issues I came across were nasty turn-on or turn-off thumps, strange noises when switching sample rates or from PCM to DSD. All this usually relates to the audio HW. You'd need to talk to the manufacturer about it. In my case. My Gustard A18 causes a very loud thump when starting squeezelite. You can't do anything about it. It's a major flaw in the audio HW.

Before buying an USB audio device make sure there's an option with your DAC that allows for a firmware update - and doing it without the need for a master degree in IT! Do not underestimate this! 

Before discussing your issues with others, make sure you run the latest operating system release, kernel and firmware! 

Application

The same applies for your audio application. Makes sure you run the latest version before further tracing down your issues.

Very often you read about users experiencing buffer under-run issues  so-called XRUNS, which sound like clicks or scratching. 

It doesn't happen often so.

Buffer Underrun means your DAC requires more data then your PC is willing or able to deliver. That's usually caused by competing processes, complex process chains or flawed software on the same machine.

The usual first measure you read about is increasing the output buffer. But that's usually just a workaround and not a solution.  Of course you can try to adjust the buffer to see if the issue disappears.

If we take squeezelite as example. 

Squeezelite applies a 20 ms output buffer divided into 4 chunks (periods) towards Alsa by default.

You might try to increase this buffer by adding

-a 120:4:::

for a starter and see what happens. Do not increase the periods above 4.

The same you can try on installations that use MPD as engine, such as Moode, Volumio, etc.

They'll all offer options to change the Alsa buffer size and periods.

As a 2. measure you can try to increase the task priority.

With squeezelite that would be adding option

-p 45

Note: 99 is max. The higher you get, the higher the chance that you lock up the system.

Log Scanning and Debugging

Now. If all this doesn't help. It's time to do some serious analysis and debugging. 

But that'll require a bit of advanced background knowledge. Scanning the app logs, syslogs, dmesg  etc. Then making sense of what you see. The typical user gets quickly overwhelmed with such a task.

E.g. Alsa also offers a tool to collect all the data that would be required by the Alsa-Dev team to respond to any of your inquiries. That makes it already complex. 

However. From my experience USB Audio under Alsa runs that stable nowadays that the experienced issue usually is created somewhere else. Better contact your dealer, manufacturers or online buddies.

Good luck with getting your device going.


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

ANNEX

Some important logs and traces:

Before running any tests make sure you run a very basic setup. No tweaks etc. Make sure the SW

is up-2-date. Use a basic 44.1/16 audio file for testing. 

dmesg

prints the kernel ringbuffer

dmesg | grep -i USB

prints all messages with string "USB" > not case-sensitive

at this point, you should see your audio device

if you see USB DAC related error messages already at this point, you probably face a driver/firmware or HW issue.

dmesg --level=emerg,alert,crit,err

only errors etc of the kernel ringbuffer are shown

lsmod

lists all loaded external kernel modules. snd_usb_driver should be in that list.

If it isn't in the list, you can skip all below tasks.

lsusb -vv

shows the advanced specs of the recognized USB devices

aplay -l

shows if Alsa has recognized the audio device

getent group audio

This shows which users, beside root, have access to the audio device

journalctl -u squeezelite.service

shows if there are issues with the audio service, change service name if you run a different service

squeezelite logging  parameters:

You need to turn logging on for squeezelite.

Enter below into your squeezelite config screen and restart squeezelite.

-d all=debug
-f /tmp/squeezelite.log

will show what happens during the initialization and playback of squeezelite.
Copy/paste the content of the logfile /tmp/squeezelite.log somewhere safe.

You might change /tmp to a different directory to keep the log

over the next reboot. On pCP this could be e.g.  /mnt/mmcblk0p2/tce

To scan the log run:

cat /tmp/squeezelite.log | more

Turn off the logging once finished. 


OK. That'll do for a start I'd guess.