Yeah that may be separate. I’ve had the audio break during video calls before and it’s not caused a system freeze like described
After I finished up with my super conservative EasyEffects setup for the improved Pipewire pipeline for the ALC285/ALC1318 I have been working on in just a few minutes I’ll get the audio expansion card out of my backpack and slap it in one of the expansion slots
I’m starting to get kind of curious if us Ryzen AI 300 folks have the same problem as you Ryzen 7040 folks myself. Because if so, I will also have a problem when listening to wired lossless in the near future…
Just plugged it in, listening through it with the AKG in-ears which came with my Galaxy S8 at the time now.
So I just discovered a small problem people might be either aware or not aware about but the default hardware output gain in alsamixer is set a little bit too low for my taste for some reason.
And damn this thing can go loud when the gain is set just a little bit higher 
Anyhow, no issue regarding the card dropping off so far.
Sounds good. Yeah, it might take a week or two to show the problem sometimes in my experience. If it’s stable for a couple of weeks then probably it is stable.
It’s also pretty crucial to set the BIOS to enable Linux audio compatibility if you have not. IDK whether the volume weirdness is because of that, but I just know without it the sound quality is pretty bad.
@mindcrsh, @Robert_Christopher been there, done that, exact same issue. The most you can do is if Fedora 42 can prevent it for you as well. But I have no idea how well that version is supported by F42.
Yes, you definitely need to turn Linux audio compatibility on. But that’s just part of getting good audio in Linux.
Because somehow there are some undocumented issues which make audio sound bad in general on Linux with Framework gear. Which I am very much aware of because I’ve been busy fixing them (at least for my Framework 16).
And I think it is really sad aswell, because with a few tweaks Framework 16 audio sounds great in Linux (or at least as great as laptop audio can be…)
What I just wrote in the thread is just an example. I manually had to amp up the hardware audio on the audio expansion card to ~70% because the audio was just a little bit too soft and bassless for my taste at ~75% using my AKGs
And then there’s the mainboard audio to internal speakers pipeline on which I spent a good 4 hours fixing - eventually with a hack, because I did not really like to patch ALSA’s UCM configs which you need to do to tackle the root cause of the problem.
Because that’s what you have to do to get better (some say Windows like) results for the mainboard audio to internal speakers pipeline: you either have to patch ALSA’s UCM or as a quick hack inject ALSA’s softmixer to the audio controller in the Pipewire pipeline so that you will be able to control the gain on the ALC285 separately from the gain you set in Pipewire (and the desktop environment). When the gain on the ALC285 is set correctly there’s a much better, audible, volume curve from 50% to 100% when controlling speaker volume by default.
Which means there’s basically no need for a complex easyeffects pipeline to get better audio too, my current baseline DSP pipeline for the internal speakers consists solely out of a four band equalizer with some small tweaks and a limiter (just to be safe). No bass enhancement, convolver or anything like that required, the gain tweaked on the ALC285 already fixed the main problem people have (reasonably soft audio unless you crank up Pipewire volume all the way up to 100%).
Anyway, while writing this the audio expansion card still hasn’t dropped off the system bus so I think I’ll quit testing for today and probably take another test run tomorrow.
Maybe that’s the reason why I haven’t noticed anything yet. The standard Gentoo kernel (which l am running) is patched with patchsets created by Gentoo’s own kernel team and Fedora’s kernel team. Which means that if the fix is inside that patchset I have it too.
Honestly, I really couldn’t care less what you believe or not. This has been proven extensively in the past, like it or not. Instead of acting like a child you could have long repeated our experiments.
Yeah, that’s what you get from only skimming. I have probably written that, only by disproving myself a couple days later. But it has been proven extensively by multiple people on multiple occasions that it would not happen on F42 if you stick to the right kernel versions.
Only on installations with a too new kernel. All my tests where conducted on a F42 live USB, so only with the kernel version that shipped with it. It was laid out extensively, from which kernel version on the fix was no longer included.
Then what are you waiting for? Go ahead already and quit acting all childish. But I’d strongly recommend to instead go with what’s in the F42 ISO and not updating anything beyond that. That will give you a solid base for testing. Only after that has been verified you can start updating various parts until it stops working.
This has been reported at least by me a long time ago. It’s literally even in the very thread I created on their bug tracker, and I’ve reported those findings to the support thread months prior to that. There’s really not much if anything this would currently add to the discussion. The FW engineers had official and public knowledge of all of this for half a year, yet they still seem to be entirely ignoring it.
Might just have been amdgpu being a hot mess for many months though. From annoying flickers that seemingly had never been fixed for the 7040 platform (and even for the 300 series it came back with a fix only landing in kernel 7.2) all the way to random freezes of at least two causes, I had it all.
Because somehow there are some undocumented issues which make audio sound bad in general on Linux with Framework gear. Which I am very much aware of because I’ve been busy fixing them (at least for my Framework 16).
Makes sense, thank you for your service. I apparently have no taste at all in audio systems because a lot of laptop / phone audio that to me is perfectly serviceable, sounds like hot garbage to a lot of other people.
Also, as far as the built-in laptop microphone side, before I had the Bluetooth headset I got on a Zoom call along with my dad with my brand new Framework laptop (I think with no Linux compat mode enabled yet), and pretty much the first thing he said to me about it was that whoever sold me the machine I was on had ripped me off for it. 
He said he could barely understand me. IDK if the audio is better now with the BIOS fixed + firmware updates, like I said I don’t do video conference at all from this machine anymore.
(Fortunately I did in the meantime get the BT headset, which has fine audio, before the important interview two weeks after, which I did do from the FW machine, this being before it started crashing completely from video conferences.)
Yeah, me too. The video crashes actually came long after the amdgpu thing got fixed though.
Highly unlikely. As mentioned several times, F42 alone has been safe. And as I do not know what kernel versions made it tp F42, it might have gotten also the kernel version that removed the patch. I only know that what F43 bundled in its ISO didn’t carry the fix anymore. Also, as it’s unlikely that Fedora had removed that fix had they known that it’s actually a fix for an actual problem, I doubt they would have removed it. Instead it’s much more likely that it was an accidental fix as nobody seems to know what that fix even was. So the chances that it ever made its way into other kernels isn’t that big.
More or less. No idea if you ever had the flip_done (or something else with flip) issue, but over the past couple of weeks it actually showed its ugly head twice. But I fear the 7040 series seems to not have been any focus, as I was the only one in the bug tracker that reported it happening on a 7040 instead of a 300.
Like I said, could be one of their own patches or Fedora’s. I do know that they really care a lot about rock solid, stable and healthy kernel releases and that’s also why the 7.1 series is still in testing, and it probably will be for a few good months more. (latest stable is 6.18.41!)
Might also be the reason why I didn’t face any of the horror stories regarding the amdgpu module and other weird issues due to code mishaps until now… knocks on proverbial wood
But I am not in a hurry to get the latest and greatest anyway. I just want a good, stable, system.
I bought this machine in December 2025. I haven’t been tracking my software versions, but I run Debian Stable as my host OS. (I run all my actual applications in VirtualBox VMs, so I do very little in the host OS, but that is a story for another time.) I did update the firmware, which didn’t seem to make much difference for this problem.
But, here is another wrinkle… It seems to mainly happen shortly after a power up, but rarely after a reboot. I have no idea if this is real or just a subjective feeling, so take it with a grain of salt, but it might be worth some experimenting.
Interesting.
I also saw this… I am really curious about what would happen if you switched to a grounded audio accessory instead of the boom box (which I’m assuming is not grounded). The pattern of it starting less frequent, and then getting more and more frequent and correlated with other trouble with the computer, sounds exactly like what would be predicted by gradual damage to the laptop protection components over time. And, having it suddenly stop happening when the laptop isn’t plugged in would also make perfect sense if the source of the issue had to do with potential draining through from the (ungrounded) boom box and into the USB card continuously (and hence into the laptop and eventually to its ground) (which would stop as soon as the laptop wasn’t grounded and they could just equalize their potentials and chill there).
Honestly, I really couldn’t care less what you believe or not. This has been proven extensively in the past, like it or not. Instead of acting like a child you could have long repeated our experiments.
Then what are you waiting for? Go ahead already and quit acting all childish. But I’d strongly recommend to instead go with what’s in the F42 ISO and not updating anything beyond that. That will give you a solid base for testing. Only after that has been verified you can start updating various parts until it stops working.
Just for future reference this is an incredibly poor way of trying to interact about anything.
Testing the F42 kernel is probably next on my list if what I’m currently doing does turn out to show the failure, because sure, that makes sense.
The rest of this, I’m honestly just not interested in engaging with.
1 Like
That can only be true if anybody knew there was a patch for this and what it is. If there was, I’m very sure someone had already made it public and tried to upstream it. So you might simply not be affected for whatever reason, no matter what you where running.
At least on my system, one possible source of this is that if fwupd ever happens to do its refresh while audio is playing via the USB expansion card, it’ll scan through the USB devices to see what needs updating, and completely break the audio card’s piece of the kernel USB subsystem when it gets to the audio card.
I’m not sure if that’s the only issue (pipewire also has some hangs that it shouldn’t have, but that’s not really Framework’s problem), but it is certainly one issue. For me I can reproduce a version of this anytime by doing sudo fwupdmgr get-devices while the headphone jack is in use. I get messages like this:
Aug 12 13:39:23 redacted kernel: usbhid 1-2.2:1.2: can't add hid device: -110
Aug 12 13:39:23 redacted kernel: usbhid 1-2.2:1.2: probe with driver usbhid failed with error -110
Aug 12 13:39:23 redacted fwupd[9344]: 17:39:23.344 FuEngine failed to add device /sys/devices/pci0000:00/0000:00:08.1/0000:c1:00.3/usb1/1-2/1-2.2: failed to setup: failed to get firmware version info: failed to get GET_REPORT: failed to GetReport: USB error: Operation timed out [-7]
… and then the audio dies. It’s then possible to bring it back (for me) by shutting down fwupd, and then unplugging and replugging the card.
I’ve just disabled fwupd completely for now to see what other failures are here if any.
1 Like
One more piece of data for those investigating this topic more deeply: even though my audio dies when I plug my headphones into Framework’s 3.5mm audio expansion card, I doesn’t if I connect my Fiio BTR5 via USB-C and then connect the headphones to its 3.5mm jack.
1 Like