Audio Interface appears to be connected, doesn't play sound. (MSI, Focusrite)

I have a Focusrite Scarlett Solo 2nd Gen Audio Interface plugged in via USB to my motherboard, an MSI B450-A PRO MAX. Up until a couple of weeks ago, it always connected properly, but after an update I’ve been seeing serious problems.

There is another thread about a similar problem here. For clarity, I am also having that problem, but this thread is about a separate problem which is probably related, hence making a new post - I hope that’s ok.

The linked problem seems to be unique to MSI motherboards, so that’s probably at least part of the cause of this problem too. Whilst that one can be solved by a single command, my problem seems more pervasive.

When connecting my audio interface on my primary OS (manjaro kde, up to date), it reliably fails to initialise properly - meaning the hardware itself cannot process audio in or audio out. Even if I have the right audio profiles shown in PulseAudio, the interface acts like it has a power connection but no data connection, it doesn’t even illuminate its own light showing that the mic is being used, or direct the mic audio internally to the monitoring output, which is bizarre. Pulseaudio shows audio is being sent to it but the interface does nothing at all.

I’ve done some investigation, and the problem keeps getting stranger.

When using a fresh OS (namely, one which hasn’t been manually updated since approximately mid-august, which applies to new installs from the manjaro site at the moment), the device works reliably after connecting it via USB.
However, if I update that OS, the problem comes back. The alternate install I tested this on was fairly new and not heavily modified from fresh install.

The strangest part is that after restart, the audio interface usually retains its functionality from the last time it was connected, regardless which OS is running now.
Whilst running the OS in which the audio interface works properly, if it was last physically plugged in whilst in the OS in which it doesn’t work properly, it will remain inoperative until I re-plug it.
The same thing sometimes happens the other way around, though sometimes it just doesn’t appear at all, I think this varies with which kernel is active.

Because of the fact that all I had to do was run an update to recreate the problem, I am assuming the problem is being either caused or catalysed by a package, without any custom configuration.
Because of this, I assembled a list of all the packages present on the system where it works properly which were either absent or different versions on the system where it doesn’t work properly.
This means that one of the items on that list, if installed (as a downgrade) on the OS with the problem, would theoretically fix the problem. Unfortunately it’s 700 items long, but that narrows it down somewhat. Simple List | Detailed List.

I’ve tried various different kernels, disabling a bunch of motherboard settings including disabling all overclocking, every different USB port I could think of, removing peripherals and internal cards, downgrading all system packages to the start of august, and even left the audio interface unplugged for a few hours. None of these produced a long-term fix.
The only thing which reliably reproduced the problem was running the mid-august update from a fresh install.

The indications I have so far do not indicate that the audio interface is likely to be broken, I’m pretty sure this is a software configuration which, as published, is partially incompatible with most B450 MSI motherboards.

Using the ‘unsupported’ linux 56 kernel fixes the bug (untenable because I need zfs), but every other kernel reintroduces the bug (currently on 4.19, same problem), even without running a full system update. Is it possible that some hotfix was applied retroactively to older kernels? I never used to have this problem.

If there’s no way a change was added to older kernels retroactively, which package(s) could affect this? I’ve already gone through all the ones which seem obvious and downgraded or removed them.

On EndeavourOS and Artix the bug is present when using a kernel newer than 5.6, but there’s no problem otherwise.
EOS uses Arch Kernel and Artix uses its own fork, but the same thing happened on both of them.

This seems like it could be a pretty deep problem and yet I’m not seeing anyone else with it. Can anyone suggest any possible avenues to investigate here?

Here’s the journatlctl / dmesg when I connect the device:

Sep 04 09:38:05 dreadnought kernel: usb 3-1: USB disconnect, device number 9
Sep 04 09:38:09 dreadnought kernel: usb 3-1: new high-speed USB device number 10 using xhci_hcd
Sep 04 09:38:09 dreadnought kernel: usb 3-1: New USB device found, idVendor=1235, idProduct=8205, bcdDevice= 4.5c
Sep 04 09:38:09 dreadnought kernel: usb 3-1: New USB device strings: Mfr=1, Product=3, SerialNumber=0
Sep 04 09:38:09 dreadnought kernel: usb 3-1: Product: Scarlett Solo USB
Sep 04 09:38:09 dreadnought kernel: usb 3-1: Manufacturer: Focusrite

It’s called a “regression bug” and the best thing to do is to look for said bug on or raise it yourself…


The similar problem you linked to is unlikely to be resolved. OP has not returned since announcing their departure for the 3rd time

This is a different MSI motherboard, but it has the same ALC892 audio codec and B450 chipset

If I find anything in the ALSA data and online I will start a new topic about it

The built-in audio device could be turned off in BIOS but I do not think it is harming other devices, but the Focusrite interface should work despite any onboard audio problem

System data is showing device is using USB 3.0 driver xhci_hcd
Audio interfaces with only 2 inputs and outputs are usually ‘USB class-compliant’ down to USB 1.1
(OHCI or UHCI) but will also work ok on USB 2.0 (EHCI)
Host controller interface (USB, Firewire) - Wikipedia

Suggest the Focusrite device is plugged in to a USB 2.0 socket if available
(black socket instead of blue for USB 3.0)
and check if any option for ‘USB legacy support’ in BIOS is enabled

whilst in the OS in which it doesn’t work properly, it will remain inoperative until I re-plug it
The same thing sometimes happens the other way around, though sometimes it just doesn’t appear at all, I think this varies with which kernel is active

Are you dual-booting system with another Linux OS or Windows ?

There are 2 USB devices present and they may not be assigned the same card numbers in ALSA every time (and card number may change if a device is unplugged)
suggest if device is in a non-functioning state to check if card numbers are different
also suggest try using only one USB device and see if errors continue
(USB devices may need to be configured to use fixed card numbers in ALSA)

This device also may not be happy if audio quality is only CD quality (16bits 44100Hz) and may want DVD quality (24bits 48000Hz)

Artix uses OpenRC, runit or s6 (no systemd) so fault is likely to be something common to all these OS and probably not systemd related

There may be a regression bug (possibly alsa-lib packages rather than kernel?) but I would expect other users with Focusrite USB devices to be having the same problem
I hope this is not the case as there are probably a lot of these devices in use on Linux


Thank you for your detailed reply.

I have tried the audio interface in various different sockets, including USB 2. Having tested it on a totally different PC, also running Manjaro, which was also recently updated, the same problem exists there too. This means the motherboard is probably not related to the problem.

USB Legacy Support is enabled. There is also an option for ‘XHCI Handoff’ or something similarly named, which I tried disabling to no effect. The BIOS settings do not change whatsoever between the audio interface working and not working, so finding a solution there is somewhat unlikely.

The other OS I am booting on this PC has been Manjaro, EOS and Artix, not Windows. I could try a debian-based install, but this would be a considerable change just to use a device which worked no problem on Manjaro a few weeks ago.

The other audio USB device has been unplugged plenty since the problem started occurring as well. They do appear as different device names (they appear as hw:Device vs. hw:USB in Jack, the latter being the audio interface).
I believe I have already tried connecting it without any other USB devices connected at all, but I will test again.

Your suggestion about the audio quality is a good idea and plausible in theory, but I’m pretty sure I’ve used 16bit 44.1khz audio with this interface in the past. Where would I go in alsa to change how it connects?

The aspect common to all those distros seems to be the Arch Kernel, possibly some packages too (like alsa-lib, as you mentioned).

I have tried downgrading alsa-lib without success. I could try downgrading further, I suppose, but I doubt that will help. It is the same version on installs where the interface works as installs where it doesn’t. No alsa configuration changes between it working and not working.

Given this is happening to me from a fresh install, after merely updating the OS, I find it unlikely that it’s due to anything I’m doing. If we exclude that, it leaves a fault in the hardware, which is not suggested by what can reproduce the issue, or a problem in software supplied by Manjaro/Arch/third parties.

Is there any chance of a quick-and-dirty solution to fix this even if we can’t find the proper solution? Any long-shots or avenues for experimentation? This audio setup is essential to my work.

Thanks again.

Unplugged all other USB devices, and tried the audio interface in several different ports, but it still doesn’t work.
Disabled the built-in audio in the BIOS, that didn’t work either.
Tried pulseaudio-git based on advice found on another thread, also no effect.
the latest experimental 5.9 kernel gets stuck while booting, but it can still attach the USB device - no help here either.

I’ve checked your link, and used the search terms ‘audio interface’, ‘focusrite’ and ‘scarlett’ and haven’t found this problem listed. I could perhaps broaden my search.

I can’t find any information in my first few searches on whether a software regression would also be ‘fixed’ retroactively across old kernels. My substitution testing has seemed to demonstrate that the kernel is the problem, as swapping only that out on some configurations makes the difference between it working and not working, but the only kernel which DOES work is the ‘unsupported’ one for which nvidia and zfs modules do not work.

I’ve booted using kernel 4.19 and the problem persists.
I’ve also run ‘supported’ kernels but without nvidia, zfs, and other modules, the pattern is the same.

So just to clarify: Are you saying that it’s possible that whatever was done to recent kernels which has made my audio interface inoperable was also applied retroactively across all old kernels?
If so, is there no way to get the version of a recent kernel which did not have this ‘fix’ applied, and for which modules will work?

If retroactive changes are not applied to old kernels, then how can we explain the problem?

If I can’t find any solutions soon, I’ll post about this on the kernel bug tracker you linked.

Thank you for your help.

Yes. A solution would be to use one of the (still supported) Real-Time (=RT) kernels as:

  • they’re geared towards audio/video buffs who want as little latency as possible (and lab technicians, real-time server admins, …)
  • they receive less updates and when they do receive updates they’re thoroughly tested.
mhwd-kernel --list
available kernels:
   * linux414
   * linux419
   * linux44
   * linux49
   * linux54
   * linux57
   * linux58
   * linux59
   * linux54-rt
   * linux56-rt

in the above list, the last 2 are the RT-kernels…

Thank you for this advice. I have tried some real-time kernels already, but I’ll try again.

Is there another source of Arch-compatible kernels I could try? I have tried lqx but as I recall it didn’t boot.

I am typing this from 5.4-RT, the problem is sadly not fixed. Whatever change they made to the kernel, they must have thought it was very important and bug-free because it seems to have been applied here too.
I’m 99% sure I’ve already tried 5.6-RT in the past, but I will try it again next.

Well… I’m still almost certain I’ve tried this before, so I remain very suspicious… but it’s working fine on 5.6-RT.

I don’t think I’d consider this a solution because there’s no telling how long it’ll work for, or if I’ll ever be able to update or change kernels, but the immediate problem is solved, at least. I would humbly recommend that this thread not be marked as solved for these reasons.

Thank you Fabby for your suggestion which prompted me to try this, but as I say, I am almost certain I’ve tried it before, so I don’t know why it’s working now.

You can git checkout an earlier version of any kernel and compile it yourself and then run that until the bug gets resolved and then go again with the mainstream, but if you’ve never done any development, you’re going to run into a steep learning curve about software development and maintenance…

You can hold this kernel and regularly try out new ones until they fix the bug and then go mainstream again…


(I’ve only ever done this once on my previous OS because Canonical isn’t as good as Manjaro to update kernels, but I used to be a developer; a very long time ago; but still…)

Thanks, I am aware of the ability to hold packages, good to know I can do it with kernels too.

I’m now having trouble getting zfs working on 5.6-RT. I have a few more things to try before I start asking around these forums, though. I should start a new thread if I do, I suppose.

zfs is important for my setup but not completely essential short-term. I am therefore still a step up.

1 Like

if alsa-lib was not included in updates and has the same version number on both working and non-working OS, downgrading to a different version would not help
but I had an alsa-lib update in July
:: Different sync package(s) in repository extra x86_64

                             PACKAGE           2020-06-13           2020-07-19
                            alsa-lib              1.2.2-1  

I only suggested alsa-lib as a possible problem because I recall it being a source of audio problems
in the past

I can see the ALSA alias names for audio devices in
the Focusrite has a hardware alias ‘hw:USB’ which is equivalent to ‘hw:2’
but it may not always be assigned the same card number
if the two USB devices were detected in a different order it may be ‘hw:3’

I have seen comments on here that Manjaro adds some additional patches to their kernel builds
so I think this assumption is incorrect

1 Like

Hi, im having the exact same issue with a focusrite scarlett 20i8 and an msi7721. Tested on Kubuntu and Manjaro. I am going to try now with 5.6 RT. Did you find any permanent solution?

I didn’t find a permanent solution, and in fact now the temporary solution won’t even work properly.

The only kernel which works with the audio interface (5.6rt) has now been marked as ‘Unsupported’, and I find I can’t install any packages.

the 5.9rt kernel which replaces it still has the same bug when connecting the audio interface.

I have no choice but to hold back on 5.6rt and hope a fix comes in a later kernel release, and if I need to install any software I guess I’ll have to find a workaround.

Any suggestions? Am I going to have no choice but to replace either my audio interface, motherboard, or distro?

any updates? should we just change the mb?

I found this discussion which may help - Focusrite Scarlett 6i6 and 18i8 2nd Gen mixer driver - LinuxMusicians

Some of the comments state that the interface does not work using USB 2.0 driver ehci-hcd
device needs USB 3.0 driver xhci-hcd
so I suggest you check that in:

lsusb -t


sudo dmesg | grep usb
1 Like

don’t bother changing MB, I tested this on my laptop after a kernel update, and found the same problem there. I don’t think it’s motherboard related, though it might be something more specific than the motherboard itself.
I was thinking it might be the firmware version on the audio interface itself, since I remember there was an application on windows which allowed you to update the firmware, and I did use it once or twice, but I can’t find that application now, and am no longer on windows.

looks like mine is plugged in on xhci, yes. I’ve tried it in all different ports on many different kernels, the only reliable fix is using 5.6rt, as I still have to.

this problem is now present on endeavourOS (close to base arch kernel) and pop os (debian kernel), though the audio interface still works on a Windows PC. There must have been some change to how audio devices are handled across the entire linux kernel in the last few months (I first noticed it in about august last year).

I’m pretty much at the point that I’m going to buy a totally new audio interface from a different company, which is such a massive waste. Hopefully someone here has an idea for what to try before I replace it.

Just in case you have not tried it yet:

# /etc/modprobe.d/focusrite.conf
options snd_usb_audio vid=0x1235 pid=0x8205 device_setup=1

sadly, that had no effect. Tried it on 5.4LTS and the interface still booted into its half-initialised state where the mic doesn’t pick up.

The most evident difference between the two states is that when the hardware works properly, the fourth USB interface on the device (interface 1.3) loads with snd-usb-audio, whereas in newer kernels it doesn’t load with any driver. I’ve tried a few methods to force it to load that driver for that interface but none of them have worked. Is there something I can do with udev or kernel options? Thanks in advance for any ideas.