On Sat, 2019-10-26 at 14:54 +0200, Pali Rohár wrote: > On Saturday 26 October 2019 15:39:51 Tanu Kaskinen wrote: > > On Sat, 2019-10-19 at 18:42 +0200, Pali Rohár wrote: > > > On Saturday 19 October 2019 19:27:19 Tanu Kaskinen wrote: > > > > On Sat, 2019-10-19 at 18:16 +0200, Pali Rohár wrote: > > > > > Automatic mode is also main objection against usage of SBC codec (it > > > > > does not specify, say or enforce specific bitrate or quality; it can be > > > > > anything) and also reason why there are vendor codecs like aptX. > > > > > Defining SBC LQ, MQ, HQ or XQ just allows to compare it with other > > > > > codecs and guarantee same settings and quality across all devices. > > > > > > > > Doesn't the automatic mode have the benefit that it automatically > > > > adapts to bad radio conditions so that users get the best quality > > > > possible without needing to fiddle with any options in case the initial > > > > bitrate is too high? So it's not entirely pointless. > > > > > > Yes, but it make sense only for lower bitpool values. Higher bitpool > > > increase size of SBC frames and with larger SBC frames there would be > > > lot of wasted space in bluetooth packets as pulseaudio pulseaudio does > > > not support SBC fragmentation. There are only some higher bitpool values > > > which make sense to use. > > > > > > Plus pulseaudio's implementation of (current) automatic mode only > > > decrease bitpool. It never increase it. > > > > > > So yes, it is not pointless, but in current state not very useful for > > > higher bitpool values. > > > > I'm not sure I understand. Why do we care about wasted space in > > bluetooth packets? Do you mean that there are only a few bluetooth > > packet sizes, and decreasing the bitpool doesn't help if the bluetooth > > packet size stays the same? > > Yes. For established connection, bluetooth packet size is fixed. SBC > packet size depends on SBC bitpool (and other) parameters. And because > pulseaudio does not support generating fragmented SBC packets, it can > only fill those SBC frames which fits into bluetooth packet size. If the bluetooth packet size is fixed, doesn't that mean that the bitpool reducing feature is completely useless, since reducing bitpool never reduces the bandwidth requirements? Reducing the bandwidth would require restarting the stream. How is the bluetooth packet size decided? Does the first RTP packet that we write to the stream socket determine the bluetooth packet size? -- Tanu https://www.patreon.com/tanuk https://liberapay.com/tanuk _______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
