Pulseaudio has an issue in that module-bluetooth-discover works only if started after the X11 session is up. This issue is prevalent for me with bluetooth headsets in that they only work with hsa profiles with aweful sound and in mono, as a2dp does not load, and trying to load it manually results in an error. There is a workaround that I restated in this post: https://bbs.archlinux.org/viewtopic.php?id=197482 I do not know if this is a new bug, or Gnome specific, as I just discovered it today as I just got my first bluetooth headset. I do have this issue on both my intel based laptop and my amd based desktop though, and the workaround worked for each.
I believe this issue is actually localized to the Gnome-Desktop, perhaps with their changes to gdm and wayland. Either way, I hope that both projects can come to a resolution. https://bugzilla.gnome.org/show_bug.cgi?id=749208
This sounds pretty weird. It shouldn't matter when module-bluetooth-discover is loaded. The available profiles depend on which profiles get connected. Gnome is responsible for connecting the profiles, but I don't know why Gnome would behave differently depending on whether module-bluetooth-discover is loaded in PulseAudio or not. Could you revert your workaround, and attach a PulseAudio log of the failing case? Instructions for getting the log: Put these lines to ~/.config/pulse/daemon.conf (remember to fix the home directory path): log-target = newfile:/home/you/pulse.log log-level = debug log-time = yes Then reboot. There should now be a log file named "pulse.log" in your home directory. There may also be files named "pulse.log.N" (N being a number). Attach the last one of those. For comparison, you could also re-apply your workaround, reboot, and attach again the newest log file.
so funny thing, there is no pulse.log file being output. And yes I got the path right :-p I don't think the daemon.conf file is being read and executed.
Ok I tried for a third time, and there is no log being output. log-target = newfile:/home/britt/pulse.log log-level = debug log-time = yes Likewise I put the above lines in /etc/pulse/daemon.conf at the bottom of the file, and I still had no log file output. This seems weird to me. Perhaps the bug is actually to do with Gnome not executing pulseaudio commands properly as it starts the service? Or perhaps gnome is getting in the way of pulseaudio somehow?
I think the problem is that when pulseaudio is autospawned, one of the command line parameters is --log-target=syslog, which overrides the configuration file. Does it help if you put this line to client.conf: extra-arguments = That is, leave it empty. The default value of that option is "--log-target=syslog", which is not nice in this case.
Created attachment 118365 [details] pulse.log of the described issue I also experience this issue. I run an up-to-date Arch Linux system with GDM 3.16.3, pulseaudio 6.0 and bluez 5.34. I've added this line to /etc/pulse/client.conf: extra-arguments = --log-target=newfile:/home/dor/pulse.log I also added these two lines to /etc/pulse/daemon.conf: log-level = debug log-time = yes Attached is pulse.log, which was generated after a reboot was performed. Let me know if anything else is needed.
Dor, the log shows that there are no profiles connected. Does Gnome show the device as connected?
Created attachment 118369 [details] journalctl snippet I guess the the bug report is missing some information. The issue appears to be that while devices can be discovered, paired and connected, audio doesn't play on the host device at all. Attached is a snippet from journalctl. I tried to include all of the related lines.
Created attachment 118370 [details] pulse.log which includes establishing a connection Attached is pulse.log which includes establishing a connection.
What are you trying to do? The log shows that you connected a phone, not a headset as in the original report. If your problem is not about headsets, I think it's better to open a new bug report.
Sorry, my mistake. You're right, I'm trying to use the PC as an audio sink, not as an audio source. However, for what's it worth, the errors that appear in journalctl appear regardless of setting up the PC as a sink or as a source, since they appear at boot time and before any bluetooth device is connected. Looking up the symptoms online, I'm getting the feeling that the root issue is shared between the two.
In any case your description doesn't sound like the same problem that the original reporter had. The original reporter wasn't able to use a2dp with a headset without a strange workaround, but hsp worked fine. In your case I've seen that using a2dp with a phone works at least for a few seconds, but I don't know what problems (if any) you're having with headsets. Regarding the journal log, I'm not familiar enough with bluetoothd to decipher the error messages. But at least the errors don't entirely prevent a2dp streaming. Your PulseAudio log shows that there's some audio moving for a few seconds. I don't know why the streaming stops after a few seconds - either you stopped playback on the phone yourself, or the phone just decided to stop the streaming for some reason.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/520.
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.