Not working on Cochlear Nucleus 7 #20
Comments
I run with 5.66 (older than yours). The stable version should be sufficient. The packet dump shows asha_stream_test subscribing to AudioStatus, and then timing out after one second. Your device initially negotiates a supervision timeout of 6 seconds. If you run asha_stream_test with root access or with CAP_NET_RAW permissions, it will override this with the default of 1 second from the android source code. It may need a higher value. Lets try some values that may work better for you. First, edit your Restart the bluetooth service after editing /etc/bluetooth/main.conf, and then forget and rediscover your hearing device using the bluetooth gui. Then try rerunning |
|
As I noted in the slack chat, this is the first device I have seen that originates its own parameter update request (which violates the asha spec, but is what bluetooth devices are supposed to do). Let me know if you already have these config values already set in your config, in which case we may need to make some changes to bluez. |
thewierdnut
added
the
testing report
|
After reading a lot of kernel code, I don't think setting those parameters via |
|
I have tried several values between 100 and 800 for For example, with a value of 600: I've attached a btsnoop file, also for a timeout of 600. |
|
Can you get me a snoop file of |
The timeout 600 wasn't being set (I had a bug in the program). Hopefully its fixed now, can you try again? |
|
Pulled and recompiled (also tried a fresh clone), doesn't work either. I tested both with and without root. With root: Without root: I attached two zipped btsnoop files, one with and another without root. |
|
Ok... non-root use case was about what I expected. It happily subscribes for status notifications, then promptly disconnects when I lie to it about the connection interval (I'm required to send the connection interval, but I have no way to read it from kernel space, so I just send the default). The root use case still didn't send the right timeout. Apparently I was sending it twice, and you disconnected after the first one was wrong, and didn't get the corrected one. I've modified |
|
Unfortunately, it still doesn't work. Looking at the btsnoop, it seems that the connection update is successfully sent and received, but nothing else happens. I tried with different timeouts, both higher and lower, same result. Running it with CAP_NET_RAW permissions (or root) yields: The relevant btsnoop file is attached. |
|
Hm... no change, except now it takes six seconds to time out instead of one. Have you tried this with an android device? I would be interested in seeing an hci dump from a working connection from android device. |
|
Hello, unfortunately I haven't been able to try it with an Android device because I don't have any compatible devices, and I wasn't able to make Bluetooth work with the emulator. However, I was able to successfully run the stream test on different hardware, a 2015 MacBook Pro (Broadcom BCM20703A1 BT chip), running Arch Linux 6.9.7. The connection is quite touchy, though, and I have to be quite close (about 20-30 cm) to the laptop to get it working without dropped frames.
The output of Finally, I have attached a zipped btsnoop file of the stream. |
|
Did you start this capture before or after you connected your device via the bluetooth gui? I ask because the snoop file doesn't show the initial bluetooth connection made by the operating system, just the one asha_stream_test made later. |
I am seriously impressed. This is literally the minimum requirements for running ASHA, and has none of the optional features that make it more stable.
This stream looks about like I would expect. It connects, renegotiates the connection interval, and then starts playback with no hitches. Since you are using bluetooth 4.2, I'm pretty sure its using 1M PHY, though it would be nice to confirm that if we caught the initial connection. Are you streaming to one device, or two? |
|
Hello, sorry for the long delay, I've been busy lately. 1M PHY is indeed the only one that seems to be supported: I've done further tests, with both processors, on one ear and both. Suprisingly, it works in all cases, and I've found that the initial problem with distance was a fluke, it can stream up to around 2 meters. However, there is a stability issue (regardless of whether it's one device or both), wherein after about a minute or so, it starts to drop packages, and the problem compounds until it disconnects. I've attached the snoop and log files (of the stream test) in a zip file. |
|
Testing this with my N7s seems to result in almost exactly the same output on a Framework 16, with a Mediatek card as well. I've attached some logs from basic runs + info below. I'm not sure what a btsnoop entails, but if given instructions on how to do that I can send some and do some testing on my end. I believe my desktop has an AX210 card that I can test with once I get home, but I only have use for direct streaming when I'm using my laptop so would love to get it working here. |
|
@tazz4843 Have you attempted to run |
To get a good snoop capture:
Note that some personally identifiable information, such as the mac addresses of your devices and their human-readable names will be in the snoop file, but its the type of information your devices broadcast out for the world to see anyways. |
|
I tested on my desktop and was able to successfully run the stream_test example (which failed on my laptop) However it is of awful quality and sounds like static in one ear before switching ears and then repeating the cycle. Physical distance to the antennae on the back of my desktop changes nothing it seems. I am willing to share the btmon files but I'd prefer to do so privately since the human readable name has the wrong name for me and I'd like to avoid making that public. If you let me know a good way to share it with you I can send it over :) |
|
|
|
I'm curious... how well does the mediatek bluetooth adapter work if you just attach one device instead of both? |
Re-try it with the correct file type. If you still have issues, or you still want to post a dump with the mediatek adapter, I enabled private vulnerability reporting for the repository. On the github page, you should be able to go to the security tab, then advisories section, then click new draft security advisory, which only I should be able to see. |
|
I ran the sample again (using ikea.mp3 and the scripts), and it's still just as awful. However, while testing it out I did notice I could get a somewhat constant stream in one ear if I had one in just the right location, which was next to impossible to find. Testing on my Framework again, one processor only still results in disconnected after a few seconds. Interestingly I had my processor off and had activity lights enabled, and noticed it flashing blue (meaning receiving streamed audio) the whole time. It almost appears there's a rate change of the blink speed of the activity LED based on the intensity of received audio, this was the minimum possible rate, while I noticed the rate changing depending on where I moved my processors around my desktop as well. Doesn't seem like private security advisories lets me upload a file unfortunately. |
Define "awful" here... Is it loud static? Or is it garbled, but recognizable audio? Is it short bursts of usable sound? |
|
It's garbled sound that's barely recognizable as something human, if I can get a consistent connection. Otherwise it's indistinguishable from static. |
|
I would like to see a snoop file then. If I can also get the command line you are running, that would be great. You can email me the snoop file to me at gmail, which has the same username as my github account. |
|
@tazz4843 Have you tried setting CAP_NET_RAW on the asha_stream_test/asha_pipewire_sink? The N7's that are mentioned further up in this issue tend to set their own connection interval to a garbage value that doesn't work. If you set CAP_NET_RAW, it will attempt to send the correct value instead using raw packets. |
|
I managed to dig up a laptop with a mediatek chipset. First, It wouldn't connect at all until I updated my kernel from the debian default of 6.1 to a 6.10 from the backports repository. Second, it refused to connect to both hearing aids until I set CAP_NET_RAW. I'm guessing mediatek doesn't negotiate the parameters correctly unless you explicitly negotiate them. (edit) ... wow its highly susceptible to interference. Don't run your microwave. |
I've tested this with my Cochlear Nucleus 7 processors, however, streaming seems to not be working, it disconnects almost instantly after connecting. I have tested this on both the right and left ear devices to no avail.
inxi -ISEazyreports:I tested both the stable version from pacman (5.76) and the bluez master branch, on different commits (latest I've tested is 7e028287a).
The Bluetooth module is the AMD RZ616 (MediaTek MT7922) network card. #10 might be related given that it also concerns a MediaTek card. I don't have other cards to test, but I can purchase an Intel AX200 card if necessary.
asha-connection-testsays (MAC address has been sanitized):Running
asha-stream-testyields:I tested with different CE lengths from 3 to 32 and setting 1M/2M PHY, as suggested in #10, same result.
I have attached two zipped btsnoop files (both of the left ear device, with sanitized MAC addresses), one for the connection test and another for the stream test.
asha-btsnoop.zip
The text was updated successfully, but these errors were encountered: