OpenSUSE 15.4 Audio Problem

[Andrew]

(I have posted most of this in a similar form to comp.os.linux.hardware)

My PC has been active since 2018, whatever OpenSUSE Leap level was
current then was installed, all of the versions since then were loaded
in turn. I had to reinstall Leap 15.3 from scratch once but that was
for a totally different reason. Audio has never been a problem, now it is.

Audio no longer works after a boot. The workaround is to insert the
headphone plug and to remove it again *while content is being played*.
Pulling and reinserting the loudspeaker plug into the line-out socket
works in exactly the same way.

According to my Asus A320M-K MoBo description, I have a "Realtek
ALC 887-VD2 High Definition Audio CODEC" on board. The sound module is
snd_hda_intel.
When I start playing content, the correct modules are duly loaded. No
additional modules are loaded once I have applied the workaround.

There are various pulseaudio messages in the system logs but I don't
know which of those can be considered normal and which indicate a problem.
Noticeable in the log of a 15.3 startup was a "Stopping User Manager for
UID 465..." (appears to be user "sddm", the SDDM daemon). This did not
appear in the 15.4 log.

Something which did appear in the 15.4 log but not in the earlier one was:
dbus-daemon[839]: [system] Failed to activate service 'org.bluez': timed
out (service_start_timeout=25000ms)
kded5[9493]: kf.bluezqt: PendingCall Error: "Failed to activate service
'org.bluez': timed out (service_start_timeout=25000ms)"
pulseaudio[10257]: GetManagedObjects() failed:
org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible
causes include: the remote application did not send a reply, the message
bus security policy blocked the reply, the reply timeout expired, or the
network connection was broken.
PackageKit: daemon quit

Does anyone have a clue what is going on here, or how to debug this s***?

[Andrew]

To summarise:
- If I boot my system, sound does not work (cable to speakers at the
rear) until I insert the headphone cable, and withdraw it again.
- If I log out and log in again, sound does not work . . .
- If I put the machine to Sleep and wake it up again, no problems.

Now the fun one, I created a new User and logged into that userid after
a boot. Sound works.

Something went wrong with my main user account when I upgraded from Leap
15.3 to 15.4.
This is a pretty much vanilla kde setup.

Which settings do I need to nuke in order to simulate having a new
user-account? If this means deleting config files, no problem.

[JJarcor]

Am 28.07.22 um 14:13 schrieb Andrew:

Well, my approach to solve this would be to make a backup of the _main
user_ home path, best using tar to preserve all meta data and personell
settings.
As second step I suggest to copy the home path of your second and
working user to use it as the main users. Then reboot and look what
happens.
May be to copy only the /home/second_user/.config - path into the path
of the main user may help as well.
___

Regards
JJenssen

[Jeffrey H. Coffield]

On 7/28/22 05:13, Andrew wrote:
> To summarise:
> - If I boot my system, sound does not work (cable to speakers at the
> rear) until I insert the headphone cable, and withdraw it again.
> - If I log out and log in again, sound does not work . . .
> - If I put the machine to Sleep and wake it up again, no problems.
>
> Now the fun one, I created a new User and logged into that userid after
> a boot.  Sound works.
>
> Something went wrong with my main user account when I upgraded from Leap
> 15.3 to 15.4.
> This is a pretty much vanilla kde setup.
>
> Which settings do I need to nuke in order to simulate having a new
> user-account?  If this means deleting config files, no problem.

Try running kdiff3 comparing the .kde folder in your account with the
one that works.

Jeff Coffield

[Andrew]

I don't *have* a .kde folder. There's a .kde4 but there's not much of
interest there - in either account. The key folder appears to be
.config and I have already pruned a bit without breaking or fixing anything.

[Andrew]

I'm considering something along the lines of "mv .config .config.bad"
but that is a bit of a last resort. The .config of the working account
has very little in there, the account is only there so I can test stuff
like this.

[Jeffrey H. Coffield]

You're right. I guess kde moved things somewhere after 13.1. I'm now on
15.4 and things are in .config.

Jeff

[Carlos E.R.]

On 2022-06-17 19:38, Andrew wrote:
> (I have posted most of this in a similar form to comp.os.linux.hardware)
>
> My PC has been active since 2018, whatever OpenSUSE Leap level was
> current then was installed, all of the versions since then were loaded
> in turn.  I had to reinstall Leap 15.3 from scratch once but that was
> for a totally different reason.  Audio has never been a problem, now it is.
>
> Audio no longer works after a boot.  The workaround is to insert the
> headphone plug and to remove it again *while content is being played*.
> Pulling and reinserting the loudspeaker plug into the line-out socket
> works in exactly the same way.

I have a similar problem with a Mini PC from MSi. The sound should go
over the HDMI cable to the display, but it does not work till I insert
and remove the headphones on the box.

But I think that an update solved this at some point (the machine is
still on Leap 15.2).


I never investigated the issue.

--
Cheers, Carlos.

[Andrew]

What is your desktop environment? Mine is kde and the problem is in
there somewhere. I may have time to rebuild the configuration files in
$HOME/.config next week.
--
This mail has been tested by https://RKIvirus.com/ and has been found to
contain Covid-19. Disinfect after reading.

[JJenssen]

Am 17.06.22 um 19:38 schrieb Andrew:

> (I have posted most of this in a similar form to comp.os.linux.hardware)
>
> My PC has been active since 2018, whatever OpenSUSE Leap level was

...

> Something which did appear in the 15.4 log but not in the earlier one was:
> dbus-daemon[839]: [system] Failed to activate service 'org.bluez': timed
> out (service_start_timeout=25000ms)
> kded5[9493]: kf.bluezqt: PendingCall Error: "Failed to activate service
> 'org.bluez': timed out (service_start_timeout=25000ms)"
> pulseaudio[10257]: GetManagedObjects() failed:

^^^^^^^^^^^^^^^^^^^^^^^^^^

> org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible
> causes include: the remote application did not send a reply, the message
> bus security policy blocked the reply, the reply timeout expired, or the
> network connection was broken.
> PackageKit: daemon quit
>
> Does anyone have a clue what is going on here, or how to debug this s***?

I think the marked output is the reason. Did you ever try to restart
pulseaudio? For shure you did, didn't you?

On the other hand a quick look into my search-machine showed up this topic:
[SOLVED] LOGS: pulseaudio: GetManagedObjects() failed:
org.freedesktop.DBus.Error.TimedOut...'org.bluez'...
Post by sebastjava » Mon Nov 01, 2021 3:21 pm
at
https://forums.linuxmint.com/viewtopic.php?p=2089168&sid=14436b220c168610e8702f3fc6bd87ec#p2089168
Perhaps it is useful to you.

Third I remember sometime in the past (OSS13.?) I had to install
pavucontrol - PulseAudio Volume Control to switch output from PC-screen
to boxes. Because it is helpful for diffrent reasons I use to install
it nowadays...
Description:
PulseAudio Volume Control (pavucontrol) is a simple GTK based volume
control tool ("mixer") for the PulseAudio sound server. In contrast to
classic mixer tools this one allows you to control both the volume of
hardware devices and of each playback stream separately.

___

Regards
JJenssen

[Andrew]

While playing around with System Settings I found a fix.
Hardware -> Audio (obviously). Profile was "Analog Stereo Duplex" and I
changed it to "Analog Stereo Output". Today I booted and it worked as
it should.
- it worked with Analog Stereo Duplex under 15.3
- My second run-account on this system worked normally under 15.4.

I suppose I could change the setting back, log out, log into the other
account and check to see what the setting was there. My assumption was
that hardware settings were system-wide, although - given I am not asked
for the root password - this may well be wrong.

[Carlos E.R.]

XFCE.

--
Cheers, Carlos.

[Andrew]

Well, I found the cause (look at the posting with the word SOLVED in the
header) but I have no idea if it would work for you - especially because
you are unsure as to whether you still have the problem in the first place.
I have no idea how the XFCE environment behaves. If my fix works for
anyone else, so much the better.