Hi all! I've been working on a streaming setup that involves PulseAudio and Mumble.
The thing is, no matter what I try I can't keep mumble from attenuating certain applications. I have my PulseAudio set up with two virtual sinks: "stream" which is where the audio for my stream is recorded from and "stream_spkr" which routes audio to "stream" and my speakers. This allows me to pipe some sound into my stream without actually having to hear it, or into my stream and still be able to hear it depending on the sink. I, of course, attach Mumble to the "stream_spkr" sink so that I can hear what people are saying.
The thing is, though, that sometimes I use Mumble on my stream, other times I don't. However, when attenuation is active on Mumble it has a tendancy to attenuate every single application, regardless of what sink the application is attached to. So, if I'm running Mumble off-stream and, say, running some music through "stream", if somebody starts talking or I start talking, it attenuates the music application. This would be confusing to the viewers since the music volume would be going up and down for seemingly no reason (becuase they don't know I have Mumble running).
I would think that Mumble would only attenuate the inputs (applications) for the sink to which it is attached, but that doesn't seem to be the case. I've tried a few other workarounds such as setting PULSE_PROP="media.role=phone" (according to PulseAudio, streams with this property set should never be "ducked" with the module-role-ducking, which is PulseAudio attenuation). Mumble, however, doesn't care what the stream properties are and attenuates everything but itself (one of the parts of the code I actually undertood).
I also attempted to add a third virtual sink to be my final output (where "stream" was my final output before) called "stream_noatt" (no attenuation). I then routed the output of "stream" to "stream_noatt". I figured that since it's further up the chain then perhaps Mumble wouldn't be able to attenudate applications attached to the new sink -- no such luck.
Short of writing a patch, is there any kind of workaround for this behavior?
It's not often that Mumble would encounter a sound setup with anything other than the default system sinks (speakers/headphones). However, because of this behavior it makes it a little annoying for any kind of custom setups. If one were to, say, change Mumble so that it only attenuates applications that reside on the same sink as Mumble, this wouldn't cause problems or confusion for 99.9% of users and setups (please correct me if I'm wrong). Is it an unreasonable request to alter the behavior of Mumble in this way?
Mumble version: 1.2.3-329-g315b5f5-2.2ubuntu1 (default Mumble from Ubuntu Saucy repositories) -- I will try with a PPA version if I can find one.
OK, so I installed 1.2.5-1~ppa1~saucy1 from a PPA and I have some even weirder issues. Mumble ignores the PULSE_SINK environement variables -- no big deal, it can be changed with Pavucontrol. However, if I manually move Mumble's sink, it ends up attenuating itself for some reason. So, I set "stream_spkr" as the default and launched Mumble which caused it to start on "stream_spkr." But when I do this, from the get-go it's attenuating itself...
OK, so what's happening is it's attenuating my module-loopbacks... I guess it's technically an input...
EIDT: I'm an idiot, turned out PulseAudio was pulling my old volume. Had nothing to do with Mumble, just had to bring the volume back to 100%.
I have attached a visual representation of my sound configuration as a reference point. A picture's worth a thousand words as they say.
In this diagram, I have two input programs, 'music' and 'mumble' and one output, 'ffmpeg.' Regardless which input is mapped to which sink, Mumble always attenuates the 'music' program. For my setup, this is undesireable behavior. I had a look at the PulseAudio.cpp file and tried to discern exactly how Mumble figures out which input sources to attenuate. It looks to me like it uses pa_context_get_sink_input_info_list(), and the callback volume_sink_input_list_callback() is called for each item returned. Strictly theoretically speaking, pa_context_get_sink_input_info_list() should return the inputs for the sink to which the pacContext refers, right? The PulseAudio documentation says pa_context_get_sink_input_info_list() "Get[s] the complete sink input list." This should theoretically work. So, perhaps there's a problem with how Mumble determines which sink it's attached to?
I have zero experience with PulseAudio other than what I've gather toying around with it to do my streaming setup. Looking through the code, I'm having a hard time determining exactly where it determines which sink it attaches itself to (the way it acts, it seems to just attach to the default sink, whatever that happens to be). But even so, if it was working as it looks like it's intended to work, then it shouldn't have an effect on any inputs that don't reside on the sink to which Mumble is attached. However, that's clearly not the case. Setting my music program to the "stream" sink (which is higher up the chain) and setting Mumble to the "stream_spkr" sink still results in it attenuating the music program on the "stream" sink.
So, I guess the first step is to be able to determine which sink Mumble attaches itself to upon startup.
Well, after a couple hours of figuring out the code, I have managed to write a patch and submitted a pull request for the changes =)