Created attachment 92307 [details] verbose pulseaudio log [After conferring with some bluez developers via irc, it was suggested this may be an issue with pulseaudio.] Connecting the bluetooth headset and playing sound works fine. However, once I start typing on the (non-bluetooth) keyboard, audio stops. It seems to be dependent on the speed of keypresses: less than about 1/sec doesn't interrupt audio. This problem is 100% reproducable, regardless what the audio source is (media players, in-game sounds). On irc it was suggested pulseaudio releases the bluetooth sink prematurely.
Created attachment 92308 [details] bluetoothd debug output
I assume the pulseaudio log shows a case where VLC audio stops when it shouldn't. Unfortunately, there's no indication of why VLC is disconnected, it looks like a perfectly normal client-initiated disconnection. The log doesn't contain debug level messages. The reason is probably that even if pulseaudio is configured to log at the debug level, syslog drops them by default. Could you provide another log using the instructions here: https://wiki.ubuntu.com/PulseAudio/Log ?
Created attachment 92521 [details] pulseaudio debug log
10 seconds after creating the VLC stream the stream is corked (paused), and about a second after that the stream is freed. If you didn't pause VLC yourself, then VLC is doing that by itself. PulseAudio never initiates corking of client streams. Corking in itself is not a reason for destroying the stream, though, so why is the stream destroyed? That, too, is most likely initiated by VLC, although PulseAudio could in theory kill the stream for some reason. Is your keyboard wireless? My wild guess is that it interferes with Bluetooth, causing PulseAudio to consume audio slower than expected, and VLC thinks that the audio system is broken and decides to stop playing. Could you try playing something with paplay instead of VLC? paplay doesn't support all file formats, but wav, flac or vorbis should be fine. If it doesn't work properly, post logs again.
The keyboard is wired. No other bluetooth devices are in use. Only a logitec unifying mouse, which I will switch off for the next test. Testing with paplay now.
Created attachment 92524 [details] pulseaudio debug log with paplay
Ok so I did some tests: using another wired keyboard changes nothing. Same effect. However using a wired mouse does fix the problem! So I tested some more: it turns out the problem only occurs when the keyboard is plugged into the "keyboard" usb port while the logitec unifying extention is plugged into the USB port designated for the mouse. If I plug either one into a different USB port the issue disappears. Even just switching the two works! I guess somehow this precise configuration causes the Unifying dongle to send interference? Not sure why it doesn't happen, when the cables are swapped or they're in other USB ports directly next to each other...
How did it go with paplay? Any problems? Did you quit paplay yourself, or did it stop by itself like VLC? If you stopped paplay yourself, then the log doesn't show anything strange happening. Can we close this bug?
(In reply to comment #8) > How did it go with paplay? Any problems? Did you quit paplay yourself, or > did it stop by itself like VLC? > > If you stopped paplay yourself, then the log doesn't show anything strange > happening. Can we close this bug? I quit paplay maybe 10 seconds after the sound stopped. I guess the bug can be closed. Either it's just some weird physical interference going on or the bug is unrelated to pulseaudio. Either way, swapping the usb-ports works for me.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.