arecord not working on embedded ARM target. #347
Comments
|
For info, I launched bluealsa using: With the Broadcom I reproducibly get the following monitor output when trying to record:
It seems to be sending two blocks of 48 bytes but then maybe some buffer becomes full? |
|
Hi Graham I would recommend you start bluealsa with only one profile to minimize the number of variables here. If your microphone supports HSP then that is the simplest SCO profile and is the best bet for initial troubleshooting:
If there is no HSP support, or once you have HSP working, then if required try HFP:
Finally, try in combination with A2DP if required. Do not use the hsp-hs or hfp-hf profiles, they are for the microphone/speaker end of the link; from your description it looks like you are trying to build a gateway. |
|
A quick web search found this, which may (or may not) be helpful for your Asus adapter: |
|
A bit more research ... The naming convention for Broadcom USB firmware is
You will see ID xxxx:xxxx against each. Make sure you have the correct firmware. There are a number of different firmwares available at: https://github.com/winterheart/broadcom-bt-firmware/tree/master/brcm |
|
Thanks alot for all your help @borine - this is where I have got to so for (no cigar yet I'm afraid): |
|
BTW I launched bluealsa with -p hsp-ag as it didn't respond with -p hfp-ag |
|
@grahamnaylorccfe have you tried to use EDIT: |
OK, bluealsa tries to do that part for you, with Broadcom bluetooth modules. Please can you post the output of:
which should confirm whether the module is reporting itself as Broadcom ? |
|
@borine for my private builds I'm using the broadcom setup also for cypress chips (after cypress acquired broadcom), but I'm not sure whether this will work in all cypress cases so this commit is not mainlined. EDIT: if (a->chip.manufacturer == BT_COMPID_BROADCOM ||
a->chip.manufacturer == BT_COMPID_CYPRESS) {However, I'm not sure whether it will help, because since playback works, chip has to read data from HCI, not from PCM interface. |
and now Infineon has bought Cypress 😄 |
Yes - tried playing on one terminal and record on another - no luck, aplay works just fine but arecord still gives only a 44 byte file. The dongle announces itself as Broadcom so I guess adding Cypress won't help. |
hciconfig -a |
So maybe this fix actually breaks somethings... Try to remove the "if" block from my previous comment - lets keep everything as a default. Before test reboot the board/PC. |
I had built the bluez-alsa with debug enabled, here is the transcript when trying to record: Initially connecting: bluealsa: D: ../../src/dbus.c:57: Called: org.bluez.Profile1.NewConnection() on /org/bluez/HSP/AudioGateway #Then running arecord...... bluealsa: D: ../../src/dbus.c:57: Called: org.bluealsa.Manager1.GetPCMs() on /org/bluealsa #Then ^C to escape bluealsa: D: ../../src/ba-transport.c:971: Closing PCM: 15 |
|
I killed bluetoothd and relaunched as bluetoothd -d and then restarted bluealsa. I don't get any debug messages from bluetoothd when connecting and trying aplay (succesfully) and arecord (unsuccesfully). |
|
hmm, according to https://bluekitchen-gmbh.com/btstack/chipsets/ CSR USB adapters always route SCO over HCI, whereas Broadcom USB adapters by default route SCO to I2S/PCM, and so always need the vendor command to switch routing to HCI. The fact that both CSR and Broadcom are failing in the same way here suggests that SCO routing is not the real issue here after all. Perhaps the microphone is simply not transmitting any audio ? Is there any way to check that (an LED or other indicator on the headset/microphone perhaps). Is this headset known to work with other systems (linux/mac/windows) ? |
|
I tried the headset and USB dongle on an Ubuntu 18.04 installation on a regular PC and was able to detect sound from the microphone and sound back to the earpiece using the audio test facility in settings. Echo testing to Skype also worked fine. Back on the embedded board I have tried a few other headsets with the same problem on record. Do you recommend any particular USB dongle to BT headset that is known to work. Ultimately I will need this to work to a waterproof headset for use underground (cave rescue). cheers Graham |
|
If the headset/dongle combination works with pulseaudio on Ubuntu 18.04 then it should work with bluealsa also. Its a mystery to me why no SCO data is being received on the HCI on your embedded board. If you have time to install bluealsa and test on the Ubuntu 18.04 machine, that would help to be sure this is not a bluealsa bug. You will have to temporarily disable pulseaudio to do this (do not use sudo !):
Restart pulseaudio later with
Please can you test with both dongles (with both pulseaudio and bluealsa) so we can know whether both should be OK on the embedded board. EDIT To restore it, |
|
Thanks for your suggestions @borine . Here is where I have got to: Now there aren't any pulseaudio processes returned by ps -ef, so I launch bluealsa and try in another window running aplay, but get the error: I think I must be missing something fundamental - sorry for being a bit slow on this! |
That error indicates that bluealsa is not installed correctly. Possibly the config file 20-bluealsa.conf is missing or in the wrong directory. I think it should be installed as Also check that the plugin libraries are correctly installed. Not sure how 16.04 organises it libraries, might be or something like: (where aaaaaaaa is the abi used by this system, If pulseaudio is installed, you'll also see the pulse plugin in the same directory:
Please don't give up on this - I'm very interested to understand why this is not working, and if it turns out there's a bug in bluealsa I'm sure @arkq will be keen to find and fix it! |
|
Of course I will help to fix the bug (if it is indeed in bluez-alsa somewhere) :). However, I will repeat my question. @grahamnaylorccfe, please try to build bluez-alsa without Broadcom fixup (e.g. use no-broadcom-setup branch) and check whether it will work or not. |
|
Thanks guys - I really appreciate your help on this. I will try the no-broadcom-setup branch and let you know how I get on. Do you think there could be any chance that there is a missing module in the Linux kernel? We believed that everything for BT had been included. Cheers G |
Given that HSP playback is working, I think it is unlikely that any kernel modules are missing. If pulseaudio bluetooth capture is working, then there are definitely no kernel modules missing. If you can assemble a test platform on which your headset and one or both of your BT dongles work with pulseaudio but not bluealsa and arecord, then when should be able to work out where the error is. |
|
I re-built bluez-alsa (after re-imaging the SD card back to a working state) with the no-broadcom-setup (but am using the CSR dongle - will try the ASUS broadcom dongle later)
Yes this file is present.
files also present
also present
Still getting the same error with aplay suggesting the incorrect installation, however I don't think I missed a step. Will try the Broadcom dongle next |
To be fair, on the smaller board (Cora), pulseaudio does not work on parecord either, hower parecord does work on the larger Zedboard (but with an older Linux kernel, but likely with a different set of kernel modules). |
|
Tried with the Broadcom dongle. I get the same error: I get this in the bluealsa window: but no logging from the aplay command. |
|
Strange, if you like we can talk on freenode #bluealsa in about an hour or
so (right now I'm busy).
|
That error message is from libasound, and results when I don't have access to an Lubuntu 16.04 installation, so I can't check where its confgured alsa datadir is. What version of libasound does it have ( |
|
For the Zedboard: G |
|
just had a look at alsa-lib 1.1.0 source. It has much less informative error messages than later versions, to the error
might also result if it found the
and see if the outcome or error message changes |
|
I just tried again with the recorder. It seems that it was recording from the phone mic and not the headset (durr) but playing back through the headset. Have tried again with skype echo test service a recorded message and I know that worked through the headset mic as I was outside the room with the phone in a drawer! Once I have the log, I will post the btsnoop log. |
|
btsnoop_hci.log |
|
@grahamnaylorccfe I've ordered an Asus USB-BT400 bluetooth dongle to experiment with, I think (hope) this has the same broadcom chipset as yours. As for the CSR, is that a branded device or generic cheap one? what does |
|
The CSR USB BT dongle is a cheap generic one. If you recommend one that works reliably I am more than happy to give that a go. Anyway, the reponses you requested: root@koheron: |
|
@grahamnaylorccfe OK, so my Asus USB-BT400 arrived, and HSP playback and recording work fine with it. So I can only assume your issue is a firmware problem. For reference, mine identifies itself as: Here's how I got the correct firmware:
Please let me know how this works out for you. |
|
Thanks @borine. Sorry for the delay in replying - I had been away on holiday with patchy wifi.. I will try and upgrade my firmware following your instructions - looks like I have build 0000! |
|
I have found a version of the BCM20702A1-0b05-17cb.hcd file that I need that reports a build number of 1467 amongst my pile of versions. I will try that and report back. |
|
I deleted my previous hcd file and used the one I had previously used with a build number of 1467 and get the following: root@koheron: I run bluealsa with: I connect in bluetoothctl report from blualsa: bluealsa: D: ../../src/ba-transport.c:962: New SCO link: 50:19:01:90:7F:39: 18 I will try again and download the driver following your method above to see if the result is any different. |
|
The firmware you attached above has the same hash as mine - they are the same. This line from hciconfig shows that sco traffic is still not being received over the hci: |
|
I am still using the no-broadcom-setup branch as indicated in #347 (comment) . Should I revert to master again? Are we sure I am not missing a kernel module? |
I am reasonably sure .. the modules you need for USB bluetooth with an Ubuntu kernel are
Yes, but first, while you have the no-broadcom-setup branch installed, please could you try the following commands and post the outputs here? The first reports the current SCO settings. The second changes SCO routing to HCI, which is what the bluealsa master branch code does, but the no-broadcom-setup branch does not. |
|
The responses to the above commands:
|
|
After applying the second command I tried connecting to my headset and performing (after a few aplays) arecord - still get no recording and apparently no rx sco packets: and a few failures signalled by dmesg: Interestingly some of the submission failed entries come from the aplay command - which apparently worked correctly (heard the sound file) - maybe an absence of the monitor source? |
|
Hmm, ok so that's the same output I get. It means that SCO routing is initially set to HCI when the adapter is initialized, so HSP recording should "just work" as it does for me, whether you use bluealsa master branch or the no-broadcom-setup branch.
That makes me think its a USB layer issue, not bluetooth. Do you have a USB hub you can try? sometimes errors like that go away when you connect via a hub instead of directly to the usb port on the card. I don't know why - that's a question for a usb forum I think 😄 |
|
|
|
In case it helps, error 28 as reported above is ENOSPC, which, according to https://www.kernel.org/doc/html/latest/driver-api/usb/error-codes.html means |
|
also, (clutching at straws, please ignore and accept my apologies if this is insulting) the Cora Z7 reference manual says:
|
|
After a bit more reading, I've found a kernel config item that is relevant to the USB ENOSPC error. From the Kconfig help: Might be worth checking that your kernel was built with this config. On Ubuntu 18.04, I can do: |
|
Thanks @borine for these pointers - hopefully we are homing in on the issue now. Don't worry about potentially being insulting. I have good competencies in some areas, but I admit I am very weak in others. As it happens I would hope modestly to say that I am good on the electronic hardware side, so had been alerted to the potential power supply issue and am using the barrel connector to ensure sufficient current (this is an issue on several such similar boards - and lets face it a microusb is not a serious way to power electronics - just sloppy!). Thanks anyway for checking. Regarding the kernel modules used. I do not have the file you mention, but when I look at the default Xilinx Linux build config (https://github.com/Xilinx/linux-xlnx/blob/master/arch/arm/configs/xilinx_zynq_defconfig) I notice that the config you mention is not set. I will see if we can rebuild with CONFIG_USB_EHCI_TT_NEWSCHED=y added (I don't believe it is included in any of the succeeding patches). |
On some distributions, you can get the current kernel config from the On a raspberry pi, running Raspbian OS, I get: So that setting is not mentioned at all there, but the ASUS dongle still works correctly with HSP. |
|
root@koheron:~# zgrep USB_EHCI_TT_NEWSCHED /proc/config.gz CONFIG_USB_EHCI_TT_NEWSCHED is not set |
|
OK, so here's a strange thing. I have an atheros on-board USB BT adapter in my laptop, and SCO recording has never worked - sco RX bytes is always 0 just like you are seeing with the Cora board . However, the ASUS external USB adapter works fine on this laptop. I came across a post suggesting that power-saving on a usb adapter can cause issues, so I turned it off by adding the following to my kernel command-line in the bootloader: And now - SCO recording works 🍾 🎆 So, if the kernel config change makes no difference, it might be worth giving this module parameter a try. |
|
@borine I think you are on the right track here!!! Then tried the arecord and got a large .wav file. I then played it back with aplay and heard myself again. The sound was quite distorted - but at least we have some thing to work from. |
|
Thanks so much @borine and @arkq for your help on this and especially your patience and commitment to solve this issue. I think we can consider the original issue of no recording as solved now. There is a residual issue of recording quality, but that I believe is covered in other issues and may be the configuration of the BT physical layer? The values recovered are 8 bit and all 7F or 80 (with the odd 81 and 82), but still remarkably recognisable as speech! |
|
As an addendum, I can say that the quality of the recording is now good. I had been able to adjust the volume a little bit using such as: Anyway - I am now a very happy user of BlueAlsa - thanks again guys! |
|
Hi , HFP headphone connection success with bluealsa. logs are : uname -aLinux 4.9.232-1.19 #1 SMP Tue Feb 1 23:20:16 UTC 2022 armv7l GNU/Linux hciconfig -ahci0: Type: Primary Bus: UART #arecord -D bluealsa:DEV=11:11:22:33:80:72,PROFILE=sco /tmp/test.wav ls -alr /tmp/test.wav-rw-r--r-- 1 root root 44 Feb 14 12:21 /tmp/test.wav |
I have an embedded A9 coretex ARM running on a Zynq chip with an Ubuntu like Petalinux OS. I managed to install the dependencies and bluez-alsa downloaded from master yesterday (21/6/2020, so v2.1 with bluez 5.48). I have similar issues as issue #262 in that aplay works fine on both a2dp and sco (eg with aplay -D bluealsa:SRV=org.bluealsa,DEV=50:19:01:90:7F:39,PROFILE=sco sample.wav ), however when trying to record (you see I need the mic input as I am tring to build an SDR) I get no sound a recorded file of just 44 bytes (using arecord -D bluealsa:SRV=org.bluealsa,DEV=50:19:01:90:7F:39,PROFILE=sco recorded.wav).
I have tried with an Asus USB BT dongle with the Broadsom chip (BCM20702A1 (001.002.014)) and get the same problem with another BT dongle using a CSR chip. For the Broadcom I have the .hcd driver in /lib/firmware/brcm/ , though it does seem that there are two in circulation (BCM20702A1-0a5c-21e8.hcd) and also BCM20702A1-0b05-17cb.hcd, though I have put both in for good measure (both 34kB). No errors in dmesg and all seems OK, but nothing on record.
@borine has helpfully suggested using btmon --sco to diagnose issues on the sco channel during an attempted record, but don't know what to make of it. Any ideas?:
@ RAW Open: bluealsa (privileged) version 2.22 {0x0003} 137.389523
@ RAW Close: bluealsa {0x0003} 137.389976
< HCI Command: Exit Sniff Mode (0x02|0x0004) plen 2 #2040 [hci0] 137.390455
Handle: 12
It looked as though it started streaming, but then stopped as if it was going in to a brick wall.
cheers
G
The text was updated successfully, but these errors were encountered: