This issue was originally discussed in a thread on the Gentoo forums: https://forums.gentoo.org/viewtopic-p-8120616.html What happens is that the audio now and then pauses before it comes back. Usually it's gone for a few seconds but some times more than that. I have two speakers connected using a TOSLINK connector on the motherboard. If an analog source is connected at the same time audio will switch over to that one instead. When this occurs the pavucontrol interface shows the message "Establishing connection to Pulseaudio. Please wait...". The problem seems specific to Pulseaudio, this does not happen when the Audacious alsa plugin is used for instance. I have created two logs running pulseaudio -k && pulseaudio --log-level=4 --log-target=file:pulse.log --start. Here's a log of the startup of Pulseaudio: https://pastebin.com/Mu4mT0z8 Here's a log of the error occurring: https://pastebin.com/kHykvjyp The problem occurs on Pulseaudio v10.0, v10.99.1 and v11.0, all installed using Gentoo's package manager portage. As others suggested in the thread I have tried setting tsched=0' in /etc/pulse/default.pa and disabled module-suspend-on-idle without any improvement. We are at least a handful of Gentoo users who have experienced this so it seems as if it's not specific to a hardware error on my computer.
Hello, it sounds as if PA is crashing and then restarted automatically. However I can't find the crash in the logs you attached. Can you try with --log-target=newfile:pulse.log? This should generate a new file every time pulse is restarted. Can you then attach the log which contains the crash?
Only one log file, pulse.log, was generated: https://pastebin.com/BCJJWdZn I think the following line is generated every time the sound stops and comes back: D: [pulseaudio] sink-input.c: The volume of sink input 0 changed from front-left: ...
Can you describe what you did and what exactly happened during the session you logged? Did you plug/unplug a headphone? What I see from the log is that you start playing to alsa_output.pci-0000_00_1b.0.iec958-stereo, then 'Front Headphone Jack' is plugged in and module switch-on-port-available switches to alsa_output.pci-0000_00_1b.0.analog-stereo, then the jack is unplugged again and it switches back to the digital output.
I unplugged the 3.5 mm jack so that only the TOSLINK connector was used, killed pulseaudio, started it again with the log flag, played a song and shutdown pulseaudio. I did not connect or disconnect anything physically in the meantime and the audio went silent for less than a second maybe 5-6 times.
Can you disable module-switch-on-port-available and see if it still happens? During your playback, PA thinks that the headphone jack is plugged/unplugged several times. Without switch-on-port-available, PA should not try to switch to the new port, so playback should work uninterrupted. The next step then is to figure out, why PA thinks that the jack is permanently plugged/unplugged.
Oh wow, thanks! That seems to solve it! But then there's of course the question of why it happens in the first place. I created a log of this as well if it's of interest: https://pastebin.com/VH0Y7KGF The 'volume of sink input 0 changed from front-left ...' does not appear anymore.
I just wanted to post here and say, I also am a gentoo user experiencing this. The work around fixed the problem for me as well. Also I had a similar problem with a USB microphone that this also fixed.
If the headphones appear to be changing between plugged/unplugged without the user doing anything, I believe that's most likely a hardware defect. Workarounds include removing module-switch-on-port-available from the configuration as suggested before or removing the relevant [Jack ...] sections from /usr/share/pulseaudio/alsa-mixer/paths/*.conf. It would be nice to be able to tell PulseAudio to ignore specific jacks that are known to be flaky. I don't know if anyone's going to work on that, though.
Wouldn't the exact same behavior be expected when the Alsa plugin is used if it's a hardware defect. Even if that's the case, Alsa and Pulseaudio at least seem to handle it in different ways. Anyway, I'm super thankful for the workaround! This thing has been driving me crazy lately. Thank you! :)
Yes, i'd re-iterate what Henrik Johansson said. It works fine with the alsa drivers, also it works fine on windows. Literally the only problem I've had with it was with PA. That doesn't really mean it's not a hardware problem, it may well be an errata that alsa handles and windows handles and PA doesn't handle. But any way you look at it it's definitely a problem with PA.
I have to admit and please don't take this the wrong way, I only intend it as constructive critisizm, it is really frustrating when PA exhibits flawed behavior and then the first thing you guys do is blame hardware. Especially when that's really hard to blame when multiple people are experiencing it on totally different hardware with totally different chipsets.
I'm not intending to spam this thread and I apologize for this, but this is your first post in this thread and your first conclusion was to pass the buck and then suggest that nothing would be done about it. When clearly it's hard to blame hardware faults when multiple people are experiencing this with -different- hardware. Take this as constructive critisizm. (In reply to Tanu Kaskinen from comment #8) > If the headphones appear to be changing between plugged/unplugged without > the user doing anything, I believe that's most likely a hardware defect. > > Workarounds include removing module-switch-on-port-available from the > configuration as suggested before or removing the relevant [Jack ...] > sections from /usr/share/pulseaudio/alsa-mixer/paths/*.conf. > > It would be nice to be able to tell PulseAudio to ignore specific jacks that > are known to be flaky. I don't know if anyone's going to work on that, > though.
I guess there is an easy test, if the issue is really on PA level. Try to run something like "while true; do amixer -c0 cget iface=CARD,name='Front Headphone Jack'; sleep 1; done" (Interrupt with Contol-C) You have to replace -c0 with the correct number of your card. If you see that the jack is (randomly) changing between on and off, then it is definitely not a PA issue, but on the alsa or hardware level. Remember that alsa does not do any automatic switching to available ports, so the bug is not exposed with alsa (similar to when you remove module-switch-on-port-available).
If I'm understanding correct, you're saying that since alsa doesn't have the feature of automatically switching ports it isn't capable of triggering this behavior. Even if it is a hardware flaw it won't be possible to see it with just alsa. That's the best explanation I've heard yet as why it exhibits in PA but not alsa. I'm going to try your experiment and I'll post back here when I am done.
Just wanted to post an update. I had to re-install the operating system for a completely unrelated reason, and now I'm unable to duplicate the same original behaviour. I don't think running that script will result in any useful output now, at least not for me due to my inability to comprehend the problem and therefore inability to duplicate it again. Sorry fella's I'm not able to help now. Originally I had been using xfce4, but now since I re-installed I've been using KDE plasma. I doubt the GUI has any effect on this, but I just dont know for sure. Anyway it's working fine for me now.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/265.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.