On Tue, 2017-02-07 at 15:51 +0100, Georg Chini wrote:
> On 07.02.2017 15:28, Tanu Kaskinen wrote:
> > On Thu, 2017-02-02 at 11:29 +0100, Georg Chini wrote:
> > > On 31.01.2017 14:51, Tanu Kaskinen wrote:
> > > > On Mon, 2017-01-30 at 17:35 +0100, Georg Chini wrote:
> > > > > Hello,
> > > > >
> > > > > in module-bluez5-device.c and module-bluez4-device.c, latencies for
> > > > > bluetooth are defined as follows:
> > > > >
> > > > > #define FIXED_LATENCY_PLAYBACK_A2DP (25 * PA_USEC_PER_MSEC)
> > > > > #define FIXED_LATENCY_PLAYBACK_SCO (125 * PA_USEC_PER_MSEC)
> > > > > #define FIXED_LATENCY_RECORD_A2DP (25 * PA_USEC_PER_MSEC)
> > > > > #define FIXED_LATENCY_RECORD_SCO (25 * PA_USEC_PER_MSEC)
> > > > >
> > > > > Is the fixed latency for SCO playback a mistake? Both headsets I own
> > > > > report around 28 ms actual latency for the SCO sink, so I cannot
> > > > > understand why the fixed latency is set to 125 ms. Should I send a
> > > > > patch to correct it?
> > > >
> > > > I don't know how Lennart came up with these numbers. How did you get
> > > > the latency report from the headset? AFAIK, the reason why these
> > > > constants exist is that we don't have a way to query the latency with
> > > > bluetooth, and reporting some latency is likely more accurate than
> > > > reporting zero latency.
> > > >
> > >
> > > Hi Tanu,
> > >
> > > the values (plus one write block size) are passed to pulse via
> > > pa_{sink,source}_set_fixed_latency_within_thread() calls.
> > > So pacmd list-sinks shows a fixed latency of 128 ms for the
> > > SCO sink.
> > > When I use module-loopback, the latency of the sink reported
> > > by pa_sink_get_latency() is 28 ms however, similar to what I
> > > get for A2DP.
> > >
> > > Since all other fixed latencies are at 25 ms and this is also set
> > > for SCO recording, I think that the 125 is just a typo.
> > > If you agree, I would send a patch to correct it.
> >
> > I thought that the latency constants would be included in the value
> > that get_latency() reports, but apparently that's only true for A2DP in
> > module-bluez4-device (which I believe you're still using). In module-
> > bluez5-device the fixed latency is added to all reports.
> >
> > I'm fine with changing the constant from 125 ms to 25 ms, it may very
> > well be a typo.
> >
>
> Hi Tanu,
>
> I am using bluez5 and I just tested it again to make sure - at least
> pa_sink_get_latency_within_thread() returns a value of around 28 ms
> and also pacmd list-sinks returns similar values although the fixed
> latency is set to 128 ms. Here the output of pacmd list-sinks:
Oops, I got confused about which one is which. It's the BlueZ 5 module
that adds the fixed latency only for A2DP, except that now that I look
more closely, the A2DP fixed latency constant is used also when in HSP
mode! That looks like a bug.
>
> index: 3
> name: <bluez_sink.0C_E0_E4_31_23_2D.headset_head_unit>
> driver: <module-bluez5-device.c>
> flags: HARDWARE HW_VOLUME_CTRL LATENCY
> state: RUNNING
> suspend cause:
> priority: 9030
> volume: mono: 65536 / 100%
> balance 0,00
> base volume: 65536 / 100%
> volume steps: 16
> muted: no
> current latency: 32,60 ms
> max request: 0 KiB
> max rewind: 0 KiB
> monitor source: 6
> sample spec: s16le 1ch 8000Hz
> channel map: mono
> Mono
> used by: 1
> linked by: 1
> fixed latency: 128,00 ms
>
> I already sent a patch last weekend.
Oh, sorry, I'm a bit behind on email.
--
Tanu
https://www.patreon.com/tanuk
