Add global master volume control to firmware audio mixers

[chrisgleissner]

Summary

This PR adds a persisted Vol Master control which scales the existing per-source mixer gains.

The main reason for this change is REST-based control:

A remote client should be able to mute or change the overall firmware-mixed volume without having to rewrite every individual mixer source setting.

Screenshots

Master Volume Off

Max Master Volume

Benefits

This PR addresses two practical problems with the current REST control model that I observed whilst working on C64 Commander, a new REST/FTP/Telnet client to control the U64:

1. Mute/unmute currently requires too much client-side state

At the moment, a REST client that wants to mute all firmware-mixed audio has to do something like this:

1. Read all relevant mixer source volumes.
2. Store those values on the client side.
3. Set every relevant source volume to Off.
4. Later write the old values back again.

That is fragile.

It makes the client responsible for preserving the user's mixer balance. If the restore fails, is interrupted, or uses stale data, the device can be left with the wrong per-source volume settings.

With Vol Master, mute/unmute becomes a single-setting operation:

• set Vol Master to Off to mute
• restore Vol Master to the previous value to unmute

The detailed mixer balance stays on the device and does not need to be reconstructed by the REST client.

This is the main issue I ran into while working on C64 Commander, where mute should not require the app to temporarily take ownership of the whole mixer configuration.

2. Global volume changes currently require multiple config writes

The same problem exists for a global volume slider in a remote control app.

Without a master volume, one logical user action, such as lowering the overall firmware audio volume, has to be translated into multiple per-source config writes.

That has several downsides:

• more chances for partial updates and thus more risk of disturbing the user's source balance
• more REST traffic, specifically larger REST payload

With this PR, a global volume slider maps to one persisted setting. The per-source mix remains the long-term user configuration, and Vol Master becomes the operational top-level control.

This is also why the change applies to U2+ / U2PL. Those devices do not have HDMI, so this is not about HDMI vs. A/V output balancing. The benefit is the same as on U64: REST clients and external control applications get one safe top-level control for firmware-mixed audio.

Out of Scope

This PR does not solve HDMI vs. A/V output-level balancing. If the goal is to let users balance HDMI and A/V output levels once and leave them that way, independent output trims would be the more direct solution. This PR does not add those trims.

Also, the built-in speaker remains separate because it is configured separately and is often used for drive sounds. It would be un-intuitive for a user if an audio-mixer master volume also changed that speaker setting, thus effectively lowering the volume or entirely muting the disk drive - something that could never happen with a real hardware disk drive.

Code changes

This PR adds a new persisted mixer setting: CFG_MIXER_MASTER_VOL with config ID 0x2A

The existing mixer source volume IDs are unchanged.

The new setting is wired into both mixer implementations:

• U64 / U64-II: software/u64/u64_config.cc
• U2+ / U2PL: software/io/audio/audio_select.cc

In both paths, Vol Master scales the existing mixer source gains before pan is applied. This means the configured stereo balance and per-source mix are preserved while the overall firmware-mixed volume can be raised, lowered, or muted.

On U64 / U64-II, master-volume changes are applied immediately through the existing mixer update path.

The U64 AutoSID path is also updated so direct AutoSID mixer programming respects Vol Master. The existing AutoSID fallback behavior for slots configured Off is preserved, while Vol Master = Off still mutes AutoSID output as expected.

[Copilot]

Pull request overview

This PR resolves #663 by introducing a persisted global Vol Master control that scales (rather than replaces) the existing per-source firmware audio mixer gains on both U64/U64-II and U2+/U2PL, preserving the existing per-source balance while enabling quick overall trim/mute.

Changes:

• Add new persisted config item CFG_MIXER_MASTER_VOL (ID 0x2A) and expose it as Vol Master in both mixer menus.
• Apply master-volume scaling to all 10 firmware mixer inputs before pan multiplication on both product families.
• Update U64 AutoSID direct mixer programming to respect Vol Master while preserving the “OFF slot fallback” behavior.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
software/u64/u64_config.cc	Adds persisted master volume control, scales mixer gains (including AutoSID path), and hooks live updates.
software/io/audio/audio_select.cc	Adds persisted master volume control and scales U2+/U2PL firmware mixer gains prior to pan application.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[chrisgleissner]

Hi @GideonZ ,

this PR simplifies global volume control and (un)mute via REST.

I encountered the same issue in C64 Commander when implementing a global mute functionality, and having such a master volume would simplify the implementation and make it more resilient.

Best wishes
Christian

[Grrrolf]

@chrisgleissner, thanks for taking the time to put this PR together! I'm just wondering if a global master volume is the best way to solve the HDMI vs. A/V mismatch in #663.

If users have to constantly adjust this new setting depending on which output they are using, nothing really changes for them. They might as well continue using their TV remote or amp volume dial. Also, modifying the core mixer for the U2+/U2+L firmware seems unnecessary, since those cartridges only have analog out and don't feature HDMI at all.

This feels a bit like a band-aid rather than a direct solution. Wouldn't it make more sense to address the root problem by adding independent output trims for HDMI and A/V, so they can be balanced once and left alone?

[chrisgleissner]

Hi @Grrrolf,

Thanks for the feedback.

I have updated the PR description on 21 May 2026 to remove the reference to #663 and to make the actual purpose of this PR clearer.

I have also incorporated the REST/client-control justification into the main PR description, rather than leaving it buried in a separate reply.

Thanks again for pushing for the PR to be clearer, more direct, and not imply that it solves a different issue.

[Grrrolf]

@christeigner, this PR shouldn’t be linked to #663 unless it actually fixes the HDMI vs. A/V volume mismatch.

If this PR is meant to be an API enhancement for remote clients like C64 Commander, please say that clearly in the PR description. #663 should stay open so the issue submitter’s problem can still be solved with proper output trims.

Also, please keep the replies direct and human.

[chrisgleissner]

Hi @Grrrolf ,

I have removed the reference to #663 as per your suggestion since this PR indeed addresses a slightly different use case.

Thanks,
Christian

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.