Unable to find definition 'defaults.bluealsa.interface'

[memeplex]

I've followed the instructions in the readme. After connecting to my bluetooth device and running sudo bluealsa I'm unable to make aplay work:

Without sudo:

(ins)carlos@carlos ~$ aplay -D bluealsa test.wav 
ALSA lib bluealsa-pcm.c:701:(_snd_pcm_bluealsa_open) BlueALSA connection failed: Permission denied
aplay: main:788: audio open error: Permission denied

With sudo:

(ins)carlos@carlos ~$ sudo aplay -D bluealsa test.wav 
ALSA lib confmisc.c:1281:(snd_func_refer) Unable to find definition 'defaults.bluealsa.interface'
ALSA lib conf.c:4528:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:4996:(snd_config_expand) Args evaluate error: No such file or directory
ALSA lib pcm.c:2495:(snd_pcm_open_noupdate) Unknown PCM bluealsa
aplay: main:788: audio open error: No such file or directory

My .asoundrc:

(ins)carlos@carlos ~$ cat ~/.asoundrc 
defaults.bluealsa.interface "hci0"
defaults.bluealsa.device "E0:D1:E6:0B:AF:F1"
defaults.bluealsa.profile "a2dp"

My device:

(ins)carlos@carlos ~$ hciconfig 
hci0:	Type: Primary  Bus: USB
	BD Address: 88:53:2E:39:25:B4  ACL MTU: 310:10  SCO MTU: 64:8
	UP RUNNING 
	RX bytes:24330708 acl:1250 sco:473901 events:17770 errors:0
	TX bytes:32573341 acl:30287 sco:473433 commands:768 errors:0

(ins)[MINIJAMBOX by Jawbone]# connect E0:D1:E6:0B:AF:F1
Attempting to connect to E0:D1:E6:0B:AF:F1
Connection successful

[arkq]

Hi

Did you make make install? If yes, please check if the 20-bluealsa.conf file is installed in the ALSA shared configuration directory. On my system it is /usr/share/alsa/alsa.conf.d/. If you're using some "non-standard" Linux distribution, please let me know which one it is.

Optionally you can use "static" configuration in you .asoundrc file, as follows:

pcm.minijambox {
	type plug
	slave.pcm {
		type bluealsa
		device "E0:D1:E6:0B:AF:F1"
		profile "a2dp"
	}
	hint {
		show on
		description "MINIJAMBOX by Jawbone"
	}
}

then connect your device and run:

aplay -D minijambox test.wav 

[memeplex]

Still no luck.

The shared config is there, nevertheless I tried the .asoundrc configuration you suggested but I get:

~$ aplay -D minijambox test.wav
ALSA lib bluealsa-pcm.c:701:(_snd_pcm_bluealsa_open) BlueALSA connection failed: Permission denied
aplay: main:788: audio open error: Permission denied

~$ sudo aplay -D minijambox test.wav
ALSA lib pcm.c:2495:(snd_pcm_open_noupdate) Unknown PCM minijambox
aplay: main:788: audio open error: No such file or directory

I'm installing this as an Arch package, it's a pretty standard build script. I've also cloned and make-installed it myself but to no avail.

[arkq]

Abut the permission. Make sure that the directory shown below exists, and has right permissions and group:

$ ls -l /run/
drwxrwx---  2 root      audio     60 Feb  5 14:36 bluealsa

Then, make sure that your user is added to the audio group. That should fix the permission problem.

Using sudo should work as well, but you have to create .arecord file in your root's home directory (I guess).

[memeplex]

Right. I've added myself to audio. Now I see some progress but yet hear no sound output. Besides the configuration you suggested I've added a ctl entry to .asoundrc:

ctl.minijambox {
    type bluealsa
    interface "hci0"
}

This screenshot shows the state of the mixer, bluealsa output, bluetoothctl repl and aplay output:

Everything is frozen at that point, I can't even sigint aplay.

[arkq]

This freeze might be caused by the alsalib bug which can be "fixed" by exporting LIBASOUND_THREAD_SAFE=0. Try to use:

$ LIBASOUND_THREAD_SAFE=0 aplay -D minijambox test.wav

or add export LIBASOUND_THREAD_SAFE=0 to your .profile or .bashrc file.

EDIT:
I can see, that your device supports AAC encoding. Please, read "Troubleshooting" section from the README file. If you experience sound glitching, you might try run bluealsa server with the following options:

$ bluealsa --a2dp-force-audio-cd --aac-vbr-mode=2

[memeplex]

Yes, beautiful, thank you!

add export LIBASOUND_THREAD_SAFE=0 to your .profile or .bashrc file.

May this have an undesired effect when set at the global level?

If you experience sound glitching

It seems to sound well but I took note of your advice just in case.

OT: how do you manage you "bluetooth session"? Say I want to channel my audio through bluetooth for a couple of hours, then wire everything again. Some apps doesn't even have a device argument (for example, sopotify AFAIK). And in any case you will have to create launchers or alias for each app in order to set the device and put them in "bluetooth mode". So, do you temporarily change the default alsa device?

[infirit]

Have a new BT speaker so been playing with this some more. I am seeing the same thing with a non static config, only a static config per #26 (comment) works.

The mixer shows up with amixer -D bluealsa but trying to play something with aplay -D bluealsa fails with "audio open error: No such file or directory"

ffs, now it works but before it didn't not sure why 😢.

[arkq]

May this have an undesired effect when set at the global level?

It's hard to tell. I think, that right now there will be no undesirable effects, but in the future there might be - ppl will start to make programs which will require ALSA to be thread safe. However, this bug will be fixed by that time - I hope so.

how do you manage you "bluetooth session"?

I do not. ALSA is not made to be user-friendly. That's why PulseAudio has emerged (I think). When, I'm using bluealsa, I'm also using other audio devices as well, and I'm doing it simultaneously. I choose which device should be used for every application I start (I'm not using applications which do not provide options for selecting audio device).

But to answer your question more adequately, I have to say, that it might be impossible (or at least very tricky) to get the Windows™ experience out of bluealsa - aka audio device auto-selection depending on whether BT speaker/headset is connected or not. The only possible/reasonable way, which comes to my mind, is indeed the change of the default section in the .asoundrc. You could write some scripts for such actions in order to make it more automatic.

PS.
Right now it is not possible to connect more than one application to particular bluetooth device using bluealsa. If you try to listen to spotify, and in the meantime you will want to listen to some youtube video, you will get "device busy" error. So using bluealsa as a default audio for a desktop environment might not be the best idea. Of course you can do it, but you have to know this limitation.

[arkq]

@infirit, I'll try to add some more meaningful debug error messages and in the meantime I'll try to setup bluealse from scratches on my host as well - it's easy to miss something trivial if one is using development environment all the time :D.

[infirit]

@arkq Cool. After rebuilding with debug flag it started working so may have been user error 😉. Not sure what changed but I'll try to reproduce and report back.

[memeplex]

Ok, regarding the "bluetooth session", and given that automating bluetoothctl is a PITA, I ended up writing a simple shell library to source inside a bash session and then launch bluetooth enabled apps from there:

connect() {
    disconnect
    export LIBASOUND_THREAD_SAFE=0 ALSA_CONFIG_PATH=/tmp/bluetoothrc
    sudo systemctl restart bluetooth
    sudo bluealsa &> /tmp/bluetooth.log &
    sleep 0.5
    echo 'power on' | bluetoothctl &> /dev/null
    bluetoothctl
    local device_id=$(echo quit | bluetoothctl | \
                      sed -nr 's/.*Device ([^ ]+).*/\1/p')
    cat > "$ALSA_CONFIG_PATH" <<EOF
pcm.!default {
    type plug
    slave.pcm {
        type bluealsa
        interface "hci0"
        device $device_id
        profile "a2dp"
    }
}
ctl.!default {
    type bluealsa
    interface "hci0"
}
EOF
}

disconnect() {
    rm -f "$ALSA_CONFIG_PATH"
    unset LIBASOUND_THREAD_SAFE ALSA_CONFIG_PATH
    sudo pkill bluealsa
    sudo systemctl stop bluetooth
}