[pulseaudio-discuss] [RFC v0 12/15] bluetooth: Update to new BlueZ 5 transport acquire/release API

[Tanu Kaskinen]

On Mon, 2013-01-07 at 17:35 +0100, Mikel Astiz wrote:
> Hi Tanu,
> 
> On Wed, Jan 2, 2013 at 2:04 PM, Tanu Kaskinen <tanuk at iki.fi> wrote:
> > On Wed, 2012-12-19 at 13:58 +0100, Mikel Astiz wrote:
> >> +        if (optional)
> >> +            pa_log_info("Failed optional acquire of transport %s", t->path);
> >
> > An error message should be printed if this is not an optional acquire.
> 
> Given that the caller also prints some traces, I will drop this one entirely.
> 
> > The messages would be more informative if they included the error name
> > and message from err.
> 
> TryAcquire() would typically fail because the audio is down by the
> time TryAcquire() is processed, so I see little benefit in trying to
> log this information, with the exception perhaps of standard D-Bus
> errors. I will discuss in BlueZ's community if TryAcquire() should
> guarantee a specific error in this typical audio-down scenario, so the
> rest of the errors could be logged.

Yep, getting a distinct and documented error for the common case would
be great.

-- 
Tanu