https://bugs.freedesktop.org/show_bug.cgi?id=106557
--- Comment #2 from Dmitrii Sutiagin <f3fli...@gmail.com> ---
Tanu, thank you for the recommendations.
While following the steps, the gdm masking part did not give intended result:
[dsutyagin@pulsar ~]$ sudo ps -ef | grep [p]ulse
gdm 779 722 0 11:22 ? 00:00:00 /usr/bin/pulseaudio
--daemonize=no
dsutyag+ 1018 905 0 11:22 ? 00:00:06 /usr/bin/pulseaudio
--daemonize=no
[dsutyagin@pulsar ~]$ sudo -u gdm bash
[gdm@pulsar dsutyagin]$ XDG_RUNTIME_DIR=/run/user/$UID systemctl --user --now
mask pulseaudio.service pulseaudio.socket
Created symlink /var/lib/gdm/.config/systemd/user/pulseaudio.service →
/dev/null.
Created symlink /var/lib/gdm/.config/systemd/user/pulseaudio.socket →
/dev/null.
[gdm@pulsar dsutyagin]$ exit
[dsutyagin@pulsar ~]$ systemctl --user --now mask pulseaudio.service
pulseaudio.socket
Created symlink /home/dsutyagin/.config/systemd/user/pulseaudio.service →
/dev/null.
Created symlink /home/dsutyagin/.config/systemd/user/pulseaudio.socket →
/dev/null.
[dsutyagin@pulsar ~]$ ps -ef | grep [p]ulse
gdm 2586 1 0 11:42 ? 00:00:00 /usr/bin/pulseaudio --start
--log-target=syslog
[dsutyagin@pulsar ~]$ sudo killall pulseaudio
[dsutyagin@pulsar ~]$ ps -ef | grep [p]ulse
gdm 2603 1 0 11:42 ? 00:00:00 /usr/bin/pulseaudio --start
--log-target=syslog
...So I used this trick:
[dsutyagin@pulsar ~]$ sudo chmod -x /usr/bin/pulseaudio
[dsutyagin@pulsar ~]$ sudo killall pulseaudio
[dsutyagin@pulsar ~]$ sudo chmod +x /usr/bin/pulseaudio
[dsutyagin@pulsar ~]$ ps -ef | grep [p]ulse
[dsutyagin@pulsar ~]$
Regarding the log... This is getting very interesting. The issue is not
consistent depending on how I reproduce it. I got at least 3 different
behaviors when testing with different combinations of pulseaudio running/not
running/ and debug foreground mode vs systemd mode:
1. it doesn't work as before, log example can be found here -
https://pastebin.com/4en37K3L # this is usually the result when I just plug in
the card while it's on (it's hardware switch)
2. it works, log example here - https://pastebin.com/0xQRWmNk # this I got when
1 pulseaudio running (with -vv) and I plugged in the card while it was "off"
(it has a hardware switch on it's front, integrated into volume knob) and then
turned the card on via the knob.
3. it glitches like hell, the card gets reset several times, then pause, then
again reset several times - I can hear clicks in headphones and kernel usb log
repeats each time as if I just plugged the card in. Log here (only journalctl,
failed to capture pulseaudio) - https://pastebin.com/Y5Ng2Fbs # This happened
with 2 pulseaudio running and using a knob to turn the card on.
To conclude, so far it looks like if I have 1 or 0 pulseaudio running and use
the knob, it usually works, all other scenarios usually lead to the issue in
it's now 2 different forms. I'll play a bit more with this and let know if I
find any specific behaviors. To me this looks like a race between pulseaudio
and kernel or system. Maybe related to systemd-udevd calling alsactl so early,
or upowerd notices about unhandled action... Both of these do happen even when
the card works, but maybe the timing between this and pulseaudio is important.
And with 2 pulseaudio the chances of success are less, which is also in
indicator of race.
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.
_______________________________________________
pulseaudio-bugs mailing list
pulseaudio-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-bugs