bluez-alsa: No such device

I disabled the default audio device via the BIOS and fully deleted pulseaudio from the system, compile and install from the latest sources bluez-alsa with alsa-lib 1.1.2.

Then start bluealsa and bluetoothctl 5.40:

power on
scan on
agent on
default-agent
pair 00:19:7F:98:XX:XX
connect 00:19:7F:98:XX:XX
[CHG] Device 00:19:7F:98:XX:XX Connected: yes
Connection successful
[9xxPlantronics]#

But can not set bluealsa as a default audio device. For this, created the file /etc/alsa.conf as below:

pcm.!default {
   type plug
   slave {
       pcm {
           type bluealsa
           device 00:19:7F:98:XX:XX
           profile "a2dp"
       }
   }
   hint {
       show on
       description "BT Headset"
   }
}
ctl.!default {
  type bluealsa
}

And the ~/.asoundrc as below:

defaults.bluealsa.interface "hci0"
defaults.bluealsa.device "00:19:7F:98:XX:XX"
defaults.bluealsa.profile "a2dp"

Then restart bluealsa.

# cat /proc/asound/cards 
--- no soundcards ---

The command # aplay -D bluealsa:HCI=hci0,DEV=00:19:7F:98:XX:XX,PROFILE=a2dp test.wav is finished with error:

ALSA lib ../../../git/src/asound/bluealsa-pcm.c:707:(_snd_pcm_bluealsa_open) Couldn't get BlueALSA transport: No such device
aplay: main:786: audio open error: No such device

Output from bluealsa:

bluealsa: Unsupported AT command: +BRSF=24
bluealsa: Unsupported AT command: +CIND=?

What can I do wrong?

If use pulseaudio instead of bluealsa, BT headset works fine.

About this issue

Original URL
State: closed
Created 8 years ago
Comments: 34 (14 by maintainers)

Commits related to this issue

Hot-start for read-only SCO Fixes #22 — committed to arkq/bluez-alsa by arkq 7 years ago

Most upvoted comments

Hi,

Fist of all make sure you are using current master snapshot of bluez-alsa. Compile it with the --enable-debug option (during configuration). Then, start bluealsa server manually, as follows:

./src/bluealsa --disable-hfp

If it complains, about permissions, create /run/bluealsa directory and chmod it to you. Also, make sure, that pulseaudio and other instance of bluealsa (e.g. started by the init.d) is not running.

Then, connect Bluetooth device (e.g. using bluetoothctl). The log from the bluealsa should be as follows (or very similar):

bluealsa: ../../src/ctl.c:464: Starting controller loop
bluealsa: ../../src/bluez.c:688: Registering endpoint: 0000110A-0000-1000-8000-00805F9B34FB: /MediaEndpoint/A2DP_MPEG24_Source
bluealsa: ../../src/bluez.c:688: Registering endpoint: 0000110A-0000-1000-8000-00805F9B34FB: /MediaEndpoint/A2DPSource
bluealsa: ../../src/bluez.c:688: Registering endpoint: 0000110B-0000-1000-8000-00805F9B34FB: /MediaEndpoint/A2DP_MPEG24_Sink
bluealsa: ../../src/bluez.c:688: Registering endpoint: 0000110B-0000-1000-8000-00805F9B34FB: /MediaEndpoint/A2DPSink
bluealsa: ../../src/bluez.c:924: Registering profile: 00001108-0000-1000-8000-00805F9B34FB: /Profile/HSPHeadset
bluealsa: ../../src/bluez.c:924: Registering profile: 00001112-0000-1000-8000-00805F9B34FB: /Profile/HSPAudioGateway
bluealsa: ../../src/main.c:217: Starting main dispatching loop
bluealsa: ../../src/bluez.c:846: Profile method call: org.bluez.Profile1.NewConnection()
bluealsa: ../../src/transport.c:593: State transition: 0 -> 2
bluealsa: ../../src/transport.c:97: Created new IO thread: HSP Audio Gateway
bluealsa: ../../src/bluez.c:785: HSP Audio Gateway configured for device 1C:48:F9:9D:81:5C
bluealsa: ../../src/transport.c:593: State transition: 0 -> 2
bluealsa: ../../src/io.c:1223: Starting IO loop: HSP Audio Gateway
bluealsa: ../../src/io.c:1074: Starting RFCOMM loop: HSP Audio Gateway
bluealsa: ../../src/transport.c:97: Created new IO thread: HSP Audio Gateway
bluealsa: ../../src/io.c:1134: AT command: +VGS=09
bluealsa: ../../src/io.c:1134: AT command: +XAPL=0000-0000-0100,7
bluealsa: ../../src/io.c:1134: AT command: +IPHONEACCEV=2,1,6,2,0
bluealsa: ../../src/bluez.c:493: Endpoint method call: org.bluez.MediaEndpoint1.SelectConfiguration()
bluealsa: ../../src/bluez.c:493: Endpoint method call: org.bluez.MediaEndpoint1.SetConfiguration()
bluealsa: ../../src/bluez.c:427: A2DP Source (AAC) configured for device 1C:48:F9:9D:81:5C
bluealsa: ../../src/bluez.c:429: Configuration: channels: 2, sampling: 44100
bluealsa: ../../src/transport.c:593: State transition: 0 -> 0

The most important line is (if your device does not support AAC, or bluealsa is compiled without AAC supper, you might see SBC instead):

bluealsa: ../../src/bluez.c:427: A2DP Source (AAC) configured for device 1C:48:F9:9D:81:5C

If the output is somehow “strange”, please post it here.

Next, make sure, that the .asoundrc file looks like this:

pcm.!default {
      type plug
      slave.pcm {
              type bluealsa
              device "00:19:7F:98:XX:XX"
              profile "a2dp"
      }
      hint {
              show on
              description "BT Headset"
      }
}

Then, try to play something using aplay (e.g. aplay test.wav). If nothing happens, please send the logs from the bluealsa (from the beginning) and from the aplay.

When the a2dp profile will work, we might try to check the SCO then.

arkq on Jan 9, 2017

It took me a while, but I might know what’s going on. I’ve pushed one debug line to the sco-hotstart branch. Please, check if this line is printed (“FIFO not connected yet”) when using arecord only. If yes, then remove the O_NONBLOCK flag from the open call from this line and remove this one. Then try again. (After this changes, bluealsa might be not useable for A2DP recoding, but it will reveal the problem).

arkq on Feb 2, 2017

Check if code from the sco-hotstart branch resolves this issue.

arkq on Feb 1, 2017

Lately I’m rather busy, so I’ve got no time to tinker around bluealsa. But your problem might be kernel or bluez related. You can try to check two things. First, after connecting to the capture stream of the SCO, check if the hcitop (included with this project) shows incoming data (RX/s). If there is none, you might check with tcpdump and see if the dump file is “big” after some recording. Because, if the IO thread hangs on the poll function, it seems that there is no incoming data and this is beyond bluealsa control. My suggestion is to try to use your headset with other PC (other hardware) or other Linux version.

arkq on Jan 23, 2017

Ad. 1 I will check this, but not until the weekend.

Ad. 2 Any info I’ve found on the net, is that this earpiece supports: Headset v 1.1 (HSP), Hands-free v. 1.5 (HFP). And this is consistent with the bluetooth.dump you’ve provided. There is no AVDTP communication. So I guess, that A2DP is not supported.

arkq on Jan 12, 2017

OK, so it seems there is a progress 😃 that’s great!

SCO playback - checked.

SCO recording - It’s sad that it’s not working… It would require some debugging, however it might be hard to do it on a distance. If I put my hands on a device with a similar problem, I’ll try to fix it. But for now I have to put in on hold.

A2DP playback - It looks like a deadlock. Try to use: LIBASOUND_THREAD_SAFE=0 aplay -D bluealsa piano2.wav. However, I’m not able to reproduce this deadlock with aplay… I will have to look at this a little bit longer.

A2DP recording - not supported. A2DP profile is a one-way transport. If you’re connecting headset, it won’t be possible to capture stream from the build-in microphone. You have to connect a device with A2DP playback capabilities (e.g. smartphone), then it’ll be possible to record with A2DP profile. In order to check what “action” is possible with which profile, issue: amixer -D bluealsa. In my case it is:

Simple mixer control 'Jabra MOVE v2.3.0 - A2DP',0
  Capabilities: pvolume pswitch
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 127
  Mono:
  Front Left: Playback 127 [100%] [on]
  Front Right: Playback 127 [100%] [on]
Simple mixer control 'Jabra MOVE v2.3.0 - SCO',0
  Capabilities: pvolume pvolume-joined cvolume cvolume-joined pswitch pswitch-joined cswitch cswitch-joined
  Playback channels: Mono
  Capture channels: Mono
  Limits: Playback 0 - 15 Capture 0 - 15
  Mono: Playback 10 [67%] [on] Capture 15 [100%] [on]
Simple mixer control 'Jabra MOVE v2.3.0 | Battery',0
  Capabilities: pvolume pvolume-joined
  Playback channels: Mono
  Limits: Playback 0 - 9
  Mono: Playback 6 [67%]

With A2DP it is possible only to playback, with SCO it is possible to capture and playback. And there is a special control, which shows battery level. It is under the “playback” section, though.

I will have some spare time during this weekend (I suppose), so this issue has to wait until then.

arkq on Jan 11, 2017

With JABRA it should work without any troubles - at lest the logs say so. Unfortunately, you are using wrong MAC address when trying to connect.

# bluealsa
A2DP Source (SBC) configured for device 1C:48:F9:40:03:FB
....
# aplay
Getting transport for 00:19:7F:98:FD:29 type 1

Change device in your .asoundrc file to “1C:48:F9:40:03:FB” and it should work.

Could you provide bluetooth dump from the “not working” device (9xxPlantronics)? Also, could you try to use SCO profile with JABRA (recording and playing) and let me know if it works?

arkq on Jan 11, 2017

OK, so from the logs I can see, that the A2DP profile is not connected. You can try to issue connect command once more and see if the “important” line (A2DP Source (XXX) configured for device) will show up. Without this line, device is not available (from the ALSA point of view). Sometimes profile is not connected - due to signal loss, or other strange “Bluetooth” reasons.

However the Audio Gateway profile is connected, so you can try to use this one. Change “a2dp” profile to “sco” in the .asoundrc and try to play. The quality will be very poor (sampling 8kHz), though. But, there is a possibility that this will not work either. However it is out of the BlueALSA scope. Encoding and data transfer is performed entirely by the Bluetooth kernel module.

In order to debug this problem even further you can dump Bluetooth transfer from the HCI device. See the EDIT of this comment: https://github.com/Arkq/bluez-alsa/issues/7#issuecomment-259513389 You can read the whole comment section of this issue, because it might be somehow related to your problem.

arkq on Jan 10, 2017

I’ve played around with the bluez-alsa quite a bit, and was able to get it to work. I didn’t write the code, ‘arkq’ did so he’d know better than me. I do see a few issues with your current setup.

I recommend using only /etc/asoundrc or ~/.asoundrc for alsa configuration.
alsa 1.1.2 has a deadlock bug in it so if you can downgrade to 1.1.1 you’ll know it isn’t failing because of that issue.
I don’t think your alsa.conf file is necessary because bluez-alsa creates the 20-bluealsa.conf file places it in the /usr/share/alsa/alsa.conf.d/ directory when you use the command ‘sudo make install’
If you decide to keep ‘your’ alsa.conf then there are a few things that need to be corrected in it. a. Add the interface parameter. It is required by the bluealsa type/code etc. b. Add the bluetooth mac address of the destination device (i.e. headset) pcm { type bluealsa –> interface “hci0” // Place your hciX that corresponds to the bluetooth device etc. –> device 00:19:7F:98:XX:XX // Place the MAC of the BT headset. profile “a2dp”

ctl.!default { type bluealsa –> interface “hci0” // Place your hciX etc. }

If you keep ‘your’ alsa.conf then ~/.asoundrc isn’t necessary. If you do ‘make install’ in the bluez-alsa directory, then you should use ~/.asoundrc. Again, the MAC addr should correspond to the destination device (i.e. your bluetooth headset).

Again, I’m not the author of this code and thus I may have made an error or two. Hopefully this helps.

erikly01 on Dec 28, 2016