Audio detected by pulseaudio control, but is not playing through speakers - Mint XFCE 22.2

[osprey]

It appears f-s-s is already installed
....

I have blacklisted snd_soc_avs by appending blacklist snd_sov_avs to /etc/modprobe.d/blacklist.conf, albeit this did not work. I have since unblacklistedit

Thanks for that. Can't see any issue with firmware then. Are the audio outputs in order? Check with the following command where I've snipped out some info since it's the "sinks" that are of interest. Note that the asterisk marks the current output "sink" on this machine with the volume level where 1.00 is 100%:

$ wpctl status
PipeWire 'pipewire-0' [1.4.9, ben@min, cookie:457850270]
 └─ Clients:
<snip>


Audio
 ├─ Devices:
 │      48. GK208 HDMI/DP Audio Controller      [alsa]
 │      49. Built-in Audio                      [alsa]
 │  
 ├─ Sinks:
 │  *   35. Built-in Audio Analog Stereo        [vol: 1.00]
 │      56. GK208 HDMI/DP Audio Controller Digital Stereo (HDMI) [vol: 0.40]
<snip>

 

[jerf]

wpctl status
PipeWire 'pipewire-0' [1.0.7, kylie@kylie-HP-Pavilion-All-in-One-Desktop-24-ca1xxx, cookie:3182124511]
 └─ Clients:
        32. pipewire                            [1.0.7, kylie@kylie-HP-Pavilion-All-in-One-Desktop-24-ca1xxx, pid:1118]
        34. WirePlumber                         [1.0.7, kylie@kylie-HP-Pavilion-All-in-One-Desktop-24-ca1xxx, pid:1119]
        35. WirePlumber [export]                [1.0.7, kylie@kylie-HP-Pavilion-All-in-One-Desktop-24-ca1xxx, pid:1119]
        51. xfce4-pulseaudio-plugin             [1.0.7, kylie@kylie-HP-Pavilion-All-in-One-Desktop-24-ca1xxx, pid:1517]
        56. Blueman                             [1.0.7, kylie@kylie-HP-Pavilion-All-in-One-Desktop-24-ca1xxx, pid:1543]
        57. xdg-desktop-portal                  [1.0.7, kylie@kylie-HP-Pavilion-All-in-One-Desktop-24-ca1xxx, pid:2115]
        58. wpctl                               [1.0.7, kylie@kylie-HP-Pavilion-All-in-One-Desktop-24-ca1xxx, pid:2615]

Audio
 ├─ Devices:
 │      46. Built-in Audio                      [alsa]
 │  
 ├─ Sinks:
 │  *   55. Built-in Audio Analogue Stereo      [vol: 1.00]
 │  
 ├─ Sink endpoints:
 │  
 ├─ Sources:
 │  
 ├─ Source endpoints:
 │  
 └─ Streams:

Video

<snip>

Settings
 └─ Default Configured Node Names:
         0. Audio/Sink    alsa_output.pci-0000_00_1f.3.analog-stereo

 

[osprey]

Audio
├─ Devices:
│ 46. Built-in Audio [alsa]
│
├─ Sinks:
│ * 55. Built-in Audio Analogue Stereo [vol: 1.00]
│

Thanks for that. Looks okay. Next check, is the user in the audio and pipewire groups? That can be checked with the following command:

$ groups
ben adm tty disk cdrom floppy sudo audio dip video plugdev users netdev bluetooth lpadmin scanner pipewire systemd-journal

The user ben is here in both audio and pipewire which are needed for that user to be able to use sound in his account.
This investigation is laborious, but hopefully something useful will eventuate.

If you are by chance not a member of those groups, add your user name as root to the relevant lines in the /etc/group file and log out and in, or reboot.

Perhaps I should have mentioned this earlier, but the linux mint installation being checked out needs to be cold booted each time, that is started from a new full power cycle. MS does odd things in dual boot if it's not shut down and shut out completely, so that variable needs to be taken out of the equation.

 

[jerf]

using

 groups

in the terminal, I saw that my user was not in groups pipewire or audio. I added my user to the lines containing those groups. After cold rebooting & running the command again, I saw that my user is in those groups now

groups
kylie adm cdrom sudo audio dip plugdev users lpadmin pipewire sambashare

Despite this, the problem hasn't gone away

I have also begun using soundcloud, youtube & an mp3 file to test for sound because it's probably better than just testing through one source

 

[osprey]

using

 groups

in the terminal, I saw that my user was not in groups pipewire or audio. I added my user to the lines containing those groups. After cold rebooting & running the command again, I saw that my user is in those groups now

groups
kylie adm cdrom sudo audio dip plugdev users lpadmin pipewire sambashare

Despite this, the problem hasn't gone away

I have also begun using soundcloud, youtube & an mp3 file to test for sound because it's probably better than just testing through one source

Some machines can reboot bypassing BIOS/UEFI initialisation of a device such as the sound device, and the kernel may be implicated. To check on this one can create the file:
/etc/default/kexec
with the contents:

LOAD_KEXEC=false

This has to be done as root with the file having the permissions as follows:

chmod 644 /etc/default/kexec

There's some info here: https://wiki.debian.org/ALSA.
It may or may not be relevant on your machine. If it makes no difference, it can be reversed with deletion.

It may be worth trying to re-initialise alsa to see if doing that after booting has an effect. To do that it's best to stop the sound server. The steps are outlined below.

Firstly see what's running with:

$ systemctl --user list-units | grep pipewire

  pipewire-pulse.service        loaded active running   PipeWire PulseAudio
  pipewire.service              loaded active running   PipeWire Multimedia Service
  pipewire-pulse.socket         loaded active running   PipeWire PulseAudio
  pipewire.socket               loaded active running   PipeWire Multimedia System Sockets


$ systemctl --user list-units | grep wireplumber
  wireplumber.service            loaded active running   Multimedia Service Session Manager

Then stop each one of the loaded units with a command such as:

$ systemctl --user stop pipewire.service
....

Then re-initialise alsa with the following command as root:

# alsactl init

Then restart pipewire and wireplumber as shown in post #13. Note especially when re-initialising alsa in the terminal whether or not an error message appears. This sound issue is a saga, but taking it a step a time hopefully gets somewhere in the end .

 

[jerf]

Thank you for your continued help with this

Created & written the line into the file, ran

 chmod 644 /etc/default/kexec

cold-rebooted;

when reinitialising alsa

Found hardware: "HDA-Intel" "Realtek ALC274" "HDA:10ec0274,103c8a6b,00100004 HDA:80862815,80860101,00100000" "0x103c" "0x89e9"
Hardware is initialized using a generic method

sadly to no avail

 

[osprey]

Thank you for your continued help with this

Created & written the line into the file, ran

 chmod 644 /etc/default/kexec

cold-rebooted;

when reinitialising alsa

Found hardware: "HDA-Intel" "Realtek ALC274" "HDA:10ec0274,103c8a6b,00100004 HDA:80862815,80860101,00100000" "0x103c" "0x89e9"
Hardware is initialized using a generic method

sadly to no avail

Thanks for the thanks. It's a doozy this one.

The sound driver in use is snd_hda_intel shown in post #15.

There are some options which can be applied to the driver.
By default the power saving function of the audio controller is set to on.
To turn power saving off, one is telling the kernel to keep the sound card and codec powered on all the time. It means that audio hardware won’t go into a low-power state, so it won't go powering down or waking up between sounds. In case this is a factor in this case, it can be checked.

To turn the power save function off just temporarily one can run the following as root:

echo 0 > /sys/module/snd_hda_intel/parameters/power_save
echo 0 > /sys/module/snd_hda_intel/parameters/power_save_controller

Once those configs have been changed, one can check sound. The effect of the change should be immediate. You can run any sound file to check, as you've suggested. The speaker-test command, being stopped after a couple of seconds with ctrl+c, is just a convenient option to use.

On reboot, the original configuration for power saving will return, so one doesn't need to return it. One can of course check the settings before making a change, but it's usually best to let the system reset the settings to the defaults since it's supposed to know better what it's doing.

 

[Condobloke]

Probably a bit late in the day to ask this....but....... Has Fastboot been turned off in bios ? .....or disabled in Windows?

To disable in Windows:

Turn On or Off Fast Startup in Windows 11

This tutorial will show you how to turn on or off fast startup in Windows 11. There are three startup modes in Windows: Cold (traditional) Wake-from-hibernation Fast Starting with Windows 8.x, the default shutdown and restart scenario has been updated and named fast startup. Fast startup...

www.elevenforum.com

 

[jerf]

Using

 (GP "HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Power")."HiberbootEnabled"

(as shown in linked website) in windows terminal returns 0 & the option is shown as off in the control panel, so fastboot is indeed disabled from windows. I wasn't able to find fast boot at all in my bios options though.

used

 sudo su

to bring up the root terminal then ran those commands, before knowing how to use root terminal I edited the files manually too, no dice for both times

 

[osprey]

@jerf , the main aim for sound is to have all the right elements in place, the drivers, the firmware and the controlling commands showing no errors. Basically, these elements seem to be in place in this situation as far as it's come to this point, but sound is still failing.

I may be at a significant disadvantage in that I'm unfamiliar with modern dual booting and the effect that MS can have on the machine which may affect a linux installation. I know for example that an MS installation in dual boot can capture the sound device which will interfere with linux's capacity to use it. In post #15 the result suggests that pipewire was controlling the devices, so I don't know that MS was interfering. In any case, this aspect with dual booting is a variable which I cannot factor in due to unfamiliarity.

The following observations may be of interest.

I came across this comment on a debian forum:

This looks like an old laptop (no insult, mine is just as old). Does it have a detachable battery? If so, do a normal shutdown, then remove the battery for a few minutes. Replace the battery and reboot. The reason for this is that sound cards can sometimes go into sleep mode and not wake up. It is possible that hibernate or a previous Windows shutdown has put the card into sleep mode, and the procedure will clear this.

here: https://forums.debian.net/viewtopic.php?p=832211#p832211

Another suggestion is for the installation, in debian, of the package: firmware-intel-sound, but the dmesg output from your post #20 did not indicate any missing sound firmware. There's no harm in installing it, but I can't say what the linux mint equivalent is, nor whether it would make any difference. I suspect not.

It may be worth trying to boot another live disk, other than linux mint, to see if that can produce sound. For example one might consider the live disks of debian, fedora, ubuntu, MX linux, minios. There are others. The site: distrowatch.com is a reference point for more.

The kernel driver in use on your machine is snd_hda_intel as shown in post #15. Blacklisting the snd_soc_avs and installing firmware-sof-signed made no difference, so presumably they aren't relevant and one is left with focus on just the single driver.

In post #27 there was a suggestion to see if turning off the power saving function made a difference. That result is yet to come.

From this point on of sound failure, one approach is to look into the parameters available for the sound driver snd_hda_intel and experiment with them. It's tedious time-consuming work and there's no promise of success. Perhaps say if you'd like to go down that rabbit hole.

 

[jerf]

I'll try a live session of another OS, but at this point I think I'm content with not having sound for now - the main reason I installed linux on this pc was to make the most out of 8GB & integrated graphics (thus no Vram) for some games like modded minecraft & a switch emulator. I'm likely going to try & get a handheld PC in the near future for this, which I can use for gaming instead

If I do find a fix for this I'll post it here in the event it does help someone

Thank you all for your help, I immensely appreciate the lengths this forum went for me & this experience has made me more comfortable with using forums more often

 

[Condobloke]

MX linux

MX Linux – Midweight Simple Stable Desktop OS

mxlinux.org

Well worth a try

Removing the battery and then reinserting is also a worthwhile move

 

[MzQ1NjExN2]

"I started using Fedora a few weeks ago. I have to say quite a nice distro. It seems to be a nice middle ground between Debian and Arch. You get stability and the latest stuff.

I upgraded from 41 to 42 no issues.

Also just wanted to mention that I bought a laptop that wasn't a well known name brand and it had some...lets say unique drivers. It worked out of the box with Fedora not so with the other distros I tried (all Debian based)."

The above is my post (#5) from the following thread:

Thread 'Fedora 42 Released'

Apr 15, 2025

Fedora Linux

An innovative platform for hardware, clouds, and containers, built with love by you.

fedoraproject.org

In all the usual places.

• dos2unix
• Replies: 11
• Forum: Fedora

• 

Also you can try MX AHS which looks like it uses a different kernel for better compatibility with newer machines:

Download Links – MX Linux

mxlinux.org