Bug 90490

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.

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.