Bug 212251
Summary: | PipeWire snd_hda_intel suspend-node Causing 3-5 Second Delay | ||
---|---|---|---|
Product: | Drivers | Reporter: | Jason (jaskerx) |
Component: | Sound(ALSA) | Assignee: | Jaroslav Kysela (perex) |
Status: | RESOLVED WILL_NOT_FIX | ||
Severity: | normal | CC: | tiwai |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 5.10.21-200.fc33.x86_64 | Subsystem: | |
Regression: | No | Bisected commit-id: |
Description
Jason
2021-03-12 14:30:38 UTC
It's not clear what you mean as "delay". It's pretty normal that a media receiver needs some seconds to re-sync the signal once when it turned off. And, if you do the runtime-suspend for power-saving, of course the signal gets off. Or, if you mean that the kernel driver really takes for 3-5 seconds to resume the device, then it's a kernel problem and we need to take a deeper look. Other than that, it's rather a usage problem. I mean there is a delay from the time I hit play to the time I hear sound which is any where from 3 to 5 seconds. If I disable suspend-node there is no delay and upon hitting play I immediately hear sound. Again, we need to know what takes so long. This should begin with the analysis in the user-space side. IOW, if you can show that it's a kernel driver that gets stuck for long time, we can start taking a deeper look at it. Without that proof and any details what's going on, it's practically impossible to start debugging anything in kernel side. That said, you should try profiling the pipewire operation at first, and it's better done by pipewire people. Or, if you experience the same problem on other sound backend (PA or ALSA-native), it'd be likely easier to analyze, of course. Sorry to bother you with this, after debugging Pipewire we discovered that it has nothing to do with snd_hda_intel. Problem has now been fixed. This can be closed. Thank you. |