Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pulseaudio service starts before Bluetooth service on boot, causing it to timeout #138

Open
LukeMcDonnell opened this issue Aug 11, 2018 · 0 comments

Comments

@LukeMcDonnell
Copy link

Running a Bluetooth only setup on a Raspberry Pi 2 B with hifiberry dac+. Using the latest Stretch image.

When I boot the pi, it seems that the pulseaudio service is starting well before the bluetooth service is ready. This is causing the Pulseaudio service to timeout and no audio from bluetooth:

Aug 11 06:26:46 musicbox pulseaudio[223]: [pulseaudio] main.c: Running in system mode, forcibly disabling SHM mode.

Aug 11 06:26:46 musicbox pulseaudio[245]: [pulseaudio] main.c: OK, so you are running PA in system mode. Please make sure that you actually do want to do that.

Aug 11 06:26:47 musicbox pulseaudio[182]: Starting system PulseAudio Daemon:.

Aug 11 06:26:47 musicbox systemd[1]: Started LSB: Start the PulseAudio sound server.

Aug 11 06:27:11 musicbox pulseaudio[245]: [pulseaudio] bluez5-util.c: GetManagedObjects() failed: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

SSHing in and restarting the Pulseaudio service resolves it and everything works fine, but this isn't a great solution for a headless server.

I've tried adding "bluetooth" to the Required-Start of "/etc/init.d/pulseaudio" (and removing pulseaudio from the bluetooth-agent dependencies) But this just caused both services to start too soon, and both failed.

In the meanwhile, I've added "sleep 120" to /etc/init.d/pulseaudio to delay the start of the service, which works in most cases, but probably isn't the most elegant solution. Hopefully there's a better way to resolve this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant