Buzzing in the speaker when the system is turned off

[Yotakon]

Hello everyone and thank you, I have been using the PIXIE version of this wonderful OS for a while and I have never had this problem on my RG35XX-H, the speaker in GOOSE produces a sound when it is turned off, to check I went back to Pixie and turned off the console several times, with this I verified that said sound does not exist in Pixie (at least on my device) is it solvable?

[Girouette]

Can confirm this happens with the RG35XXSP as well.

[DuongTH]

Same on my RG35XXH and Trimui Smart Pro

[kayarelle]

I notice this on my 35xxsp and my cubexx

[jader242]

Same here on my 35xxH, I don’t recall it happening on Pixie

[genti7]

I can confirm the issue on 40XX-H

[smartazz104]

Well I’ll throw a curve ball here and say that I don’t get any sound when turning off (RG35XXSP).

[andromalandro]

Same issue here, the devs on discord have said that is the speaker turning off but I have an extra sd card with pixie so I can test things out and it doesn’t make any sound while powering off. I have a 35XX H btw.

[teggydave]

Hey everyone, I don’t have a solution but I can confirm the devs and testers (myself included) are aware of the speaker “buzz” or “pop” during shut off. This is caused by the power itself being cut-off from the speaker.

[xonglebongle]

This should now be resolved.

It came down to how the audio path and the speaker amplifier behaved during shutdown.

Why it was happening?

• We introduced a small helper module that keeps the speaker path active. During shutdown that helper was being terminated too early.
• Muting only at the PipeWire level does not guarantee silence at the codec or the “amplifier” level. The graph is muted, but the analogue path can still click when power rails fall or the codec enters suspend with a non zero output.
  • This is because of how the hardware is actually designed…
• If the amplifier is disabled before the codec output and mixers are muted and settled, the amplifier hears a step or DC offset as power collapses. That is the audible pop you hear.

What the hardware is doing

Well when we do a “safe” reboot or shutdown it generally goes in this order, at least from what I understand anyway…

1. Reduce digital level to zero
2. Hard mute the codec path
3. Let the codec mixers settle
4. Disable the speaker amplifier
5. Only then stop user space audio services

If steps 1 to 3 are skipped or reordered, the amplifier may see a sudden edge or offset exactly when it is being switched off.

Technical notes

• PipeWire mute is graph level only from what I understand. It does not toggle codec mixer switches or the external amplifier enable line.
  • Not that it makes a difference, the speaker (or amplifier) I believe is always powered and active.
• Many codecs expose soft ramp and zero cross controls. Enabling these allows volume and mute changes to occur at a zero crossing or with a short ramp, which removes clicks from abrupt changes.
• The helper process that kept the path alive was masking timing issues. Killing it first allowed the codec to suspend while the amplifier was still on, which is the worst possible moment for a click.
• Some class types of speakers and amplifier combos in handhelds are sensitive to this kind of sequencing(?). They expect the input to be muted and settled before enable or disable, otherwise their input filter reproduces the edge as that audible pop.

Okay, cool, the fix?

Well just like the other issue statement from the other I guess you’ll want to know what has changed to see what we’ve done to rectify it.

• PipeWire Start

  • Wait for DBus and PipeWire responsiveness
  • Select the correct default sink for the device mode
  • Set the requested volume, unmute the codec control, unmute the PipeWire sink
  • Start the speaker active keep alive process
  • Mark audio as ready

• PipeWire Stop

  • Fade the PipeWire sink volume down to zero in small steps
  • Allow a brief settle so mixers reach a stable zero output
  • Disable the external speaker amplifier through its mixer control
  • Stop the speaker keep alive process, then stop PipeWire and WirePlumber
  • Mark audio as not ready

This ensures the analogue path is “quiet and stable” before the amplifier is switched “off”, and that we continue the reboot/shutdown process after the hardware is already silent.

What this means for you

If you were hearing that pop on shutdown, this sequencing change should remove it on affected devices. The fix is in testing and will be included in the next release. This one may be able to be fixed on current devices however due to the number of changes like the “boot issue” I will be rolling it out into a new full image instead of a patch.