[pulseaudio-discuss] [PATCH v2 00/22] Revisiting Bluetooth modules

Arun Raghavan arun.raghavan at collabora.co.uk
Wed Sep 26 21:34:15 PDT 2012


On Wed, 2012-09-26 at 17:42 +0200, Mikel Astiz wrote:
> Hi Arun,
> 
> On Wed, Sep 26, 2012 at 1:57 PM, Arun Raghavan
[...]
> > 18 and 19 are a no-go from me. I'm not okay with dependencies between
> > unrelated modules. As mentioned on IRC a while back, I'd much rather
> > signal an unwillingness to be suspended via sink/source flags.
> >
> > The alternative is we declare suspend-on-idle core, but tbh I think
> > that's messier than just doing the flags.
> 
> I will think of alternative approaches but keep in mind that the
> "unwillingness" is idle-specific, so adding these flags also sounds to
> me like declaring suspend-on-idle core.

The unwillingness is not actually specific to module-suspend-on-idle.
Imagine a hypothetical system policy module that implements something
like wakelocks for audio. Applications explicitly inform the system when
they want a device and when nothing needs it, the module suspends the
device. This would also be an idle suspend, but not made by
module-suspend-on-idle.

While this is completely hypothetical, it's certainly feasible, which is
why I want these sorts of underlying hardware properties to be exposed
by the corresponding PA object.

> >> - Patch 22 is experimental and should not be applied yet.
> >
> > Luiz mentioned the patch for that version is in, so if you could just
> > update the version on the comment (or even just tell me on IRC), I'll
> > update and push that one too.
> 
> Let's discuss this with Luiz but I would rather leave it out. Even
> though the patch is already applied in BlueZ, there has been no
> release yet and chances are that the next release will take some time
> and involve other changes.

Sure, that sounds fine.

Cheers,
Arun



More information about the pulseaudio-discuss mailing list