GPD Win Mini internal speakers are not working
Hello Bazzite discord,
as the title says the internal speakers of my GPD Win Mini are not working. I had this issue a while ago but could fix it myself by playing around with the sound but i cannot recall how.
In Gaming Mode sound does not work unless i plug my headphones in. Selecting the internal sound card doesn't change anything.
In Desktop Mode it's the same unless i go into the KDE settings and select the speakers (KDE says that they're not available). However that won't carry over into Gaming Mode and doesn't survive a reboot.
Another step i tried is to hook up my TV via a dock, switch to the HDMI output and then back to the internal speakers. Nothing changed.
Yet another step i tried is to run
rm -rf ~/.local/state/wireplumber/ followed by systemctl reboot. No change either. Running rm -rf ~/.local/state/wireplumber/ together with alsactl init fixes the audio temporarily but causes the internal speakers to play sound even if a headphone is connected. This fix also doesn't carry over to Gaming Mode and doesn't survive a reboot either.
I'm really at a loss here because i did manage to fix it once. I think it might have been with a GUI tool for ALSA. But i don't know and it really irks me.
Here's my output from rpm-ostree status:
Updating to Bazzite 42 doesn't work.Solution:Jump to solution
For future reference, here are the steps users can take if the automatic headphone detection fails:
Step 1: Make sure to clean out the headphone jack because lint can short the ground to another pin and make any device think that a headphone is connected.
@CheckYourFax recommends a can of compressed air. Should that not be enough, i recommend an interdental brush as it‘s small enough to get in there and does not risk leaving lint behind unlike the trimmed cotton swab i used....
27 Replies
Here's also the
amixer output:
Another addendum: I plugged headphones in and rebooted my Win Mini. Also i plugged my headphones in and disconnected them. Both didn‘t change anything.what does
wpctl status show?
When KDE doesn't see them as "plugged in"
might need to set up a custom wireplumber config to fix it, or disable suspend
it might also be helpful to check what wpctl status shows when you swap device in steam game mode.Pastebin
PipeWire 'pipewire-0' [1.2.7, julia@fedora, cookie:2844950621] └...
Pastebin.com is the number one paste tool since 2002. Pastebin is a website where you can store text online for a set period of time.
Here‘s the
wpctl status output in gaming mode. I couldn‘t pipe this into a text file because my keyboard is set to german on my Win Mini and thus i cannot use >
I believe that suspend is unrelated to this since audio worked mostly well ever since i installed Bazzite last year.
pipewire suspending is not the same as device suspending
i think that the reason it says the speakers are not "connected" is because of pipewire suspend
the other issue with game mode just not playing any audio i don't really know what is going on
okay so the issue is not the sink at least looking at the status, they're both correctly selected
I'm not entirely sure what is going on here, I hope someone else is able to take a deeper look at this.
The only difference i see between my own device and your is that your "Streams" is completely empty
and for me its showing Chromium.
Oh i see, thanks for clarification
How can i disable pipewire suspend?
through a json file, im not too well versed in wireplumber but ill try to cook something up
I don't think it will matter much, but we might as well try to see if it does anything.
Scratch that idea. I've done some research and what I think is going on is that the jack detection for your internal speakers is borked and on boot is not detecting your internal speakers. That seems to be the problem, especially since
alsactl init fixes the issue temporarily, because this disables jack detection entirely (and makes every device play audio)
I think we should try setting the node to always be detected as available.Would that mean that i have to switch to headphones manually or does it just not completely disable the speakers when a headphone is connected?
no ALSA detects your internal speakers as unavailable ("In Desktop Mode it's the same unless i go into the KDE settings and select the speakers (KDE says that they're not available)")
then wireplumber chooses another device
and that's the main culprit i think
realtek still uses a form of sensing (jack detection) for internal speakers and somehow your internal speakers are not detected as available
you can still switch to it manually just like how you're able to switch manually to headphone jack port
even if nothing is inserted
My guess is that game mode doesn't like it when a device is detected as unavailable (but keep in mind that might also be a completely separate issue)
Let's first fix the reason why ALSA detects device as not available. This should be fairly simple by just forcing it as available.
@MyFairJulia Could you do
wpctl inspect 71 and wpctl inspect 55 after a reboot and in desktop mode?
without having done any state changingI‘ll do that in a few minutes
need to know all the property names to create a conf
You first need to do
wpctl status and then afterwards do wpctl inspect on the device and sink of "Family..." devices.Here's the output for
wpctl inspect on the device:
id 74, type PipeWire:Interface:Device
alsa.card = "1"
alsa.card_name = "HD-Audio Generic"
alsa.components = "HDA:10ec0245,1fdb0002,00100001"
alsa.driver_name = "snd_hda_intel"
alsa.id = "Generic_1"
alsa.long_card_name = "HD-Audio Generic at 0xdc5c0000 irq 128"
alsa.mixer_name = "Realtek ALC245"
api.acp.auto-port = "false"
api.acp.auto-profile = "false"
api.alsa.card = "1"
api.alsa.card.longname = "HD-Audio Generic at 0xdc5c0000 irq 128"
api.alsa.card.name = "HD-Audio Generic"
api.alsa.path = "hw:1"
api.alsa.split-enable = "true"
api.alsa.use-acp = "true"
api.dbus.ReserveDevice1 = "Audio1"
api.dbus.ReserveDevice1.Priority = "-20"
* client.id = "41"
* device.api = "alsa"
device.bus = "pci"
device.bus-path = "pci-0000:63:00.6"
* device.description = "Family 17h/19h/1ah HD Audio Controller"
device.enum.api = "udev"
device.icon-name = "audio-card-analog-pci"
* device.name = "alsa_card.pci-0000_63_00.6"
* device.nick = "HD-Audio Generic"
device.plugged.usec = "7491143"
device.product.id = "0x15e3"
device.product.name = "Family 17h/19h/1ah HD Audio Controller"
device.string = "1"
device.subsystem = "sound"
device.sysfs.path = "/devices/pci0000:00/0000:00:08.1/0000:63:00.6/sound/card1"
device.vendor.id = "0x1022"
device.vendor.name = "Advanced Micro Devices, Inc. [AMD]"
* factory.id = "15"
* media.class = "Audio/Device"
object.path = "alsa:acp:Generic_1"
* object.serial = "453"
spa.object.id = "4"
And here's the output for the sink:
id 42, type PipeWire:Interface:Node
alsa.card = "1"
alsa.card_name = "HD-Audio Generic"
alsa.class = "generic"
alsa.components = "HDA:10ec0245,1fdb0002,00100001"
alsa.device = "0"
alsa.driver_name = "snd_hda_intel"
alsa.id = "ALC245 Analog"
alsa.long_card_name = "HD-Audio Generic at 0xdc5c0000 irq 128"
alsa.mixer_name = "Realtek ALC245"
alsa.name = "ALC245 Analog"
alsa.resolution_bits = "16"
alsa.subclass = "generic-mix"
alsa.subdevice = "0"
alsa.subdevice_name = "subdevice #0"
alsa.sync.id = "00000000:00000000:00000000:00000000"
api.alsa.card.longname = "HD-Audio Generic at 0xdc5c0000 irq 128"
api.alsa.card.name = "HD-Audio Generic"
api.alsa.headroom = "0"
api.alsa.path = "front:1"
api.alsa.pcm.card = "1"
api.alsa.pcm.stream = "playback"
api.alsa.period-num = "32"
api.alsa.period-size = "1024"
audio.channels = "2"
audio.position = "FL,FR"
card.profile.device = "3"
* client.id = "41"
clock.quantum-limit = "8192"
device.api = "alsa"
device.class = "sound"
* device.id = "74"
device.profile.description = "Analog Stereo"
device.profile.name = "analog-stereo"
device.routes = "2"
* factory.id = "19"
factory.name = "api.alsa.pcm.sink"
library.name = "audioconvert/libspa-audioconvert"
* media.class = "Audio/Sink"
* node.description = "Family 17h/19h/1ah HD Audio Controller Analog Stereo"
node.driver = "true"
node.loop.name = "data-loop.0"
node.max-latency = "16384/48000"
* node.name = "alsa_output.pci-0000_63_00.6.analog-stereo"
* node.nick = "ALC245 Analog"
node.pause-on-idle = "false"
* object.path = "alsa:acp:Generic_1:3:playback"
* object.serial = "458"
port.group = "playback"
* priority.driver = "900"
* priority.session = "900"
session.suspend-timeout-seconds = "0"mkdir -p ~/.config/wireplumber/wireplumber.conf.dDone
Just to be sure, the internal speakers show as unavailable even when nothing is inserted in the headphone jack?
because its normal if there's something plugged in the headphone jack
@antheas Sorry to tag you, but I really need your help here. It's a (GPD Win device, you love these devices), it seems to have an issue with switching ports (ALSA auto mute)?
it shows internal speakers as unavailable
Did you ever open your device?
Sounds like headphone autodetection broke on your device
Gpd win mini works fine
You're the only one with an issue + the other guy that removed a daughter board
That's what I was thinking, there's a little tiny switch in the headphone jack. If that's busted you're just gonna have to disable auto mute
and manually control the mixer from now on
To test if Internal Speakers work fine in game mode: Reboot device, open TTY session with Ctrl+Alt+F2, and then:
amixer -c 1 sset 'Auto-Mute Mode' Disabled
amixer -c 1 sset Speaker 100% unmute
This should unmute and set Speaker volume to 100% and if audio plays, your internal speakers work fine in game mode 🙂
If it saysUnable to find simple control then it could be amixer -c 0 instead, but that's usually your HDMI audio card.I did open my device, but this happened weeks ago and thus it would be weird if the issue started popping up now. Especially since i only removed the fan.
I did take a look into the headphone jack and it looks odd indeed. I‘m starting to suspect that something has gotten inside that shorts out the ground pin which another pin and thus makes my Win Mini believe a headphone is connected.
This is what my headphone jack looks like
IT WAS THE DEBRIS!
Here‘s a picture for comparison
Okay, i‘m not entirely sure whether it was debris shorting the headphone jack.
The jack doesn‘t look so different from before. But there might have been debris in there that shorted the jack out.
I followed the instructions outlined here to clean my headphone jack: https://www.wikihow.com/Clean-a-Headphone-Jack
Then i booted my Win Mini and now headphone autodetection works again. There might be a better way to clean a headphone jack and i‘m certain it didn‘t look that way when the Win Mini came. But it is a helpful first step one can take if autodetection fails.
wikiHow
Clean a Headphone Jack
Easily clean dust or debris from your headphone jack or aux port Are you having issues connecting headphones to your phone or other electronic device? When your headphone jack is left uncovered in your bag or pocket, it can easily...
INTERDENTAL BRUSH? THIS TOOL IS NOT AT THE TOP? THAT‘S THE BEST TOOL FOR THIS PURPOSE. THE HELL DID WIKIHOW SMOKE?
best thing you can use is a can of compressed air with the little plastic tube thingy
fits inside of it perfectly
and just spray
i do the same for USB-C ports
Solution
For future reference, here are the steps users can take if the automatic headphone detection fails:
Step 1: Make sure to clean out the headphone jack because lint can short the ground to another pin and make any device think that a headphone is connected.
@CheckYourFax recommends a can of compressed air. Should that not be enough, i recommend an interdental brush as it‘s small enough to get in there and does not risk leaving lint behind unlike the trimmed cotton swab i used.
Also use isopropyl alcohol to clean tech up. NEVER EVER EVER USE WATER! We‘re here to remove a short, not to risk shorting the rest of the PC.
If that fails, your headphone jack is borked. If you do not happen to have the soldering skills and the correct headphone jack ready, you can use the following commands to disable headphone detection:
amixer -c 1 sset 'Auto-Mute Mode' Disabled
amixer -c 1 sset Speaker 100% unmute
If that fails with Unable to find simple control then you can try amixer -c 0.
Thank you @CheckYourFax for retrieving those commands and for your assistance.