On Tue, 2018-04-10 at 16:10 +0300, Luiz Augusto von Dentz wrote:
> Just keep in mind the 7.5 msec is specific for USB alternate setting 6
> so I don't think we should hard code it as there are other transports
> like UART and even controllers which don't support alternate setting
> 6.

Sounds like a thing that the kernel should take care of. As I've been
saying, I haven't seen evidence that PulseAudio should be very
concerned about the packet timing.

> Also, like I just responded to Georg, perhaps we should not even be
> sleeping for less than default-fragment-size-msec, well assuming that
> is what PA uses for processing the audio frames.

The bluetooth code ignores default-fragment-size-msec, because
PulseAudio can't configure arbitrary hardware buffer sizes with bluez
like it can with alsa (and even alsa usually ignores that setting,
because it's better to adapt the hardware buffer size to client latency
requests when possible).

-- 
Tanu

https://liberapay.com/tanuk
https://www.patreon.com/tanuk
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Reply via email to