I'm using PipeWire (on defaults) and am getting a 3-5 second delay when starting a video or playing music which goes away when I turn off `suspend-node` in PipeWire's media-session.conf config file. Was going to file the bug with them but have been informed it is a driver bug with snd_hda_intel and I think this is the right place to file it? Would be happy to just comment out suspend-node but have been told that it won't suspend video and would leave them open, which they tell me is a bad thing if there is a camera attached to the system. This is over HDMI using Codec: ATI R6xx HDMI. http://alsa-project.org/db/?f=dc828e520e1f91db8c7efbf3786802ccfdc3336f. I'm not sure what other information you require so let me know and I'll try to post it immediately in the hopes of getting this fixed quickly.
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.