That’s exactly what I need. I think Sam would rather do it with python than in C++.
Yes, it took a long time trying all sorts of combinations of settings but in the end it is pretty much down to the conf files. Kodi won’t list any alsa things that don’t appear as a card in /proc/asound, but if you add CARD as an @arg in 20-bluealsa.conf kodi comes up with a device called AML-M8AUDIO.bluealsa which can be selected for playback. Hacky, but the best I could find until/unless Arkq can make the BT device into an alsa ‘card’.
Try this
# BlueALSA integration setup
defaults.bluealsa.service "org.bluealsa"
defaults.bluealsa.profile "a2dp"
defaults.bluealsa.delay 0 ## seems to work best without the default 20000
defaults.bluealsa.battery "yes"
defaults.bluealsa.device "FC:A8:9A:B3:42:4F" ## hard-coded for testing
ctl.bluealsa {
@args [ SRV BAT ]
@args.SRV {
type string
default {
@func refer
name defaults.bluealsa.service
}
}
@args.BAT {
type string
default {
@func refer
name defaults.bluealsa.battery
}
}
type bluealsa
service $SRV
battery $BAT
}
pcm.bluealsa {
@args [ CARD SRV BTDEV PROFILE DELAY ] ## add CARD and rename DEV so it doesn't clash with alsa DEV
@args.CARD {
type string
}
@args.SRV {
type string
default {
@func refer
name defaults.bluealsa.service
}
}
@args.BTDEV {
type string
default {
@func refer
name defaults.bluealsa.device
}
}
@args.PROFILE {
type string
default {
@func refer
name defaults.bluealsa.profile
}
}
@args.DELAY {
type integer
default {
@func refer
name defaults.bluealsa.delay
}
}
# type plug ## doesn't work using a plug device. Kodi audio locks up
# slave.pcm {
type bluealsa
service $SRV
device $BTDEV
profile $PROFILE
delay $DELAY
# }
# hint { ## hint not needed and clutters up kodi settings menu
# show {
# @func refer
# name defaults.namehint.extended
# }
# description "Bluetooth Audio Hub"
# }
}
The steps I’ve taken is to :
Disable the loopback module in /etc/modules (which was only needed for the pipe)
Copied the file you’ve posted and saved as: /usr/share/alsa/alsa.conf.d/20-bluealsa.conf
Changed the BT mac address in that file to my BT mac address
Restarted the Vero.
After connecting my bluetooth via bluetoothctl, I restart Kodi and I see the bluealsa device is available now in settings/system/audio/audio output device, but I get no audio…
Do I need anything in ~/.asoundrc ?
Anything I’m missing?
I haven’t figured out how to package it, but I think all you need to do is change bluealsa-pcm.c bluealsa_set_hw_constraint() like this:
if ((err = snd_pcm_ioplug_set_param_minmax(io, SND_PCM_IOPLUG_HW_PERIODS,
2, 2048)) < 0)
return err;
/* In order to prevent audio tearing and minimize CPU utilization, we're
* going to setup buffer size constraints. These limits are derived from
* the transport sampling rate and the number of channels, so the buffer
* "time" size will be constant. The minimal period size and buffer size
* are respectively 10 ms and 200 ms. Upper limits are not constraint. */
unsigned int min_p = pcm->ba_pcm.sampling * 10 / 1000 * pcm->ba_pcm.channels * 2;
unsigned int min_b = pcm->ba_pcm.sampling * 170 / 1000 * pcm->ba_pcm.channels * 2;
Not sure which of the two changes above (or both) are necessary. YMMV.
There’s another patch for bluealsa-aplay but Arkq has already pulled that in.
No joy Graham, I’ve tried with both changes, and with each one individually, but the audio continues to just come out of the HDMI no matter what I set the output to in the Kodi settings.
Thats cool buddy, I’ll stick with my hacky pipe method for the time being.
Just to note I did try without all the extra codecs, and the result was the same.
Let me know if there’s anything else to test/try if need be, no doubt you’ll get there in the end.
@grahamh quick question mate, when you installed bluealsa does it automatically run at startup (via systemd) ?
If so did u have to do anything to make this happen?
I was only able to achieve this by making my own bluealsa.system file and installing it manually to ‘/etc/system/systemd’
This seemed strange, should this step be necessary?
Did a bit of testing and tried it with my other bluetooth headphones…the result was the same, audio just continues through the HDMI, but this time the sample rate is the same as yours, 48000, so I guess thats not the underlying issue here.
On your Vero are u running the 3.14 kernel or the newer one?
iirc bluealsa comes with a unit file for systemd, but it’s ‘static’ so you have to run systemctl start. Yes, that is a bit strange. Someone has posted a unit file for bluealsa-aplay which requires bluealsa and does start automatically so it starts both. If you are not interested in bluealsa-aplay then hack the static unit file to add an Install section, as you have done.
I am running 4.9 and haven’t tried this on 3.14 or on Pi yet. All I’ve got to test is a JBL Flip 3 (working) and other OSMC devices running bluealsa (yet to try). Maybe the car
Interesting that the main difference is the kernel version, Im still running 3.14 as 1080i and Live TV isn’t working yet, although Sam has said it will be fixed for the next update so Ill give this another try again when that fix is available, so I can upgrade without feeling the wrath of the other half.
Do u still have to restart Kodi after connecting via bluetoothctl?
The fact it’s working on your JBL Flip is the most important thing though.
Yes, you have to restart kodi to get it to scan audio devices. I’m looking at how it recognises USB soundcards when you plug them in for a steer on how to avoid that.
I’ll try that one with all the bells and whistles later.
And I’ve no note about where I got this from:
osmc@vero4kp2:/etc/dbus-1$ cat ./system.d/bluealsa.conf
<!-- This configuration file specifies the required security policies
for BlueALSA core daemon to work. -->
<!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"
"http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
<busconfig>
<!-- ../system.conf have denied everything, so we just punch some holes -->
<policy user="root">
<allow own_prefix="org.bluealsa"/>
<allow send_destination="org.bluealsa"/>
</policy>
<policy group="audio">
<allow send_destination="org.bluealsa"/>
</policy>
</busconfig>
There’s nothing in /usr/share/dbus-1 - only org.bluez.service.
Aha! Just checked - what I did was install on Raspbian first from their repo then copied the files from Raspbian to OSMC and made some adjustments because Raspbian is on 1.4.0 and Arkq’s git is on 2.1 which uses a service rather than an interface (whatever than means).
So let’s try with borine’s conf files. He seems to know what he’s talking about.
