Splitting a client...

[dakhubgit]

I am currently digging through the source for implementing a somewhat arcane but useful server-only (for now) feature: if the name of a client contains an "&" sign (command-line configurable), its mixer strip is split into two mono strips (for that to be useful in any way, of course, it has to stereo to start with). That means that, say, "Alex & Betty" which both have their own microphone but are sharing home and sound card, can be independently panned and level-controlled in the mixes.

The server-only implementation will come with one bug, of course: since the server can only designate one of the strips as owned by the client, when the client presses "Mute myself", it will not just appear mute to everyone else (due to sending a muted signal) but the locally substituted sound will then be according to the stereo panning interpretation of the one strip the client imagines to represent itself.

It is a good question how to fix this in the long haul. Maybe "Mute myself" would work by telling the server that one will mute oneself, and the server acknowledges by sending back the 2×2 matrix that the client should use to map its input to the output. In that case, only the server needs to know which strips belong to the client.

[ann0see]

Just a question here: why can't the client also mix both signals locally? Wouldn't that fix the problem?

[dakhubgit]

My first implementation will be server-only: the client does not realise that it's responsible for two mono mixer strips but thinks it is just providing a single stereo strip. Basically I am in control of compiling my own GNU/Linux client and the server (also running under GNU/Linux). But nobody else in our group uses a GNU/Linux client.

Now for the question "why can't the client also mix both signals locally": it does, of course, under the assumption that it is serving only one mixer strip. And it will take that strip's volume for both signals, and use its pan control as a balance control rather than a pan control.

To do this right, the client would need to be aware that it is providing signals for two mixer strips to the server. Any proposal of mine asking the server to accept any different number of channels or quality differing from what it sends (if only to stop sending zeros when muting yourself, or to make for send-only or listen-only setups) have been shot down so far as violating the "KISS" principle.

Working code would likely eventually soften up that stance (which in my book is more stupid than simple) but would be a hen-and-egg problem and take several iterations of getting any client code into a release.

In the mean time, I need to solve a problem for the group I am rehearsing with, and it can be addressed server-only even if it messes up "mute myself" locally. But we don't need people muting themselves, certainly not while getting an adequate simulation of not being muted. So that shortcoming is not much of a concern for getting my problem solved.