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
