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.

Regards
             Georg

_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Reply via email to