Mumble: Multi-channel audio interface support

[krono86]

In which context would you expect your suggested feature to be useful?
Using Mumble with multi-channel audio interface.

Describe the feature you have in mind
A clear and concise description of what you want to happen.
It would be useful to select not only the preferred in/out audio interface to be used by Mumble, but also the specific channels.

Describe alternatives you've considered
At the moment I have to use virtual audio interfaces (e.g., Soundflower, Blackhole, Rogue Loopback) in Mumble to route my desired audio channels through the first two channels of the virtual audio interface.

[Krzmbrzl]

For reference, this is what we already support: #3064

[stemcc]

For me, multioutput audio is the holy grail of Mumble features and it's my understanding that Mumble right now will mix down everything into a stereo output.

I use Mumble where I have users join a room where I've routed a particular audio feed into the room and people listen and comment on this running feed, and I route the audio of that room back out into a software mixer. Right now I am needing to open a seperate client instance for each room I need to route audio out of in order to route that audio using a different audio output. Once I've got more than a few rooms open like this, things start getting a little unweildly with all the seperate client windows open.

But then again, maybe there's another way of approaching this I've overlooked?

[Krzmbrzl]

For me, multioutput audio is the holy grail of Mumble features and it's my understanding that Mumble right now will mix down everything into a stereo output.

Actually the transmitted audio is mono. There only really is stereo if positional audio kicks in. However this is not what this issue is about. I think you'd be more interested in #2829.

But then again, maybe there's another way of approaching this I've overlooked?

:shrug:

[telephon]

Given the excellent low latency, we are currently looking into using mumble for network music. There, multichannel transmission, and a convenient choice in the client for higher audio quality (>96mbps) may be useful.

[eldorel]

I have a rather nice interface with 8 inputs, and a separate pre-amp that connects to it via ADAT that shows up as channels 9-16.

I prefer the sound from the preamp (and it's the one sitting on my desk while the other one is in the rack and wired into all of the permanently connected devices.)

As it is, I'm using a virtual device driver (vbaudio voicemeeter) to route the higher-numbered input to channel 1/2 for mumble, but that adds quite a bit of latency. If I could tell mumble to use inputs 9-10, that would remove the need for the extra software.

Additionally, if mumble was able to send more channels (without combining them to mono) users could theoretically use it to share other audio sources like music.

Users could also use multi-channel settings for recording podcasts/raid events for post-processing.
As it stands, we have to use a convoluted workaround with multiple clients and local-mute to prevent all of the communications chatter being combined into one two-channel mono track when we record.

[streaps]

Would stereo streaming be sufficient or do you need more than 2 channels per user?

Do I understand it correctly that you would like to route the audio from each user to a separate audio channel?

[krono86]

I think stereo streaming should be sufficient, but we need to select the preferred two input channels, and, hopefully, two output channels for each user.
That would be great!

Ivan

[eldorel]

I think my comment is actually three separate items that all fall under "multi-channel"

1. Stereo would be great for music or people with ASMR/stereo/binaural mic setups.

2. Multiple channel selection/mapping to allow for higher number channels to be selected instead of defaulting to input+output channels 1/2 for a given device.

3. More complicated routing options to allow users/admin to select different (or multiple) output channels for different users (or linked rooms).

It seems that items 1+2 are reasonable.

Item #3 is probably not within scope for mumble, but would make it an amazing option for people running livestreams/podcasts/etc.

(edit: and item #3 combined with working ASIO outputs could allow for some incredibly useful/powerful options.)

[streaps]

1. shouldn't be too hard to implement.

2. is maybe a bit overkill for the standard Mumble client. I think it's better to have a separate app for this, like a "studio" client. It could have very basic functionality (no administration, no text chat, no serverlist retrieval and ping, maybe not even any channel UI, no echo and noise suppression, no positioning algo), just user to output channel mapping.

[telephon]

1. shouldn't be too hard to implement.

That would be a great first step, plus a larger range of audio quality settings.

Is multichannel audio already supported on the server side? And is the audio from the different participants mixed on the server side or do we already get all streams separately?

1. It could have very basic functionality

How would you then switch channels and see who is participating? You'd still need that I suppose.

[Krzmbrzl]

Is multichannel audio already supported on the server side? And is the audio from the different participants mixed on the server side or do we already get all streams separately?

The server only relays the audio data it receives to the respective clients. It doesn't do any audio processing.

[eldorel]

1. is maybe a bit overkill for the standard Mumble client. I think it's better to have a separate app for this, like a "studio" client. It could have very basic functionality (no administration, no text chat, no serverlist retrieval and ping, maybe not even any channel UI, no echo and noise suppression, no positioning algo), just user to output channel mapping.

I think you're mixing Items 2 and 3 into a single use case, which was not my intention.

For item 2, I was specifically thinking about my personal setup.

I have multiple inputs on my sound device (interface) and at the moment I am forced to either use inputs 1+2 for my mic or route the mic through software so that it's on channels 1+2 of a virtual sound device. (which adds latency/delay)

My interface has better mic preamps on inputs 5+ than 1-4, so I have to choose between latency and quality right now.

The same applies for output as well. If I want mumble to output on a different pair of speakers on a multichannel device, then I have to do this in software.

It would be MUCH easier if mumble saw that I have a 7.1 card and just let us select Front, rear, or side channels, or if it saw that the input device I have selected had 8 channels and let me select one from a dropdown menu. (bonus if there was a MONO/Stereo selection as well...)

This doesn't even require any fancy hardware.
Just using the 7.1 outputs on most motherboards, this would give users the option to connect 5.1 speakers and use the leftover jack for a headset connected to mumble, or use the front/rear/line-in separately on sound cards/interfaces/ADCs/etc that don't publish them as separate devices.

Additional note: A notable chunk of the work is already done!

The windows client has a multi-channel selection UI already in place for ASIO support.

Unfortunately, ASIO support doesn't work at the moment (crashes and no output options [ see issue #2274 ] ) and most onboard and retail sound cards don't offer ASIO drivers.

Honestly, as long as the channel selection and routing was properly abstracted, co-opting the ASIO multichannel UI code and modifying it to work with WASAPI would also make it easier to identify where the ASIO code is breaking.

[k1ttt-remote]

4209 adds stereo streaming from bots, but no hardware input mechanism. There are several uses in ham radio operation that need stereo hardware inputs from standard sound cards.