[pulseaudio-discuss] [PATCHv2 55/60] bluetooth: Process sink messages for BlueZ 5 cards

[João Paulo Rechi Vita]

On Sat, Sep 14, 2013 at 2:45 AM, Tanu Kaskinen
<tanu.kaskinen at linux.intel.com> wrote:
> On Fri, 2013-09-13 at 20:21 -0300, João Paulo Rechi Vita wrote:
>> On Mon, Aug 19, 2013 at 6:05 AM, Tanu Kaskinen
>> <tanu.kaskinen at linux.intel.com> wrote:
>> > On Tue, 2013-08-13 at 01:54 -0300, jprvita at gmail.com wrote:
>> >> From: João Paulo Rechi Vita <jprvita at openbossa.org>
>> >>
>> >> ---
>> >>  src/modules/bluetooth/module-bluez5-device.c | 81 ++++++++++++++++++++++++++++
>> >>  1 file changed, 81 insertions(+)
>> >
>> > Apparently you did no changes, despite my feedback:
>> > http://lists.freedesktop.org/archives/pulseaudio-discuss/2013-July/018049.html
>> >
>>
>> I don't have a deep knowledge of how the sink latency should be
>> calculated and reported. My understanding of this is that
>> FIXED_LATENCY_PLAYBACK_A2DP is synthesizing the over-the-air A2DP
>> latency (which can be calculated with the current specification of
>> AVDTP), and then we set a fixed latency for the sink in
>> a2dp_set_bitpool adding up this FIXED_LATENCY_PLAYBACK_A2DP and the
>> time the whole data buffer takes. If my assumptions are right, then I
>> think we should keep using thread_info.fixed_latency in
>> PA_SINK_MESSAGE_GET_LATENCY. What are your thoughts about it?
>
> The latency behind the the socket interface fluctuates as the headset
> consumes data and as we write more data to the socket. There is some
> lower and upper bound for the latency. The upper bound is reached when
> all buffers are full. We have no idea about what the lower bound is, but
> that's not so important.
>
> We don't have an interface for querying how much there is room in the
> buffer behind the socket, so we use the system clock to estimate the
> fill level. If we write a block exactly at the moment when there's room
> for one block, according to the system clock, then that is the moment
> when all buffers should be full. This is the moment when the real
> latency should equal the fixed_latency field of the sink.
>
> So, fixed_latency represents the maximum latency. Whatever we return in
> PA_SINK_MESSAGE_GET_LATENCY, it shouldn't be larger than fixed_latency.
> What should we return then? We should return
>
>     fixed_latency - pa_bytes_to_usec(u->write_block_size) + wi - ri
>
> which equals
>
>     FIXED_LATENCY_PLAYBACK_A2DP + wi - ri
>
> I hope I was able to convince you that it's wrong to use
>
>     fixed_latency + wi - ri
>
> as the reported latency like your patch does. I didn't really explain
> why I think "FIXED_LATENCY_PLAYBACK_A2DP + wi - ri" would be the correct
> replacement. If you want me to explain that, I can try, but it's not
> easy to do (otherwise I would have explained it already in this mail).
>

All right, after having a better look at the meaning of fixed_latency
I agree with you. I'll be sending out a v4 soon.

-- 
João Paulo Rechi Vita
http://about.me/jprvita