Add two-input stereo-output microphone mode

[seanogdelaney]

Summary:

• add a Two-in/Stereo-out client audio mode

• send the second input as an auxiliary mono Mic channel

• use the Vocal instrument icon for the Mic channel

• persist and expose the new audio-channel setting

• Implements Two-in/Stereo-out: simplified support for separate mixer channels for a user's instrument and microphone #3756.

• Implements a narrow subset of Multi Channel Fader on one Jamulus #96.

• Related to Allow mono input device and channel selection for stereo input devices. #2344.

Validation:

• Compiles on Linux
• Runs on Linux
• Two channels appear in mixer as expected, with second suffixed 'Mic', using vocal icon.

Notes:
Running two jamulus clients can achieve this, but is a bit awkward.
This way makes it more accessible (less flexible, but easier).

[dingodoppelt]

From a first skim through the code I could gather that CAuxiliaryMonoSender basically duplicates CClient without raw audio transmission. Is there a reason for not trying to reuse CClient?
I guess since it is client only code we now occupy two channels with one client?
Have you thought about less invasive alternatives like UI only changes, i.e. splitting stereo clients (with vocal and instrument combination) into separate channels?

[seanogdelaney]

Thanks. Yes, the auxiliary sender is intentionally a cut-down client-side network peer, so it does occupy a second server channel. That is the point: the extra vocal input appears as its own fader/channel in the mixer for all participants, without requiring server or protocol changes. I did consider reusing "CClient", but "CClient" owns much more than the transmit path: sound device lifecycle, receive/mix/playback, UI-facing state, raw audio handling, local monitor logic, etc. A second "CClient" would either try to own another sound device or require a larger refactor to separate “Jamulus network/audio stream endpoint” from “full client”. The auxiliary sender is intended to avoid that larger architectural change. I agree there is overlap. It would be possible to refactor CClient into a reusable base plus the existing full client, with the auxiliary sender deriving from (or using) the reusable part. That looked like a significantly larger architectural change. For this PR, a small private helper seemed simpler and less invasive. I think you may misunderstand. A UI-only change won't work here. Each client channel exists on the server, where it is mixed and sent to each clients. To expose separate vocal and instrument faders, the server must receive them as separate channels. Otherwise we'd need to modify the server to split the incoming stereo stream into separate mono channels when this client mode is enabled, which would be a considerably more invasive change.

…

On Sun, 28 Jun 2026, 22:55 Nils Brederlow, ***@***.***> wrote: *dingodoppelt* left a comment (jamulussoftware/jamulus#3757) <#3757 (comment)> From a first skim through the code I could gather that CAuxiliaryMonoSender basically duplicates CClient without raw audio transmission. Is there a reason for not trying to reuse CClient? I guess since it is client only code we now occupy two channels with one client? Have you thought about less invasive alternatives like UI only changes, i.e. splitting stereo clients (with vocal and instrument combination) into separate channels? — Reply to this email directly, view it on GitHub <#3757?email_source=notifications&email_token=ACXCDDWQQHBLWPKHWYCFX635CGH5ZA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOBSG42TCMJUGEY2M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-4827511411>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACXCDDV7ZUDJLFLO6MB63M35CGH5ZAVCNFSNUABFKJSXA33TNF2G64TZHMYTONZSHA3TOMJQHNEXG43VMU5TINZWGMZTQOJSGY42C5QC> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/ACXCDDTNWP7SLQFVYPMIPPD5CGH5ZA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOBSG42TCMJUGEY2M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KUZTPN52GK4S7NFXXG> and Android <https://github.com/notifications/mobile/android/ACXCDDWFPKM35FISSCU2RGT5CGH5ZA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOBSG42TCMJUGEY2M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA>. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***>

[dingodoppelt]

I think you may misunderstand. A UI-only change won't work here. Each client channel exists on the server, where it is mixed and sent to each clients. To expose separate vocal and instrument faders, the server must receive them as separate channels. Otherwise we'd need to modify the server to split the incoming stereo stream into separate mono channels when this client mode is enabled, which would be a considerably more invasive change.

I find this change very invasive by it's sheer size while it is not very clear what is to be achieved.
If we are using two server slots, why is this mono-only/non-raw? A client already sends two mono signals in all available audio qualities. This should be exploited first before duplication of code.
Why do you think changes to the server would be more invasive? A server would receive a stereo packet and treat it like two mono paths. I'd start from there to keep changes simple and small.

[seanogdelaney]

Firstly, respect (to you and the community) for such fast responses on issues / PRs. It's much appreciated!

You express three very reasonable concerns: intent clarity, code size, and the server-side alternative. My perspective is:

Intent Clarity: The aim is "mixer shows 1 fader per source" instead of "1 fader per person". The most common situation is a person who sings and plays an instrument (two sources). This PR addresses that case, but could be extended later (e.g. stereo instrument + mic), see for example issue #96.

Code size: This change is about 300 real lines of code, mostly isolated in the auxiliary sender. If it can be achieved in less code (without sacrificing quality / maintainability), I'd like that very much.

Server-side alternative: I agree it's possible (i.e. a client check-box triggers the server to split a stereo channel into two mono channels before the mixer stage). It's not clear to me that this would be less code, or less invasive. It also doesn't provide a natural path to cases "stereo DJ decks + mic", or the more general multichannel support discussed in #96.

So my thinking was to implement the more general model from the outset: independently mixable sources are sent as independent channels. This PR just implements the simplest two-source case.

[dingodoppelt]

This way makes it more accessible (less flexible, but easier).

Is there really a usecase for this? Why is this better than using two clients or simply mixing a stereo mix and feeding that into Jamulus for the sake of stereo and raw audio? I don't know if people will use this when there is not even a stereo signal available.
By the approach taken a lot of code is duplicated and would have to be maintained in parallel. I really think the server is the place to start here and have clients do the visuals.
I could see some benefit in this, if...

• There was only one channel occupied at the server
• There was stereo
• There was raw audio

In general I think we shouldn't give two channels to one client. I know this is being done but I have never liked it and I still think people shouldn't do it.
Missing stereo and raw audio support will be a deal breaker for many.

[seanogdelaney]

Thanks, that helps clarify the concern.

Use case: I believe there is a real use case here. A mono instrument plus mono vocal is common for people playing in Jamulus “rock band” style sessions: bass + vocal, guitar + vocal, etc. In that situation, independent mixer faders are useful even though neither source needs stereo.

Why not two Jamulus clients: that is what I currently do, but it is hard to recommend to less technical users. It requires either scripts with separate ini files, or repeated manual configuration. Many users will find that awkward or conceptually confusing.

Code duplication: I agree this is the main weakness of the current implementation. If you are open to it, I can reduce this by factoring the relevant sender-side parts out of CClient rather than maintaining parallel code.

Stereo / raw audio: agreed, this PR does not cover those cases. They would require more code, so I would prefer to handle them in a follow-up PR if this general direction is acceptable.

Multiple mixer channels per user: I understand this is the central design disagreement. I do not want to argue against the maintainers’ preferred model. My motivation is simply that I believe many users would find this useful, myself included, and that independently mixable sources mapping to independent channels is a natural model for this use case.

[dingodoppelt]

Thanks, that helps clarify the concern.

Use case: I believe there is a real use case here. A mono instrument plus mono vocal is common for people playing in Jamulus “rock band” style sessions: bass + vocal, guitar + vocal, etc. In that situation, independent mixer faders are useful even though neither source needs stereo.

I use a similar setup (multiple instruments, analog and digital through some effect chains) and I surely need stereo for everything. I'm mixing all my channels locally and just send a stereo mix.

Why not two Jamulus clients: that is what I currently do, but it is hard to recommend to less technical users. It requires either scripts with separate ini files, or repeated manual configuration. Many users will find that awkward or conceptually confusing.

To launch the client with a separate INI file you don't need a script, just the cli option -i. This is well documented and not at all awkward or confusing in my opinion. At least on Linux this is a one-click matter.

Code duplication: I agree this is the main weakness of the current implementation. If you are open to it, I can reduce this by factoring the relevant sender-side parts out of CClient rather than maintaining parallel code.

I'd say CServer is a better place to make this happen as we already have a path to send two mono channels (stereo configuration)

Multiple mixer channels per user: I understand this is the central design disagreement. I do not want to argue against the maintainers’ preferred model. My motivation is simply that I believe many users would find this useful, myself included, and that independently mixable sources mapping to independent channels is a natural model for this use case.

"Multiple" is not what you actually propose here. It is "two mono signals" which is a stereo signal in current Jamulus terms. This only applies to users using mono for all their instruments exclusively. This may be ok for a bass player but pianists, guitarists and vocalists generally use stereo signals for the sake of sound fidelity (this is what we tell users when they join a server with mono signals) and those users wouldn't make use of this feature.

[dingodoppelt]

We have #3746 that introduces multichannel support but only on iOS.
If we had this cross platform we could think about acquiring more than two channels and send those simultaneously from one client. Either in multiple messages or over dedicated sockets.
Since the limitation mono/compressed is not a technical boundary but a deliberate design decision and tailored to a very limited use case I don't think this is the right approach. Not many users will make use of this I fear.

[dingodoppelt]

If running two clients seems awkward you may want to try running the secondary client without a GUI (-n) so you don't receive chat messages twice and stuff like that. An RPC method has just been introduced to mute yourself or you could use MIDI to control the headless client.
In theory you could have even more clients with stereo/raw sound that way.

[dingodoppelt]

#1063 and #1840 are still open and it hasn't been agreed upon a strategy to pursue with this but the ideas seem to point in a different direction of a more general way of sending multichannel audio. Use cases differ wildly and we need the widest possible coverage.

[dingodoppelt]

Why is raw audio transmission left out?

[dingodoppelt]

I'd say stereo already covers this. This should rather tell the server to treat a stereo signal as two mono signals and have the client display two channels instead of one.

[dingodoppelt]

This would have to be maintained separately from the main code for audio transmission and is already out of date as it doesn't support raw audio or even stereo while there is no clear reason other than covering a singular use case.
While we have a socket, why not use it to its full potential?

[dingodoppelt]

The server sends audio that will never be played back from the client. Is this really necessary? Shouldn't the server rather not return anything, just consume additional samples from the client? CAuxiliaryMonoSender doesn't imply receiving as well.