Audio weirdness

[Andrew]

According to my Asus A320M-K MoBo description, I have a "Realtek ALC
887-VD2 High Definition Audio CODEC" on board.
I have run OpenSUSE Leap on this PC since I bought the machine back in
2018, there were never any problems with it until I upgraded to the
newest level (15.4) a few days ago.
The kernel module currently being used is snd_hda_intel which seemed
strange to me but appears to be correct.

The symptoms are:
- no sound at all from the speakers (which are plugged into the back).
- if I plug headphones in to the appropriate socket on the front panel,
Let There be Sound!, and the sound was good.
- now I pull the headphone cable again, the speakers then work as they
should.

I see that there are several posts from people trying to get this audio
device to work and most of them don't get as far as I have.

According to "pacmd list-sinks" it knows it is using Line Out rather
than Headphones.
There is a second sound card for HDMI / DisplayPort but that is
SUSPENDED because it is IDLE and I'm good with that.

Am I missing something obvious?
tia

[David W. Hodgins]

Check the configuration in pavucontrol (run as the user). In my case I have
to have hdmi off, and built in audio set to analog stereo output.

Regards, Dave Hodgins

[Andrew]

Thanks for the reply, it gave me some ideas on how to do some more testing.

The back of the PC is rather inaccessible, but pulling the loudspeaker
cable half-out and in again also gets things working. I have to be
playing content at the time, otherwise it does not help.

pavucontrol makes no difference. I performed the following operations:
- configured it while all was running, turning the HDMI/DP device Off
and locking that config. The other device was showing "Analog Stereo
Duplex".
- terminate pavucontrol
- reboot
- try playing content, nothing.
- restart pavucontrol, nothing.
- "pull and push" the line-out cable - that fixes things only if content
is playing.

I think my next step is going to have to be a "modprobe snd_hda_intel",
(after checking if it is already running) - one reboot coming up.

--
This mail has been tested by https://RKIvirus.com/ and has been found to
contain Covid-19. Disinfect after reading.

[Andrew]

Well, not what I was expecting at all.
1. "lsmod" after a boot showed various modules, including snd-hda-intel.
2. "lsmod" while music was (not) being played showed additional modules.
3. "lsmod" once the workaround (cable) had been applied and with music
playing, the modules loaded were identical to case 2.

I have tried two different "content" sources - Firefox and Dragon
Player. The behaviour is identical.

[David W. Hodgins]

On Fri, 17 Jun 2022 06:27:36 -0400, Andrew <Do...@hyperspace.vogon.gov> wrote:
> Well, not what I was expecting at all.
> 1. "lsmod" after a boot showed various modules, including snd-hda-intel.
> 2. "lsmod" while music was (not) being played showed additional modules.
> 3. "lsmod" once the workaround (cable) had been applied and with music
> playing, the modules loaded were identical to case 2.
>
> I have tried two different "content" sources - Firefox and Dragon
> Player. The behaviour is identical.

I'd try (as root) in a termainl, start "udevadm monitor", unplug/replug the
speaker cable, ctrl+c to kill the udevadm monitor.

Then see if there are any udev rules being triggered by that. If there are
you may be able to find a way to force them when you boot.

I suggest doing as little as possible while udevadm is running to keep the
noise in it's output to a minimum. Just the unplug/replug. It produces output
for every mouse movement and keyboard press and release.

Regards, Dave Hodgins

[Andrew]

No events, none at all. All I saw was

monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent

^C

My guess is that Pulseaudio is misbehaving, but it could just as easily
be the victim here.
Three messages I saw in the log after the upgrade were:

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.

I saw nothing of the kind in a log from before the upgrade.

[David W. Hodgins]

On Sat, 18 Jun 2022 02:12:48 -0400, Andrew <Do...@hyperspace.vogon.gov> wrote:
> No events, none at all. All I saw was
>
> monitor will print the received events for:
> UDEV - the event which udev sends out after rule processing
> KERNEL - the kernel uevent
>
> ^C
>
> My guess is that Pulseaudio is misbehaving, but it could just as easily
> be the victim here.
> Three messages I saw in the log after the upgrade were:
>
> 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.
>
> I saw nothing of the kind in a log from before the upgrade.

If it's a hard wired speaker, not a bluetooth connection, then bluez has
nothing to do with the speaker.

If you're not using bluetooth for any audio output, see
https://forum.manjaro.org/t/journalctl-pulseaudio-error-after-latest-update/38771/5
to stop it from looking for bluetooth headphones or earplugs.

I doubt that will change anything with the wired speakers, but it might if it's
the delay caused by searching for non-existent bluetooth speakers that's causing
the problem.

Regards, Dave Hodgins

[Andrew]

This is going to have to wait - I'm going to be away for a week or so,
then I'll have time for another go at the problem.
Thanks

[Andrew]

Ok, I've back for over a week now and have been experimenting as and
when time permitted.
- Having the headphones plugged in while booting, and then pulling them
(while content was being played) was sufficient to get the speakers
going. This suggests that the speakers would work if plugged into the
front, I'll have to check that.
- Logging the session out and then logging in again - rather than
booting - behaves the same way as booting. This is a real surprise and
I'm going to have to create a second user to see if there is something
wrong with my user settings.

Actually, both of those effects surprised me.
Oh, and I did not deactivate Bluetooth.

[Andrew]

It was a setting in KDE and I don't know if the solution makes any sense
outside the OpenSUSE environment.

System Settings -> Hardware -> Audio -> Profile was set to "Analog
Stereo Duplex", changing it to "Analog Stereo Output" fixed the problem.

It had worked with "Analog Stereo Duplex" under the previous level.