bluealsa fails to start

[tomg-66]

First off, thank you for this piece of software... I think it's great. There is one issue that we have yet to solve in an acceptable manner. If we put an init script to start bluez-alsa right after the init script to start bluetoothd bluealsa fails to start and we have a device that won't produce audio. I can move the bluez-alsa init script later, and sometimes it works and sometimes it does not. I am assuming this is because something in bluetoothd has not finished initializing. Is there a way that bluez-alsa can query bluetoothd to find out if it is ready to run so that the init script will successfully start bluealsa every time?

[arkq]

Some logs would be nice.... I'm not able to reproduce, aka works for me.

[Pro-pra]

Except that the bluethootd is running, you need to have the device connected (ex. bluetoothctl connect) you device autoconnect on system start?

[tomg-66]

On 2018-02-19 16:39, Pro-pra wrote:

Except that the bluethootd is running, you need to have the device connected (ex. bluetoothctl connect) you device autoconnect on system start?

-- You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub [1], or mute the thread [2].

*

Links:

[1] https://github.com/Arkq/bluez-alsa/issues/81#issuecomment-366827748 [2] https://github.com/notifications/unsubscribe-auth/AhtyGOe-QkNF5gXpLzYeOaWsi37j1H0Jks5tWgZFgaJpZM4RbqIH

Arkq,

Thank you for your reply. What we had was the bluetoothd start with an init script, and tried to start bluez-alsa with an init script after.
Apparently there has to be some time before starting bluez-alsa because the hci device doesn't become ready very fast in bluetoothd. Our solution was to add a udev rule to wait for hci0 to become available then to start bluez-alsa. It would seem that this issue should be closed with a resolved status.

Thanks again,

Tom

[Pro-pra]

was to add a udev rule to wait for hci0 to become available

please post udev rule for wait hci0, it's intresting

[tomg-66]

where the bluez-alsa.sh script is a standard rc script....

KERNEL=="hci0", SUBSYSTEM=="bluetooth", ACTION=="add", RUN+="/etc/init.d//bluez-alsa.sh start"

[nicokaiser]

There might be a "systemd way" to do this, as systemd units can depend on not only services and targets, but als devices. I tried to add something like

After=sys-subsystem-bluetooth-devices-hci0.device

to /lib/systemd/system/bluealsa.service, but somehow this did not work. Maybe someone with more systemd expertise than me can have a look at this?

Also, I added a systemd script that starts a bluealsa-aplay process listening on all devices:

[Unit]
Description=BlueALSA player
Requires=bluealsa.service
After=bluealsa.service
Wants=bluetooth.target sound.target

[Service]
Type=simple
User=root
ExecStartPre=/bin/sleep 2
ExecStart=/usr/bin/bluealsa-aplay --pcm-buffer-time=250000 00:00:00:00:00:00
Restart=on-failure

[Install]
WantedBy=graphical.target

(Also, the sleep 2 feels somewhat ugly but is necessary, as the unit does not seem to wait for bluealsa to be fully available...)

[tomg-66]

Well, this is an imbeded system, and we're also kind of anti-systemd, so the udev method was the best way for us

Thanks,

Tom

On 2018-02-23 16:43, Nico Kaiser wrote:

There might be a "systemd way" to do this, as systemd units can depend on not only services and targets, but als devices. I tried to add something like

After=sys-subsystem-bluetooth-devices-hci0.device

to /lib/systemd/system/bluealsa.service, but somehow this did not work. Maybe someone with more systemd expertise than me can have a look at this?

Also, I added a systemd script that starts a bluealsa-aplay process listening on all devices:

[Unit] Description=BlueALSA player Requires=bluealsa.service After=bluealsa.service Wants=bluetooth.target sound.target

[Service] Type=simple User=root ExecStartPre=/bin/sleep 2 ExecStart=/usr/bin/bluealsa-aplay --pcm-buffer-time=250000 00:00:00:00:00:00 Restart=on-failure

[Install] WantedBy=graphical.target

(Also, the sleep 2 feels somewhat ugly but is necessary, as the unit does not seem to wait for bluealsa to be fully available...)

-- You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub [1], or mute the thread [2].

*

Links:

[1] https://github.com/Arkq/bluez-alsa/issues/81#issuecomment-368171444 [2] https://github.com/notifications/unsubscribe-auth/AhtyGOv5DGYTGJw_diFQCIxyWFlM1cQKks5tX00LgaJpZM4RbqIH

[arkq]

It seems to be resolved. Closing.