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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 15 Jun 2022 06:24:55 -0400, Andrew <Doug@hyperspace.vogon.gov> wrote:

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?

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

David W. Hodgins wrote:

On Wed, 15 Jun 2022 06:24:55 -0400, Andrew <Doug@hyperspace.vogon.gov>
wrote:

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?

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

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Andrew wrote:

David W. Hodgins wrote:

On Wed, 15 Jun 2022 06:24:55 -0400, Andrew
<Doug@hyperspace.vogon.gov> wrote:

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?

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

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.

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 17 Jun 2022 06:27:36 -0400, Andrew <Doug@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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

David W. Hodgins wrote:

On Fri, 17 Jun 2022 06:27:36 -0400, Andrew <Doug@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

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 18 Jun 2022 02:12:48 -0400, Andrew <Doug@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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

David W. Hodgins wrote:

On Sat, 18 Jun 2022 02:12:48 -0400, Andrew <Doug@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

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

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

David W. Hodgins wrote:

On Sat, 18 Jun 2022 02:12:48 -0400, Andrew <Doug@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

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

David W. Hodgins wrote:

On Sat, 18 Jun 2022 02:12:48 -0400, Andrew <Doug@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

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)