With the same USB expansion card as you’d been using for a while on other mainboards?
If it was doing slight damage to circuit protection components in both the card, and also the computer, then that would explain why switching the card didn’t help before, and why switching the computer doesn’t help now.
(Also, if now that it’s started, it happens for you more frequently than once every 5 days that would be a small but significant corroboration for the circuit-damage theory.)
I’m not saying you are wrong (and in particular Fedora 42 working consistently on my computer now, or for someone else in the past, would be a pretty strong counter argument). Just saying that to me, switching either the computer or the headphone expansion card but not both at once might not fix the problem under my theory, necessarily.
Just a data point here - I keep the headphone jack plugged in 24/7 (into an old boombox), and I get this problem randomly about once every week or two.
Yes. But as mentioned, that was the first thing that was replaced, yet it had no effect whatsoever.
But if I’m not mistaken I also used another DAC on one of my USB C modules and got the same result eventually, which would completely defeat this argument. But again, if so, it’s most likely documented in this massive thread. Just that U haven’t found a good way yet to make it easily searchable.
Yes. But as mentioned, that was the first thing that was replaced, yet it had no effect whatsoever.
Yeah, I got that part. As mentioned, that’s not inconsistent with my theory. Switching either the headphone module or the mainboard, but not both, could continue the same problem.
But if I’m not mistaken I also used another DAC on one of my USB C modules and got the same result eventually, which would completely defeat this argument. But again, if so, it’s most likely documented in this massive thread. Just that U haven’t found a good way yet to make it easily searchable.
Fair enough. At some point I’ll go back and read the whole thread and see what all was already sorted out about it.
Okay, I at least skimmed the whole thread. I’m now a lot more confident in the plausibility of my damage-to-the-circuitry idea.
The whole thing with F42 seems to come from just one test for a few weeks… which doesn’t line up to me; this is just an intermittent problem. It could have just been a couple weeks of luck. Or, Fedora could have some kind of power-management setup that makes it less likely to happen to surface, without actually fixing the underlying root. A couple of weeks of singular stability doesn’t prove it doesn’t happen. And two separate people (I think including yourself) reported having the problem on F42; you said that replugging the card fixed it, but I’ve also seen that happen sometimes with manifestations of this same problem on my system randomly sometimes. Sometimes (mostly) it wedges the audio or USB systems when it happens, but sometimes it doesn’t. I’m also struck by how many people are reporting that it happened all of a sudden (sometimes correlated in their minds with a particular upgrade, but also sometimes not), but then stuck around once it started happening. It’s reasonable to connect that to a software change, but I don’t think looking at the totality of their experiences that it was connected to those specific software changes for every person.
I think this is just a hardware problem. I could be wrong, but I think I am going to write up my thoughts about it in the firmware tracker, and hopefully at some point the engineers there can weigh in on it.
This also means I really don’t want to be manifesting this problem on my system for the sake of testing anything. I would actually be happy to run the other side of the test – grounding the headphone cord first, running in a carefully no-stray-potentials environment, and seeing if it still happens there. If it does not, then I would consider that moderately strong corroboration for my theory.
(Of course I could still be wrong, not an EE, etc etc. These are just my semi-informed theories about it.)
Another thing to consider is that analog out is really low voltage compared to USB data lines. 2 volts at most, usually less. Even if it were backfeeding into the bus, which it shouldn’t without any headphones or speaker also getting 5 volts the other way and getting damaged, it may not even be enough to get past the gate voltage on whatever chip is the USB provider
Yeah. In my scenario the whole damage comes from that pop of potential equalization when you first plug in the headphones. I agree; I can’t concoct any scenario where just driving the headphones doing normal audio could cause an issue, which is why I’m comfortable testing things out with the computer always plugged in and the headphone cable always shorted to ground before plugging it in.
(Well, earth ground could maybe be a little different from USB signal ground… but probably it’s a small difference if any. It’s fine. I still think it’s likely to be safe and worth testing.)
Like I say, I could be wrong. I’ll test with the headphones that way and report if I still see the issue; if nothing else it’s nice to rule out hypotheses.
Today I’ve been running with just Bluetooth audio, no headphone expansion card even connected, and twice today I did a suspend-and-resume with music playing but paused, and twice when I resumed and tried to restart the thing that was playing music (one was ffplay, one was a browser tab with a paused video), it continued in total silence (on all possible sinks). One time pipewire was refusing to interact with anything from userspace (pavucontrol was hung and etc) until I jogged it back into activity by seeking within the YouTube video in the browser tab, then everything came back to life.
I think this is a much simpler and more straightforward bug, specific to suspend-and-resume maybe, and unrelated to all this that we’re talking about with USB audio devices sometimes disappearing from the bus entirely. I still think this thread is about a much deeper issue than just pipewire being weird. But full transparency requires me to say something about it, rather than pretend that now that I’ve removed the headphone jack expansion, everything in my audio is working like it normally is supposed to.
One more bit of transparency: During my skim I saw people talking about a whole system crash during videoconferencing. I have that too. It sure isn’t convenient, let me tell you. I haven’t tried for a while (I generally have been just doing videoconferencing from my Mac when it comes up), so I can’t say whether it’s still going on, but the crash within about 10-15 minutes of starting video chat was 100% consistent back when I was trying to do it, and it might be relevant that me and whoever both have USB headphone issues and also both have videoconference crash issues.
And, long long ago when I first got this machine, I actually happened to do some videoconferences and they all went fine. The videoconference crash actually appeared after maybe 6 months? and I think a good bit before the headphone troubles.
Again, both have been switched by now. The mainboard twice. I think the chance that your theory can realistically explain this isn’t too big. And as already mentioned, if I’m not mistaken it also happens when you just don’t use the headphone module. And one would have to check if it even has to be wired audio or if BT/speaker audio alone would also eventually have an issue. And to be honest, if the audio jack itself would be that big of an issue, I’d expect many more people to be affected, both on other FW laptops and other devices.
But so far my best guess would be some issue with the audio processing or transport. What’s rather unique with FW laptops and (thankfully) not too common in other devices is that all wired audio goes through USB alt-mode. The only two ways to circumvent that is via BT and speakers. Probably no other laptop has a USB layout as complex as this, so there might be an issue with how the USB hubs interact with each other or with the SoC. We don’t even have an Intel-based alternative to check if that would also be affected. I can’t tell if any FW 13 or 12 models ever showed similar issues, but after all they might just have a simpler USB layout. But after a quick look through some search results I don’t really see any other reports on any other model.
Nah, that’s where you’re missed something. I tested it for like 1.5-2 weeks, a time frame where it would have simply been impossible for this not to appear, as it’s actually quite reliable on the 5-8 day cycle - if you use it daily. And at least one other person confirmed the findings. That’s also the person that found that the kernel that would ship with F43 was no longer preventing it. This is no coincidence.
Nobody ever said anything about a fix, but it’s a fact that it simply doesn’t happen on F42. And as soon as you boot anything else it happens almost immediately. Sorry, but that is impossible to be a coincidence.
And what kernel were they running? We made it quite clear which work and which don’t. And I don’t think that Fedora is as conservative with keeping the main kernel version the same over the entire life cycle of a distro version and only shipping bug fix updates.
Nope, I never did. In very few occasions a soft-reboot follow by replugging was able to fix things, but that’s it. It has never worked without the soft-reboot.
It’s basically guaranteed to be, but that’s it. I seriously doubt that the headphone jack itself can be causing it, it’s just not possible that it would never show up on any other device. And the FW13 has been around for so much longer, if that was the cause, it would have been affected long ago.
Well, that does rule out all the stuff between the SoC and the USB ports, so the issue is somewhere between the SoC, its firmware and the BIOS, as I kinda doubt the WiFi/BT-chip is to blame.
I’d think that’s only a symptom of what happens when this issue appears as I don’t remember actual full crashes.
What I’ve seen is that when you try to play back a video - no matter through what software - it just doesn’t start to play because the audio subsystem just threw errors. In some cases they are ignored and just the audio plays, but most of the time all video playback becomes impossible because the video always comes with audio and the software was never programmed to handle the case that audio just randomly stops working.
That’s interesting, but it’s not impossible that in some way the headphone issues appeared but in some way you didn’t yet notice. This would bring back the idea that some software component is involved in all of this and you only started noticing because of some software change no longer caused errors being thrown that only caused your video conferences too crash. I guess back when that happened you didn’t get the idea to try to play any audio back when your video conference crashed? So it might be the case that those very crashed where your first experiences with the audio issue, you just didn’t realize.
Hi guys, I have a Framework 16 Ryzen AI 300 series (HX 370) here, and as I bought every expansion card for “just in case” purposes I also happen to have a audio expansion card.
Running a system based on Gentoo, and currently running kernel 6.18.41 (with Gentoo and Fedora patchsets).
If you want I can take a (quick) look at what happens on a Ryzen AI 300 system, as I am a bit bored at the moment because the RX7700 GPU in my Expansion Bay died last week and Support is still in the process of clearing a replacement.
Actually that could be pretty good, especially if it doesn’t exhibit the issue. I don’t think we have dmesg logs and whatnot of a normal looking system to compare to, since the thread kind of self-selects against that by virtue of existing
Have you ever had the headphone jack malfunction on you in this way? It seems it affects some people but not everyone, so I’m not sure whether your testing of things would necessarily be useful… if you want, I think the first thing would be just to try headphone audio with your existing setup and see if it crashes in the same way it does for us, and then once it’s verified I do have some things I would be curious for you to try to see if they resolve it.
And as soon as you boot anything else it happens almost immediately.
That’s not my experience. Sometimes it takes quite a while to show up, but it never completely goes away, is my experience. Although yes it sometimes does happen to show up almost instantly. Not always though. I know you said you’ve already done it for 1.5 weeks and only had the one issue with it. To me that’s not bulletproof yet. Sorry. And then doing a bunch more testing after that of slightly different configs (all of which showed the crash) and saying that confirms that the 6.14.11 Fedora kernel in Fedora config is definitely the key piece, that doesn’t seem proven to me.
At the end of the day I’m not trying to go back and forth with you on it endlessly though. Like I say, you could be 100% right. The bottom line is some of this stuff is easy to just test. We already have confirmation that it happens on F42 + a more recent than 6.14 kernel (from John_Obscurant), so the next obvious thing would be to have more people try the F42 6.14.11 vendor kernel (I would recommend just using the vendor bzImage blob + modules + firmware on their existing system) for longer. If a few people do that for a week, or one person for a month or something, and it doesn’t crash, then that to me would be pretty rock-solid yes. I can actually do that at some point. If that doesn’t show the crash with more testing, then I can spend a pretty solid amount of time digging into what is the difference with that kernel compared to the ones right adjacent to it that are crashing. Or, we can just report that pretty exact finding to FW engineers and give them a chance to be the ones to figure it out if they want.
What I’m currently doing is alternating between:
Headphone jack audio, with the headphone jack touched to ground first, and me on an anti-static wrist strap
Bluetooth audio with no suspend and resume involved
My speculation is that neither of those will show the crash. But let’s see. In particular, these problems with my Bluetooth audio might throw a whole new wrinkle into this from my POV for looking for issues with it. But I’m inclined just to test stuff and find out.
Oh, and the videoconference crash is just a whole system hard freeze. Not like these outcomes where the audio system freezes and nothing else. It’s also a lot more consistent. I’m not even sure it’s related; I only brought it up because someone else with the exact same audio troubles mentioned the same thing.
Actually, one question right away – do you ever get these types of messages in your kernel log?
reset full-speed USB device number 8 using xhci_hcd
If so roughly how often? I get them from 1 time per hour all the way up to roughly 6 times per hour, and there’s a theory that they are correlated with some of the breakage.