https://bugs.kde.org/show_bug.cgi?id=415976
--- Comment #1 from Florian <kde-b...@pyoworks.com> --- The situation seems to be a bit more complex than I thought: When I first started my desktop computer today (this is the device I experienced the audio lag), reinstalled KDEConnect with Bluetooth support and tried to reproduce the issue (prior to applying your code), nothing happened: No lag, no buffer increases anymore. However, after booting up my second computer (a laptop also running KDE, KDEConnect and with an enabled bluetooth adapter), the buffer increases started on the desktop computer again when playing audio. Watching the bluetooth systray of KDE on both computers, I noticed that both systems connected or tried to connect each other via bluetooth from time to time. Whenever this happened for the first time while playing audio, the buffer increased like this: I: [bluetooth] module-bluez5-device.c: Changing bluetooth buffer size: Changed from 5120 to 6144 I: [bluetooth] module-bluez5-device.c: Changing bluetooth buffer size: Changed from 6144 to 7168 I: [bluetooth] module-bluez5-device.c: Changing bluetooth buffer size: Changed from 7168 to 8192 Now I am not sure if the KDEConnect tool is responsible for this after all, even though during my tests yesterday it was clearly related. Anyway, I somehow managed to stop the automatic pairing tries of the systems and now the system behaviour regarding audio playback seems to be ok (even with KDEConnect with Bluetooth support running). BUT whenever I manually I press the "Connect" button in the KDE bluetooth systray applet to connect the desktop to the laptop via bluetooth while playing audio, I will immediately reproduce the same 3 buffer increases. Since I usually don't use this function, and somehow was able to stop the automatic connection attempts, the problem seems to be solved for me right now. Meanwhile, a pulseaudio developer told me that the buffer increases happen because there is some delay in the audio, so it is a reaction to the delay, not the cause. And he suggested to me to change the line size_t new_write_block_size = u->a2dp_codec->reduce_encoder_bitrate(u->encoder_info, u->write_link_mtu); to size_t new_write_block_size = 0; in module-bluez5-device.c I tried this out while the systems were still in the state that they tried to connect each other via bluetooth from time to time. So, whenever this happened, the audio would stutter for a short time, before continuing to play normally - until the next connection attemp, when it stuttered again. However, this way the audio stayed in sync with the videogame. In general, I think the original pulseaudio behaviour, to increase the buffer size, seems to be good for the use case of listening music. Because it will only stutter once, then increase the buffer, and be OK for the rest of the time. (but might be out of sync with video or game) The modified behaviour is not perfect because of regular stuttering that might occur, but that might be acceptable for gaming, because at least this way the audio will stay synchronized with the game. I hope this documentation will help others experience similar issues. This might not be a KDEConnect bug, but maybe it could be a general bug in the KDE bluetooth system (after all, just pressing the "Connect" button in the bluetooth systray applet to try to connect a different device will reproduce this) or just a general bluetooth software or hardware problem. -- You are receiving this mail because: You are watching all bug changes.
