Attachments (1) Download All
Nordic Case Info
  • Case ID: 309552
Options

nRF5340 LE Audio Samsung Galaxy Buds2 Pro - Multiple Problems

ksmith197

Hello,

I using the Samsung Galaxy Buds2 Pro headphones to connect to the latest v2.4.0 nRF SDK. I am using the LE Audio demo code as gateway. The demo connects successfully out of the box to the headphones, with some modifications to the prj.conf file, using the nRF5340 Audio DK. For my project needs, I have both source and sink enabled via CONFIG_STREAM_BIDIRECTIONAL.

Problem #1 - Controller Crashes

If you connect to the right headset first, then connect to the left headset, the"ble5-ctr-rpmsg_3349" controller crashes. I believe this also happened on the 3330 controller as well.

The crash happens after calling bt_bap_stream_start on the Left SINK. This only happens if you connect to the right headset first, followed by the left.

Once the controller crashes, the next call to bt_hci_cmd_send_sync will fail on semaphore take "timeout with err -11". This usually happens either on the next le_audio_send stream send OR on the ble_core.c watchdog call to net_core_ctrl_version_get.

Log:

Problem #2 - Connection constantly disconnects

There seems to be a possible timing issue when connecting a headset stream, then starting the scan / connection to the other headset.

After starting the left headset stream, when you start scanning / connecting to the right headset, the left headset drops connection. It happens as soon as the right headset starts scan / connection. I have noticed that if you start searching for the right headset later in time / further in the code connection sequence, this happens much less frequently. The ACL scan is originally in unicast_client_location_cb. If I move the ACL scan to discover_source_cb or stream_enabled_cb, the issue happens much less frequently. If this is time dependent, then this is also likely a problem because as we add code to the rest of the system, time could change again and cause the issue to come back.

Problem #3 - Source audio not always acquired

The next issue that I have seen is if you connect to the headset successfully, the first time the connection is made, the source (headset microphone) audio will play on the headphone jack every time. The issue comes when you put the headset back in the case and close the lid, then re-open and take the headset out. The next successful connection will have a 50% chance of the microphone audio playing on the headphone jack. This 50% chance of source audio working happens every time you put the headphones back in the case and take them out again. 

One note: I have also tested this on a non-audio DK, with the source audio being fed back into the headset sink. For this reason, I don't think the issue has to do with the I2S or HW codec etc.

Lastly, it looks like the audio in data is still being received since the callback for Rx data is still being called.

I have attached an example project. It is the LE audio demo code with minor modifications. Search for <Modified> in the code to see what I modified. The modifications were only made in prj.conf and le_audio_cis_gateway.c

nrf2_4_0_AudioDemo.zip

  • 0

    Hello,

    Thank you for the detailed report!
    I will have to discuss a few things with the team internally tomorrow and I will get back to you with an update after that.

    Best regards,
    Karl

  • 0

    Hello again,

    We have not yet performed any tests with the Galaxy buds pro 2 since the nRF Connect SDK v2.4 release, but we will schedule some next week to take a closer look at the issues you have reported here. In the meantime, I have a few suggestions you could try on your own, along with some additional questions.

    The demo connects successfully out of the box to the headphones, with some modifications to the prj.conf file, using the nRF5340 Audio DK. For my project needs, I have both source and sink enabled via CONFIG_STREAM_BIDIRECTIONAL.

    We have not yet tested using bidirectional streams with the galaxy buds pro 2 before. Does everything work as expected when you run the same test without the CONFIG_STREAM_BIDIRECTIONAL set?

    Regarding Problem #1:
    This behavior was indeed a known issue with the 3330 controller, but it was resolved before the v3349 release, so this is a very interesting report.
    I will need to discuss this some more with the team, and we will test this specifically next week.

    Regarding Problem #2:
    When we tested with the Galaxy buds pro 2 before we found that we had to make these modifications to our gateway device to have the most stable connection to the Galaxy buds pro 2:
    - The presentation delay must be set to 40 ms
    - The ACL connection interval should be 45 ms
    - The maximum number of retransmissions we should use is 2
    - There should be a small delay between the establishment of the two CISs

    Please make sure that you are using these configuration in your test, and see if that improves the stability of the connection.

    Regarding Problem #3:
    During our last round of testing with the Galaxy Buds Pro 2 we saw that there was some issue with the bonding to the earbuds, which perhaps could be related to what you are seeing here.
    Is the ACL to the earbuds terminated when they are put in the case?
    You mention that it works 50% of the time, could you elaborate on the behavior on the other 50% of the time when it is not working?
    It would also be great if you could capture a sniffer trace of these two scenarios (just of the link establishments, not of the ISO parts), so that I could check if there any indication of what goes wrong when it does.

    Again I would like to thank you for the detailed report, and I will keep you updated on any news from our own testing of the Galaxy Buds Pro 2 next week :) 

    Best regards,
    Karl

  • 0 in reply to Karl Ylvisaker

    Thanks for your reply Karl.

    I haven't spent as much time testing without mic audio as it is needed for our project. I did a quick test and it looks like left connects, but right fails to connect. Some times it looks like it is going through successfully and then it gets a -22 on bt_bap_stream_qos. I haven't spent that as much time with this case though.

    Note:

    This is minor but if you start audio system twice in a row, you get a crash.

    Response Problem #2:

    Interesting, adding the delay between establishment of the two CISs may help explain why I had to put the start of the right headset connection a bit later in the connection sequence. It effectively adds a delay.

    I am using the settings ya'll provided except that I tend to see a bit better connection reliability with 2x the ACL connection interval, 90 ms. Both work, but I tend to see the left make a successful connection, then fail starting into the right connection more often with 45 ms. This still happens with 90 ms connection, but seemingly less frequently.

    Response Problem #3

    I have bonding turned off. The first time connecting works but as soon as there is a disconnect, reboot etc. using the stored bond never connects to the device. This is another issue. It finds 2 public addresses but never connects.

    Related to the bonding issue, I have added a key filter since bonding does not work. What I have found though is that it only successfully filter connects to 1 of the two public keys. And, it only connects to the right headset first. After that, I have added CONFIG_BT_PRIVACY and it successfully finds the random address of the other headset.

    The problem though is that we cannot connect to the right headset first because of the controller crash issue so we currently do not have a way to connect to a specific headset vs. all headsets with the name "Galaxy Buds2 Pro". If you have any suggestions for how to uniquely identify a Galaxy headset, i'd appreciate it. We haven't come up with a solution yet.

    For the 50% issue, the failure mode is that the connection is successful but if I print some of the data bytes from the stream, they are all 0s. The data to be receiving but the data is empty. I print the data in audio_datapath_i2s_blk_complete. I also tried playing the tone generation over the mic data and could successfully hear the tone generated.

    Also, every time it happens, I get a lot of underrun conditions.

    The ACL connection is terminated when putting back in the case.

    Weird... I haven't been able to replicate the issue on the demo app I sent you yet. I tested before sending in the original post and saw it but can't replicate now, will test more tomorrow.

  • 0 in reply to Karl Ylvisaker

    One other note on Problem #1.

    I saw a strange behavior on the right headset when connecting first. If you connect to the right headset, you can configure sink and then source, then ONLY start the right source and both the sink + source audio works. This behavior is not true for the left headset, configuring sink will enable sink audio, likewise for source.

  • 0 in reply to Karl Ylvisaker

    For the bonding issue, it looks like if you keep the left headset in the case then bond with the right headset only, you can reboot the processor and it at least attempts to connect to the right headset repeatably. Once the left is bonded though, it won't connect to either headset.

    This also works the other way around. If you keep the right headset in the case then only bond to the left, it attempts to connect.

    Interestingly, if you set CONFIG_BT_MAX_PAIRED=3, then it will attempt to connect as well. It seems once the bonds are full it doesn't even try to scan.

    Attempted connection:

    When both headsets are connected though, it hangs on bt_conn_prepare_events

1 2 3 4 5
Terms of service