-
Notifications
You must be signed in to change notification settings - Fork 187
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
No such device #22
Comments
When you say "default audio device", are you attempting to black audio from the bluetooth source -> bluez -> bluez-alsa -> sound card? |
No, I'm attempting to play wav file via BT headset with help of bluez-alsa. |
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.
ctl.!default {
Again, I'm not the author of this code and thus I may have made an error or two. Hopefully this helps. |
erikly01, thank you for help! I was forgotten to add the line interface "hci0" to alsa.conf file. However, it does not help. So I deleted all files and left ~/.asoundrc only. If to change a2dp profile to sco, playback begins to work, but only 1 time:
After some seconds, headset disconnected in bluetoothctl. Moreover, can not be connected within several seconds. The system logs in this moment:
Why does it happen? Moreover, why playback does not work with a2dp profile? What device can not be opened? By the way, recording with sco profile also not work. The command arecord -d 3 -D bluealsa test.wav is never finished, test.wav is 44 bytes. Downgrading alsa-lib to 1.1.1 does not help. |
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:
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):
The most important line is (if your device does not support AAC, or bluealsa is compiled without AAC supper, you might see SBC instead):
If the output is somehow "strange", please post it here. Next, make sure, that the .asoundrc file looks like this:
Then, try to play something using aplay (e.g. When the a2dp profile will work, we might try to check the SCO then. |
Hello, Arkq! Thank you for help! Here is my logs: bluetoothctl
bluealsa
aplay
|
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 ( 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: #7 (comment) You can read the whole comment section of this issue, because it might be somehow related to your problem. |
I tried another headset with A2DP profile (Jabra instead of 9xxPlantronics), but get "no such" device anyway. May be some problems with the configuration of the operation system? But with PulseAudio no any problems on the same system. New logs:
Bluetooth dump here. Thank you for help! |
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.
Change 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? |
Sorry, forgot to change the MAC address. The playback works fine with both Jabra and 9xxPlantronics BT headsets on SCO profile. The recording does not work with both Jabra and 9xxPlantronics on SCO profile (the output file is always 44 bytes, the problem like here). May be the deadlock bug with the recording (used alsa-lib 1.1.2)? Some logs. Jabra SCO playback (ok, 9xxPlantronics the same, but have not got A2DP profile detected):
Jabra SCO recording (failed with 44 bytes, 9xxPlantronics the same, but have not got A2DP profile detected):
Jabra A2DP playback (failed):
Jabra A2DP recording (failed):
On the 9xxPlantronics with A2DP profile - recording and playback the error "no such device" (the logs above). Full dump for 9xxPlantronics: here. |
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: 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:
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. |
Good news! An A2DP playback works fine with the LIBASOUND_THREAD_SAFE=0 flag. So it remains to solve the two problems - thread issue on SCO recording and determine the cause of the absence A2DP profile for 9xxPlantronics BT headset.
P.S. I see in bluealsa.4653 file error in io.c (function io_thread_open_pcm_write return an error:
It's strange. Also I do not get an exception. |
Ad. 1 Ad. 2 |
Hello, Arkq! Any good news? I debugged the eternal cycle on the SCO recording (44 bytes output file). See the problem in static void *io_thread(void *arg) function - the poll function never ending. If to add the timeout 10 seconds, it finished after 10 second with logs from arecord as below (string number are different from git, because some debug logs added):
What device can not be found? May be some additional logs is required? If remove reading condition in io_thread, get the error: "ALSA lib ../../../src/asound/bluealsa-pcm.c:280:(io_thread) PCM FIFO write error: Bad file descriptor". |
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. |
Yes, no any activity in RX/s or TX/s when recording and about 15000-17000 bytes/s when playing (both on SCO). Get about 1 packet for 3 second in tcpdump. It's strange, but with PulseAudio recording works fine. May be some dbus configuration issue? Or some kernel option? I will continue to research... |
Hmm... So, if with PA it works, it definitely has to be something wrong
with bluealsa... It might be worth to look at the function responsible
for acquiring SCO socket in the transport.c (transport_acquire_bt_sco).
Maybe, I'm doing something wrong, or not doing something...
If you've got the nerve to research this, I'd be very glad. Like I said
before, with my setup everything works fine, so it is hard for me to
debug it.
|
no any activity in RX/s or TX/s when recording and about
15000-17000 bytes/s when playing
One more thing. Is this 15 kbytes/s during playback in both directions
or only in the TX indicator?
|
It was about 15 kbytes/s for TX and the same for RX during playback. |
By the way. Is blue-alsa required some Linux kernel specific build flags? I have a light weight kernel for the equipment with low performance. |
It was about 15 kbytes/s for TX and the same for RX during playback.
That's strange, but I've got an idea. Could you try to play and capture
at the same time? Because, it might be required to stream audio in
order to receive it from the headset - e.g. headset might not start to
stream audio from the microphone until it receives something to play
(some kind of "optimization"). If it works, try to stop playback and
see if recording still captures sound (e.g. using hcitop).
Is blue-alsa required some Linux kernel specific build flags?
No, or at least nothing I know about. However, bluealsa requires some
CPU power if working as a A2DP source - power required for audio
encoding.
|
Arkq, thanks in advance for a good idea! Start arecord without aplay, get a string Starting in the log and waiting for a file descriptor in the poll function. Start aplay, in arecord log appears Starting IO loop and recording works fine... My be some AT commands needed in blue-alsa? |
What happens when you stop aplay? Does arecord still work? Because I might have some idea how to "fix" this issue :) It is not AT command issue (I think). The problem is, that I'm using HSP/HFP profile in a non-standard way. This profile should be used to stream audio to the headset and receive one from it - standard usage as a handsfree setup for a phone. However, I thought, that receiving audio and not streaming one should be also possible - save CPU and bandwidth. But it might not be as easy as it seems. |
Yes... :) I just made tests... When play astop, arecord continues to record the sound while I don not interrupt the recording manually. |
Check if code from the sco-hotstart branch resolves this issue. |
Recording does not work yet. :-( The debug string "Hot-starting SCO for reading" not appear. If to start arecord only, t->sco.spk_pcm.fd == -1 and t->sco.mic_pcm.fd == -1. If to start aplay only, t->sco.spk_pcm.fd > 0 and t->sco.mic_pcm.fd == -1. If to start arecord (at this moment t->sco.spk_pcm.fd == -1 and t->sco.mic_pcm.fd == -1), then aplay - t->sco.spk_pcm.fd > 0 and t->sco.mic_pcm.fd > 0. |
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). |
Yes, I get the line "FIFO not connected yet". And... SCO recording works fine with removed O_NONBLOCK flag from 97 line and deleted 107 line. :-) |
OK, thanks a lot for your help with this bug. Now I know exactly
what causes this issue - it is not caused by the out of standard HSP
profile usage...
I will fix this in a next few days.
|
@Vitaliy69, please check if the current master snapshot works for you. |
Works fine! Thank you! |
Hi Arkq! First of all, I really appreciate the work you've done so far. This is really a very good project unlike pa which "... breaks your audio" (sic) Unfortunately I've run into a similar issue with my bluetooth device. The playback works just fine, aplay works, mplayer works, chromium works, I can listen to YouTunbe audio. But the recording doesn't. And unfortunately I have no more ideas nor clues how to proceed. I have alsa-1.1.2 Please take a look at the logs. asound.conf: defaults.bluealsa.interface "hci0" pcm.duplex { pcm.!default { pcm.bluzmic { pcm.bluz { ===== bluetoothd[18792]: Bluetooth daemon 5.47 ===== bluealsa: ctl.c:489: Starting controller loop ==== ../shared/ctl-client.c:102: Connecting to socket: /var/run/bluealsa/hci0 ==== ls -la test.wav As you see I have that 44-byte issue, meaning that the .wav is empty. Even more, despite I say to record the audio only for 3 seconds, it doesn't stop it. Mind the ^CAborted by signal Interrupción... If you could only give me a hint where to dig further that would be really great. Thanks! |
I am sorry for the mess here. I hope you haven't lost your time trying to analyse the issue reported. It turns out the issue has nothing to do with BlueAlsa. I found a solution here: https://forums.gentoo.org/viewtopic-p-7846088.html?sid=e055c02e2ca9e8edb99b75d9e24c97b8#7846088 The guy mentions another thread with the solution https://forums.gentoo.org/viewtopic-p-6910768.html#6910768 which comes from a long and a more general discussion on the Arch forum https://bbs.archlinux.org/viewtopic.php?id=91496 So, just for the record, just in case if somebody else struggling with the same issue. I had to enable CONFIG_USB_EHCI_TT_NEWSCHED in the kernel. But anyway, thanks for a good software. |
@keyoffecka pcm.duplex { pcm.!default { pcm.bluzmic { pcm.bluz { to use it with google assistant that is a full duplex audio application. But although it can record being on profile sco, it does not automatically turn to a2dp when playing audio and nothing is heard |
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:
But can not set bluealsa as a default audio device. For this, created the file /etc/alsa.conf as below:
And the ~/.asoundrc as below:
Then restart bluealsa.
The command # aplay -D bluealsa:HCI=hci0,DEV=00:19:7F:98:XX:XX,PROFILE=a2dp test.wav is finished with error:
Output from bluealsa:
What can I do wrong?
If use pulseaudio instead of bluealsa, BT headset works fine.
The text was updated successfully, but these errors were encountered: