[pulseaudio-discuss] [RFC 0/3] Automatically enable loopback on sources

Luiz Augusto von Dentz luiz.dentz at gmail.com
Tue Jan 24 01:31:46 PST 2012


Hi Frederic,

On Tue, Jan 17, 2012 at 4:32 PM, Dalleau, Frederic
<frederic.dalleau at intel.com> wrote:
> Hi Tanu,
>
> On Mon, Jan 16, 2012 at 8:22 PM, Tanu Kaskinen <tanuk at iki.fi> wrote:
>>
>>
>> Do you think it would be a lot of work to move this logic to a separate
>> module? As discussed before[1], I'd prefer there to be
>> "module-bluetooth-policy" that would take care of choosing profiles
>> automatically etc. Autoloading module-loopback could be the first
>> feature of that module.
>
>
> Doing a separate module has been the first thing I tried. But there are
> several reasons which made me try differently  :
> * I needed finer control by being into module-bluetooth-device than hooks :
> when a sink is being removed it is not possible to remove the sink inputs
> that were previously affected to it because the sink input has started
> moving and this triggers an assertion. I had to unload module-loopback
> before the sink inputs would start moving.
> * I wanted to avoid having loopback enabled for unwanted modules that could
> cause uncontrolled side effects.
> * IIRC Some specific other modules (USB) could benefit of similar behavior.
> * The code isn't too big.
>
> Maybe I'm trying to get complicated in that I'd rather explicitly remove the
> loopback instead of letting it die.
>
> So that's not a big bunch of work to do a module, but I'm open ideas to fix
> the issues encountered before that. It's an RFC after all ;)

Overall Im fine with the changes, but how would we could dynamically
control the auto loading? Im not sure this will always be static which
apparently is what it implicates by being in
module-bluetooth-discover, lets say in some conditions the audio
should not be send back to loopback or loopback is not the default
sink/source.

-- 
Luiz Augusto von Dentz


More information about the pulseaudio-discuss mailing list