On Sat, 2017-09-02 at 13:31 +0200, Georg Chini wrote:
> On 02.09.2017 13:12, Tanu Kaskinen wrote:
> > On Fri, 2017-09-01 at 16:21 +0200, Georg Chini wrote:
> > > When a phone is connected via bluetooth and switches to HFP, the sinks
> > > and sources will have higher priority than the built-in devices.
> > > Therefore they are chosen as default and module-bluetooth-policy will
> > > incorrectly insert loopback modules that loop the phone back to itself.
> > >
> > > This patch fixes the problem by lowering the priority of devices with
> > > the form factor "phone" so that they are never chosen as default sink
> > > or source unless no other sound device is available.
> > > ---
> > > src/pulsecore/sink.c | 2 ++
> > > 1 file changed, 2 insertions(+)
> > >
> > > diff --git a/src/pulsecore/sink.c b/src/pulsecore/sink.c
> > > index a8b4cd3d..e1bd5a08 100644
> > > --- a/src/pulsecore/sink.c
> > > +++ b/src/pulsecore/sink.c
> > > @@ -3529,6 +3529,8 @@ unsigned pa_device_init_priority(pa_proplist *p) {
> > > priority += 450;
> > > else if (pa_streq(s, "internal"))
> > > priority += 400;
> > > + else if (pa_streq(s, "phone"))
> > > + priority -= 1000;
> > > }
> > >
> > > if ((s = pa_proplist_gets(p, PA_PROP_DEVICE_BUS))) {
> >
> > priority is unsigned, and its value is not guaranteed to be high enough
> > for substracting 1000 from it.
> >
> > Maybe it would make sense to just immediately return 0 if we spot a
> > phone form factor?
> >
>
> I think the priority should still be higher than a null-sink, so it
> would be OK to return something like 1500.
>
> There is also another way to achieve the same thing. We could
> set the priorities in the bluetooth code when the sink/source are
> put and pulseaudio is in the headset role or the device is an a2dp
> source. That would be more general than only checking the form
> factor.
>
> What do you think?
Sounds good.
--
Tanu
https://www.patreon.com/tanuk
