MUOS sometimes boots without sound

Issues 2508 Goose
1

Hi, so I’m having this issue where sometimes, apparently at random, my RG35XX-H will boot without sound and no amount of tweaking settings or trying to increase the volume affects it at all, it’s just completely mute.

The only way to solve it I’ve found is to restart the device and hope it’s not a “mute boot”.

Also I’ve noticed that in the instances where this happens, the volume bar resets between screens, as if the volume wasn’t changed at all.

I don’t know how to troubleshoot this, and I’ve already done a full reflash but it keeps happening. I’m on Golden Goose 4f83d826.

Please let me know if there’s anything I can check to make it easier to pinpoint the cause.

Thanks in advance!

1 Like
[RG34XXSP] Device starts up at full volume
2

I can confirm that, happens the same thing on my RGCubeXX.Also on the Golden Goose.

I realized that when this happens, I go into the Bluetooth app and try to change the audio output, but there’s no alsa sound driver available.As if no driver has been loaded in this case.

1 Like
3

I’m having the same problem with my rg40xx h. When this happens, StardewValley won’t launch and just crashes.

4

Unless it is replicable and you have done a complete fresh flash with no modifications, and you are certain that you are using a reputable and quality mSD card, there isn’t much we can do to help troubleshoot this except in the instance of sending me your device.

5

I have had the same issue on my RG35XX SP ever since I upgraded to the Golden Goose. I did a fresh flash to a new Samsung mSD. Sometimes it boots just fine, and sometimes it boots without a sound. It seems to be random and a reboot usually fixes it.

It is not as rare as it might seem. In my experience, it happens on every third or fourth boot and it´s not that hard to trigger it by a few power cycles.

6

I am no linux expert, but I checked the pipewire.sh script and it looks like a race condition between ALSA initialization and PipeWire startup.

Correct me if I am wrong, but looking at the DO_START() function: START_PIPEWIRE is called first, launching the daemons. After that (DO_PRESTART) & runs in the background.

DO_PRESTART is responsible for copying asound.conf/alsa.conf and running alsactl restore. Since this runs asynchronously after PipeWire has already started, there is a window where WirePlumber initializes before ALSA is fully configured or the mixer state is restored.

When this happens, PipeWire seems to fall back to the Dummy-Driver (defined in pipewire.conf).

The script doesn’t catch this error because FINALISE_AUDIO only checks for grep -q "Audio/Sink". Since the Dummy Driver registers as a valid sink, the script assumes audio is ready and exits, leaving the device muted on the dummy output.

7

Actually, it might not even use the dummy at all.

I SSH´d into my RG35XX SP, and this is a printout from the “wpctl status”

[~]# wpctl status
PipeWire ‘pipewire-0’ [1.0.4, root@muos-792312, cookie:636276438]
└─ Clients:
20. WirePlumber [1.0.4, root@muos-792312, pid:1482]
21. WirePlumber [export] [1.0.4, root@muos-792312, pid:1482]
40. PipeWire ALSA [muxfrontend] [1.0.4, root@muos-792312, pid:2711]
46. wpctl [1.0.4, root@muos-792312, pid:8198]

Audio
├─ Devices:
│ 29. Built-in Audio [alsa]
│ 30. Built-in Audio [alsa]
│
├─ Sinks:
│ 23. Built-in Audio Stereo [vol: 0.40]
│ * 31. Built-in Audio Stereo [vol: 1.00]
│
├─ Sink endpoints:
│
├─ Sources:
│
├─ Source endpoints:
│
└─ Streams:
41. PipeWire ALSA [muxfrontend]
42. output_FL > Stereo:playback_FL [active]
43. output_FR > Stereo:playback_FR [active]

This is a normal, working state.

This is the same printout on a silent boot.

[~]# wpctl status
PipeWire ‘pipewire-0’ [1.0.4, root@muos-792312, cookie:650192112]
└─ Clients:
20. WirePlumber [1.0.4, root@muos-792312, pid:1481]
21. WirePlumber [export] [1.0.4, root@muos-792312, pid:1481]
27. wpctl [1.0.4, root@muos-792312, pid:5287]

Audio
├─ Devices:
│ 25. Built-in Audio [alsa]
│ 26. Built-in Audio [alsa]
│
├─ Sinks:
│
├─ Sink endpoints:
│
├─ Sources:
│
├─ Source endpoints:
│
└─ Streams:

The ALSA hardware is detected, but the Sinks list is empty. PipeWire saw the hardware but failed to negotiate a profile, most likely because the ALSA state wasn’t ready.

Another small update. I noticed that /var/lib/alsa/asound.state is missing during silent boot. Running /opt/muos/script/system/pipewire.sh restart from the SSH fixed missing pipes, but the sound came on after I ran alsactl -U -f “$DEVICE_CONTROL_DIR/asound.state” restore

8

I’ve rebooted several times over the past hour, both internal, via HDMI, internal audio w/ HDMI. So far the current changes are looking promising. But I guess I can’t exactly try every single combination of device and mSD card out there. So we’ll see what happens.

1 Like
9

Thanks for looking into it, xongebongle. Please let me know if you’d like to test it out. As I mentioned earlier, I encounter this issue frequently. You probably won´t make it a hotfix. I could pull the updated scripts from GitHub, but I am not sure if I can catch all the dependencies. So far, I tracked these changed scripts. Would these be enough?

/system/pipewire.sh
/system/network.sh
/system/startup.sh
/mux/quit.sh
/mux/frontend.sh
/mux/install.sh
/var/func.sh

/settings/advanced/audio_ready

10

Thanks for the latest update! I updated my device to Loose Goose, and I suspect the “Audio Subsystem Wait” in the advanced settings should fix the issue. I enabled it and will test it in the following days. So far, it looks very promising, and there is no noticeable delay in boot times :heart:

11

This topic was automatically closed 60 minutes after the last reply. New replies are no longer allowed.