On 2019-12-09 15:53, Hyperion wrote:
09.12.2019, 12:47, "Andrey Semashev" <andrey.semashev@xxxxxxxxx>:
On 2019-12-09 14:39, Pali Rohár wrote:
On Monday 09 December 2019 14:32:52 Andrey Semashev wrote:
I have another piece of feedback to provide. Sometimes I experience audio
dropouts. Sometimes in both left and right headphones, sometimes just one.
In particular, I noticed this happen when I have a Bluetooth-connected
DualShock 4 gamepad connected and playing games, but it also happens without
it, although less often.
I assume this is caused by Bluetooth bandwidth limitation. Note that EOZ Air
are "truly wireless" (i.e. the two headphones connect wirelessly), and I
have multiple WiFi networks available (one access point in the same room as
the Bluetooth transmitter, a few others behind walls). I expect 2.4 GHz
radio to be rather crowded. The gamepad and the headphones are in the same
room as the Bluetooth transmitter, in clear direct visibility, so it can't
get better than that.
Yes, 2.4 GHz is shared by both Bluetooth and WiFi, so it may be a
problem.
I can see Pali's patches offer reduce_encoder_bitrate API that is supposed
to mitigate this problem, but both SBC XQ profiles don't allow bitrate
reduction.
Yes, SBC XQ is there the highest available quality profile of SBC.
I think, SBC XQ desperately needs to support bitrate reduction,
No, this is main reason for usage of SBC XQ it is high quality codec.
SBC XQ needs high bitrate by its definition.
as the codec with the highest bitrate out of all. Users might actually have
reduced experience due to audio dropouts compared to the previously
supported SBC HQ.
If you cannot use high bitrate codecs, then do not use high bitrate
codecs. There are other profiles of SBC which lower bitpool value and
therefore lower bitrate. E.g. SBC MQ or SBC LQ (medium and low quality).
Or you can use SBC in automatic mode where bitrate is automatically
decreased.
As a user, I don't know whether I can use SBC XQ. I don't know whether
its bitrate will fit in my radio conditions. If my device happens to
support SBC XQ, that is the codec that will get picked upon connection.
Please, correct me if I'm wrong, but I don't see a way to influence that.
SBC XQ is high quality and high bitrate, true, but PA should adapt to
the actual use conditions. More so if it actually has the means to do
so. If PA detects that SBC XQ does not fit in BT bandwidth, it should
gradually drop quality.
Please take a look at the many discussions, experiments, specifications analysis and calculations about
SBC XQ, before posting this kind of complaint. You make devs waste a lot of time at this point of implementation.
Can you point me to these discussions?
Also, I'm providing feedback based on the actual usage experience, which
is something you asked for. The devs can disregard it if they choose so,
I just don't think this would be for the benefit of PA user experience.
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
