Can TX2 read digital data from bluetooth mic ??

Hi,everyone:

I recently bought TX2 and I want to develop it as a voice assistant, so I connected my AirPods over Bluetooth to TX2, but when i check “System Settings”, “Sound”, Airpods only show up in “Output” Column, but the “input” device does not have Airpods, Airpods can only be used as a speaker output, but not as a microphone input. So, is that TX2 did not support Bluetooth headset as an audio input, or just my system is not configured correctly?
thanks.

Can someone help me?

Update

Today, I borrowed my friend’s Sony-made Bluetooth headset, this time, the Bluetooth headset device appeared in the ‘input’ and ‘output’ device both, but when I tried to record, I did not get any sound.

I heard that this may be the sound card on TX2 does not support digital audio input, is that right? Or some other reasons?

[b]Can anyone help me, or where can I get some technical support?

Thanks.[/b]

I would give an answer if I could, but I’ve never had anything bluetooth to work with. If one assumes bluetooth is like USB though, then connecting a device would result in a broadcast telling drivers there is a new device and asking if any driver can handle that device. If a driver knows it can handle the device, then it would bind to it.

In the case of USB many people assume a failure is because USB isn’t working, when in reality it is almost always a case of not having a custom driver for the device. As it turns out there are many generic USB devices (standard classes), and those are all supported, but some manufacturers require a custom driver. For the headset which doesn’t work one would need to know exact details of chipset and find out if it requires a custom driver. Should that be the case it may be nothing more than building a kernel module (the driver), or if it is proprietary, then the manufacturer would be required to make the arm64 version available.

I really thank you for your reply.

There is another guy has the same trouble,and still not resolved yet. See:

https://devtalk.nvidia.com/default/topic/976710/bt-headset-pairing-with-tx1

Update:

Today, I tried a few more Bluetooth headsets, these Bluetooth headsets are from different manufacturers, all the same : no input sound. So, I am pretty sure is not my Bluetooth headsets problem.

As for the driver problem you mentioned, I tested all my headsets on my Ubuntu 16.04 PC,all worked fine and didn’t need any extra driver,just basic Bluetooth driver installed when I installed Ubuntu .So, I do not think that some of the headset need customized driver.

So, in my opinion,there could be three possible problems:

  1. Hardware does not support.
  2. The driver provided by NVIDIA in JetPack 3.0 does not support.
  3. Or there are some configurations in my Ubuntu system that need to be changed.

I really hope is the third reason, so I can use the Bluetooth headset in my future development.

Best regards.

Embedded hardware does not install all of the modules a PC does. It is normal to leave out something not used and let the end user install the driver. This would be true regardless of whether it is a generic or name-brand driver. One would have to research the headset to find out what drivers it wants…having the driver on desktop Ubuntu tells you it is probably generic in some way, but you would still need to know which driver it is so you could add it to the embedded system.

Even when the driver is present I’ve found audio configuration can be a pain. I have at times installed the “mumble” chat application and used it to configure audio instead of the standard mixer applications. The complexity of audio routing/mixing seems to be part of all Linux, and not just Jetsons (some basics are not hard to work with, but doing anything fancy gets difficult).

My luck has been with USB headsets, but this uses standard USB drivers, there are very likely different drivers required for a Bluetooth headset’s microphone.

Thank you for your reply.

I am not a hardware engineer, I really do not understand why the hardware supports this basic function, but NVIDIA does not make a complete driver to make it work properly, and leave this problem to users.

As an artificial intelligence researcher, I personally know nothing about how to write hardware drivers. And when I search for ‘Jetson TX2 driver’ or ‘arm 64 Bluetooth driver’ on google, basically there is no result.

So I do not know where to find these drivers, or I have to write those drivers by myself(which is impossible to me).

The driver to run bluetooth is there and works, it’s only a pipe. You need a driver for the input device to handle the microphone, and a driver for the output device to handle audio processing. It gets more complicated when you add a CODEC to the mix to handle different formats…this would be yet another kernel driver or feature. You know that some output formats are supported and that there is an output driver for your headset since you can listen on the headset. The CODECs and several parts of the audio pathway are provided by third parties. The trick here is we don’t know if you are missing a microphone driver or a CODEC. This is usually provided by the manufacturer of the microphone.

Some manufacturers provide hardware matching a standardized class of device…most of those are supported in Linux without manufacturer custom drivers. If not standardized then the manufacturer of the microphone must supply the driver. If the CODEC is proprietary you won’t see it provided in any Linux distribution by default…this would require the end user adding it for legal reasons.

If we knew more about the specific headset (to the point of knowing what chipset is in it…many headsets will use the same chipset if it is popular) we’d know what driver module and/or CODEC has to be enabled. In the Windows world this is actually the same…what differs is that Windows detects what device is plugged in and then goes over the internet and queries its database to install the module/driver without the user knowing much about it (including commercial licensing restrictions when looking at CODECs). In Linux it is up to the particular Linux distribution (e.g., policy of Ubuntu or Fedora or CentOS or SuSE) as to what drivers to make available as modules without asking…this is a non-trivial amount of disk storage on an embedded system and so you’ll have to get used to adding a driver module if it isn’t standardized and you are using an embedded device instead of a PC.

Unfortunately I don’t have bluetooth experience and don’t know nearly as much about tracing device information for this as I do for USB or PCI. I do know that the USB microphones use standardized USB classes so there is no need for a custom driver…I suspect (it’s conjecture) that most bluetooth headsets need a custom driver or at least some sort of CODEC support.

If anyone has an example of a bluetooth microphone (either an individual microphone or part of a headset) it would be useful to know if it works or does not.

Thank you for your reply.

So, your opinion is the Bluetooth driver or CODECs problem? However, I do not know anything about them, so it is difficult to write the relevant driver or CODECs on my own.

So, i was thinking that if the built-in Bluetooth and its driver does not support Bluetooth audio input, then if I disable the built-in Bluetooth, re-purchase a USB Bluetooth adapter, and install the USB Bluetooth driver, Can I solve this problem?

Best regards.

I am doing some guessing here, I have not looked closely at bluetooth spec (the main document is over 2000 pages)…I know USB fairly well, there should be both similarities and differences. It would be very helpful to see an exact model for one or more of the headsets you are using such that the chipset and manufacturer’s driver specification can be looked up. Without that everything is a guess other than the fact that we know the bluetooth controller is able to function correctly when presented with some devices (the bluetooth speaker output works…there is a chain of software involved and much of what goes on is not from the bluetooth controller).

The detail to think about is that I do not believe bluetooth itself supports any particular device, it supports talking to devices via protocols (analogous to ethernet supporting communications, but knowing nothing about a web browser or ssh program…the pipe is agnostic to what is being transported…a failure of a web brower might be blamed on the ethernet driver, but the ethernet driver in no way understands or supports a web browser…an Intel e1000 ethernet driver is not expected to come with firefox support…it isn’t relevant). Device support should come in the form of a “hot plug” layer announcing what device was just plugged into bluetooth…then all support for specific devices would be a separate topic. If the bluetooth has the ability to announce a device in need of a driver, then bluetooth has done its job and is finished.

One thing I did look up in the bluetooth spec is that audio is supported as either of two formats: PCM or CVSD (these are CODECs…any compression requirement might be added in addition on top of this). Each would require different driver support, but be fairly common in support…your speaker must use this, so at least one CODEC is supported. Is this speaker’s CODEC the same as the microphone’s? We don’t know.

There would be other details about how Linux itself finds and binds the correct driver, but this depends on the details of the specific headset. Whatever details you can give about exact model of headset (such that we can see the manufacturer requirements) would be useful. I would bet that the issue is not the bluetooth driver itself (this is what NVIDIA supplies…everything surrounding this driver is Linux or the manufacturer’s custom driver).

NOTE: If the headset requires some driver or CODEC not present, then a USB bluetooth adapter won’t change anything…bluetooth would continue to work and the microphone would continue to fail.

Thank you for your reply.

We tested 4 Bluetooth headsets and 1 Bluetooth speaker. Their models are:

  1. Apple AirPods (headset)
  2. SONY MDR-XB950N1 (headset)
  3. Leme EB30 (headset)
  4. Joway H02 (headset)
  5. Xiaomi Cannon 2 (Speaker)

They are all equipped with a microphone , and Apple AirPods can only be recognized as output device, but can not be identified as input device, the rest can identified as input devices and output devices, but can not record.

Hoping to get some useful information from it.

There isn’t enough information to be definitive (yet), but I am going to make some guesses (emphasis on guessing). I do not have any bluetooth devices to test with, but I am assuming L4T R28.1 because this has bluetooth 4.1 support. Possibly earlier L4T versions also have 4.1 support, but I don’t know.

All of these devices use a known output format/CODEC and do not require custom output device drivers or CODECs. The microphone which is not even recognized as an input (Apple AirPods) would be a custom/proprietary device requiring manufacturer device driver support. I do not believe this microphone can be made to work without extreme effort (if at all). I suspect anything made for a Mac has higher probability of being something proprietary and not easily installed on other platforms.

The microphones which are recognized as input devices probably lack either some configuration (such as mixer) or CODEC. The fact that they show up says bluetooth has done its job.

Case 1: SONY MDR-XB950N1. I can’t find details on this regarding drivers.

Case 2: Leme EB30. This requires bluetooth 4.1, and should not be an issue for the bluetooth side. Unfortunately I have not found anything giving “system requirements” beyond the bluetooth 4.1 requirement. Had this requirement not been met the headset would not have shown up (not even the sound output).

Case 3: Joway H02. The web site appears to be Mandarin, so I can’t tell. I did see it is bluetooth 4.1, which is supported on the Jetson.

Basically I don’t know how to find out what drivers are required beyond bluetooth 4.1. If you connect each of the devices and provide the output from “hciconfig -a” with that device connected something may show up.

Thank you for your reply.

In order to test whether Jetpack 3.1 will solve this problem, today, I use the Jetpack 3.1 flashed my TX2 . But the problem is getting worse, now, bluetooth headsets can only be paired, but can not be connected(my android phone is the same but my bluetooth mouse can still work). After a lots of tests, the problem is still not resolved, so I did not get any “hciconfig -a” information today ,and I am going to re-flash back to Jetpack 3.0 tomorrow,and try to get some “hciconfig -a” detail.

If “hciconfig -a” shows nothing at all I am suspicious that bluetooth is not enabled. After a fresh flash perhaps you need to re-enable bluetooth before testing.

There is output information, but I have not been able to connect any Bluetooth headset , so this may be no useful information.

nvidia@tegra-ubuntu:~$ hciconfig -a
hci0:	Type: BR/EDR  Bus: UART
	BD Address: 00:04:4B:8C:64:75  ACL MTU: 1021:8  SCO MTU: 64:1
	UP RUNNING PSCAN ISCAN 
	RX bytes:2490 acl:7 sco:0 events:93 errors:0
	TX bytes:1393 acl:7 sco:0 commands:81 errors:0
	Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87
	Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 
	Link policy: RSWITCH SNIFF 
	Link mode: SLAVE ACCEPT 
	Name: 'tegra-ubuntu'
	Class: 0x000000
	Service Classes: Unspecified
	Device Class: Miscellaneous, 
	HCI Version: 4.1 (0x7)  Revision: 0x1000
	LMP Version: 4.1 (0x7)  Subversion: 0x610c
	Manufacturer: Broadcom Corporation (15)

Someone knowing more about bluetooth should take a look at this, but you do know that the bluetooth is up, it has sent and received packets without error, and that it is a recent version 4.1 (the 0x7 is bluetooth version 4.1). This is difficult to go further with since I do not have anything bluetooth to test with.

I am curious what was connected (or not connected) with that “hciconfig -a”? Also, if you monitor “dmesg --follow” while bonding or configuring any of the headsets, does anything show up? I see in some docs that hciconfig is being marked deprecated, that bluethoothctl is the replacement. Within the bluetoothctl program you can type “help” to see a list of commands, and of particular interest is the response from “list”, “show”, and “devices” (while one of the non-Apple headsets is connected).

EDIT: ALso, what is your “lsmod” while the headset is attached? I’m interested in knowing if bnep is loaded.

1 Like

Thank you for your reply.

Today, I flashed my TX2 back to Jetpack 3.0, Bluetooth is still the same,and get some ‘hciconfig-a’ detail when headset is not connected:

nvidia@tegra-ubuntu:~$ hciconfig -a
hci0:	Type: BR/EDR  Bus: UART
	BD Address: 00:04:4B:8C:64:75  ACL MTU: 1021:8  SCO MTU: 64:1
	UP RUNNING PSCAN 
	RX bytes:2330 acl:17 sco:0 events:115 errors:0
	TX bytes:1977 acl:21 sco:3 commands:89 errors:0
	Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87
	Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 
	Link policy: RSWITCH SNIFF 
	Link mode: SLAVE ACCEPT 
	Name: 'tegra-ubuntu'
	Class: 0x2c0000
	Service Classes: Rendering, Capturing, Audio
	Device Class: Miscellaneous, 
	HCI Version: 4.1 (0x7)  Revision: 0x1000
	LMP Version: 4.1 (0x7)  Subversion: 0x610c
	Manufacturer: Broadcom Corporation (15)

some ‘hciconfig-a’ detail Afte headset is connected:

hci0:	Type: BR/EDR  Bus: UART
	BD Address: 00:04:4B:8C:64:75  ACL MTU: 1021:8  SCO MTU: 64:1
	UP RUNNING 
	RX bytes:3503 acl:35 sco:0 events:119 errors:0
	TX bytes:2605 acl:41 sco:1 commands:69 errors:0
	Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87
	Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 
	Link policy: RSWITCH SNIFF 
	Link mode: SLAVE ACCEPT 
	Name: 'tegra-ubuntu'
	Class: 0x2c0000
	Service Classes: Rendering, Capturing, Audio
	Device Class: Miscellaneous, 
	HCI Version: 4.1 (0x7)  Revision: 0x1000
	LMP Version: 4.1 (0x7)  Subversion: 0x610c
	Manufacturer: Broadcom Corporation (15)

And there is the output of “lsmod” while pairing and connecting the Bluetooth headset , this message appears only when the device is connected:

[ 3115.373502] input: AC:10:A5:A6:83:26 as /devices/virtual/input/input7

And today I borrowed someone else usb bluetooth dongle, ‘hciconfig-a’ results shown below:

nvidia@tegra-ubuntu:~$ hciconfig -a
hci2:	Type: BR/EDR  Bus: UART
	BD Address: 00:04:4B:8C:64:75  ACL MTU: 1021:8  SCO MTU: 64:1
	UP RUNNING PSCAN 
	RX bytes:766 acl:0 sco:0 events:48 errors:0
	TX bytes:1560 acl:0 sco:0 commands:48 errors:0
	Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87
	Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 
	Link policy: RSWITCH SNIFF 
	Link mode: SLAVE ACCEPT 
	Name: 'tegra-ubuntu #3'
	Class: 0x2c0000
	Service Classes: Rendering, Capturing, Audio
	Device Class: Miscellaneous, 
	HCI Version: 4.1 (0x7)  Revision: 0x1000
	LMP Version: 4.1 (0x7)  Subversion: 0x610c
	Manufacturer: Broadcom Corporation (15)

hci1:	Type: BR/EDR  Bus: USB
	BD Address: 00:1A:7D:DA:71:11  ACL MTU: 310:10  SCO MTU: 64:8
	UP RUNNING PSCAN 
	RX bytes:258661 acl:46 sco:4850 events:1228 errors:0
	TX bytes:911167 acl:2185 sco:4843 commands:89 errors:0
	Features: 0xff 0xff 0x8f 0xfe 0xdb 0xff 0x5b 0x87
	Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 
	Link policy: RSWITCH HOLD SNIFF PARK 
	Link mode: SLAVE ACCEPT 
	Name: 'tegra-ubuntu'
	Class: 0x2c0000
	Service Classes: Rendering, Capturing, Audio
	Device Class: Miscellaneous, 
	HCI Version: 4.0 (0x6)  Revision: 0x22bb
	LMP Version: 4.0 (0x6)  Subversion: 0x22bb
	Manufacturer: Cambridge Silicon Radio (10)

hci0:	Type: BR/EDR  Bus: SDIO
	BD Address: 00:00:00:00:00:00  ACL MTU: 0:0  SCO MTU: 0:0
	DOWN 
	RX bytes:0 acl:0 sco:0 events:0 errors:0
	TX bytes:0 acl:0 sco:0 commands:0 errors:0
	Features: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
	Packet type: DM1 DH1 HV1 
	Link policy: 
	Link mode: SLAVE ACCEPT

the magic thing is when I use the USB Bluetooth dongle connected to the Bluetooth headset, the playback and recording are all functional, but when I pulled the USB Bluetooth dongle out,and use Built-in Bluetooth adapter, I can not recording again. So it makes me very confused,why the built-in Bluetooth adapter can not record but the USB Bluetooth dongle can?