It reverses the bluetooth mac address from time to time

[satarsa]

Hi

Thanks, it works! But sometimes it does not start, mplayer says: ../../../src/asound/bluealsa-pcm.c:96: Getting transport for B6:96:74:DB:A8:30 profile 1 [AO_ALSA] alsa-lib: ../../../src/asound/bluealsa-pcm.c:613:(_snd_pcm_bluealsa_open) Couldn't get BlueALSA transport: No such device

But my headset's mac is 30:A8:DB:74:96:B6. Thus, it somehow reverses it, I do not understand the pattern.

[arkq]

Hi,

I'm glad, that it works for you.

The "reverse" problem is caused by the bluez library itself, however I'm using this buggy function for debugging purposes only (due to API simplicity). See this: https://www.spinics.net/lists/linux-bluetooth/msg16305.html.

But cutting to the chase. The actual reason, why you can't connect to your bluetooth device (to be more specific, why bluealsa server cannot acquire bluetooth transport) can be found (I hope) in the bluealsa logs. Please start bluealsa in the separate terminal and past here logs from the point where the connection is refused. I kinda guess what might be the problem, but I'd like to be sure.

[satarsa]

Sometimes it runs OK, sometimes not. If it does not, then the log is here:

bluealsa: ../../src/ctl.c:408: Starting controller loop
bluealsa: ../../src/bluez.c:762: Registering profile: 00001112-0000-1000-8000-00805F9B34FB: /Profile/HSPAG
bluealsa: ../../src/bluez.c:632: Registering endpoint: 0000110A-0000-1000-8000-00805F9B34FB: /MediaEndpoint/A2DPSource
bluealsa: ../../src/bluez.c:632: Registering endpoint: 0000110B-0000-1000-8000-00805F9B34FB: /MediaEndpoint/A2DPSink
bluealsa: ../../src/main.c:174: Starting main dispatching loop
bluealsa: ../../src/ctl.c:466: New client accepted: 9
bluealsa: ../../src/ctl.c:469: +-+-
bluealsa: ../../src/ctl.c:469: +-+-
bluealsa: ../../src/ctl.c:440: Client closed connection: 9
bluealsa: ../../src/ctl.c:469: +-+-

[satarsa]

Another problem, the sound is tearing (on Sony SBH52). Should I open another issue for it? Which parameters might I tune to get rid of the tearing?

[satarsa]

Strange

samac tmp # hcitool con
Connections:
        > ACL 30:A8:DB:74:96:B6 handle 12 state 1 lm SLAVE AUTH ENCRYPT

but

samac tmp # bluealsa -i 30:A8:DB:74:96:B6
bluealsa: HCI device not found: 30:A8:DB:74:96:B6

[arkq]

OK, now I see why you cannot "connect" sometimes. It seems, that the device is not connected at all. One clarification here (I will probably put similar explanation in the REDME for others to see). Prior to streaming, the device has to be in the "connected" state. But the connection is not triggered by the ALSA plugin (or by bluealsa server), but it has to be triggered by other software, e.g. bluetoothctl (provided by the bluez) or some user friendly GUI. Currently I'm using bluetoothctl, e.g.

$ bluetoothctl
[bluetooth]# power on
[bluetooth]# connect 12:34:56:78:9A:BC
[DeviceName]#

The bluealsa log has to contain lines like these:

../../src/bluez.c:546: Endpoint method call: org.bluez.MediaEndpoint1.SelectConfiguration()
../../src/bluez.c:546: Endpoint method call: org.bluez.MediaEndpoint1.SetConfiguration()
../../src/transport.c:343: State transition: 0 -> 0
../../src/bluez.c:481: A2DP-SBC Source configured for device 1C:48:F9:9D:81:5C

the last one is the most important, though :) It states, that the media endpoint has been configured, and that the SBC codec will be used for given device (hexs order is not reversed in this case). In the future more codecs (currently I'm trying to incorporate AAC encoding) will be possible (if supported by device one is connecting to, e.g. headset).

the sound is tearing (on Sony SBH52)

Yes, it is some other issue. If the tearing is during first 2-5 seconds, I know about this issue and I will fix it eventually, but not with a hight priority (but you might add a bug report). If the audio is tearing all the time, it is definitely something wrong. In such a case definitely add a bug report with a note, that the audio is tearing all the time and please describe how this tearing sounds like.

bluealsa -i 30:A8:DB:74:96:B6

Here is partially my fault, because of the naming. The HCI device is a Bloetooth interface not a device per se. If you run hciconfig, this program will list all HCI devices available on the host. In most cases it is only one device hci0 (which also has a MAC address). This parameter (-i) should be used to bind to the specified HCI only - in most cases it should not be given, bluealsa will bind to the default HCI, or to the first active one.

[satarsa]

OK, I understand now. After connection through bluetoothctl it works just fine, even the tearing has disappeared completely. That's funny that sometimes it "just works" (but with tearings) and sometimes I have to use bluetoothctl to explicitly connect the devices. Anyway, Arkq, thank you, you've done a great job! Since now I do not need anymore the fat monster pulseaudio.

[satarsa]

I think you may also add to README that mplayer can be run as

mplayer -ao alsa:device=bluealsa file.mp3

(if ~/.asoundrc is set correctly, of course). It took me for a while to figure it out.

[arkq]

I'm glad that everything turns out just fine. The tearing problem is caused partially by me and partially by connected device. The problem with initial tearing, is that device is consuming audio too fast at the beginning or too slow (it gets out of sync). I'm trying to prevent this, but I account only for 10ms speed up (which seems to be too small). I'm afraid of adding more "dead" time, because it will cause unnecessary audio delay (audible while pausing and seeking). Nonetheless, I will try other approach, however it is not a priority for me right now.

Thanks for the tip with mplayer, I will add some exemplary configurations and use cases in the readme. Currently, I'm using (with mpv, which is a fork of mplayer, so it should work with mplayer as well) something like this:

in the mpv config file:

$ cat .config/mpv/mpv.conf
ao=alsa:device=jabra,alsa,

and in the .asoundrc:

$ cat .asoundrc
pcm.jabra {
    type bluealsa
    device "1C:48:F9:9D:81:5C"
    profile "a2dp"
}

so when my headset is connected, mpv will try to use it, otherwise standard alsa device will be used. The only problem I've got is volume. Changing volume in mpv changes default PCM volume, but when the headset is connected, the ctl.bluealsa controller should be used instead...