This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

WL1831MOD: WL1831MOD: Bluetooth performance degredation with concurrent stream on WIFI part 2

Part Number: WL1831MOD
Other Parts Discussed in Thread: WL1837, WL1831

We are still seeing significant audio issues when having an incoming A2DP stream from a cellphone and an outgoing A2DP stream to a speaker: As soon as WIFI traffic is present, there are significant bursts of noise, as lengthily explained in the previous thread.

We have dug into this issue with the help of an external consultancy and analysed what's going on at BT protocol level. As it seems, there are (usually) no dropped packets, but by looking at the RTP protocol headers in the audio stream, we found that the timestamps are jumping occasionaly, p.ex.:

 7113  82.767373 Motorola_77:d4:d6 (moto g(8) power) → localhost () SBC 617 ✓ PT=SBC, SSRC=0x0, Seq=15, Time=8960 Frames=5
 7114  82.770830 Motorola_77:d4:d6 (moto g(8) power) → localhost () SBC 617 ✓ PT=SBC, SSRC=0x0, Seq=16, Time=9600 Frames=5
 7117  82.776478 Motorola_77:d4:d6 (moto g(8) power) → localhost () SBC 617 ✓ PT=SBC, SSRC=0x0, Seq=17, Time=12416 Frames=5

the time difference of packets 16 and 17 correlates exactly to a pop-noise in the decoded audio stream.

Our hypothesis is now that BT master does not assign enough time slots the sender (cell phone), respectively they are assigned too late due to the presence of wifi traffic.

Does the firmware offer any tuning parameters to give BT traffic higher priorities over Wifi, or is there a way to reduce Wifi airtime so that both interleave at a finer temporal granularity?

sorry it took some time to follow up on this.

Simon

P.S. the config we are using is attached

  • Hi Simon,

    I'll follow up here tomorrow.

    Best,
    Jacob

  • Hi Simon,

    Unfortunately, I do not see the config you mentioned. Can you try sharing it again on this thread?

    Thanks,
    Jacob

  • Simon,

    Just wanted to tell you that I am looking into this issue and will follow up next week.

    Thanks,

    Jacob

  • Hi Simon,

    Bluetooth should have higher priority over Wi-Fi on the device. Can you check the WiLink8 WLAN Features Guide to see if you receive the same performance as listed?

    It looks like this thread noticed performance differences between A2DP source devices connected to the WL1837. Do you notice any differences between A2DP source devices?

    Thanks,
    Jacob 

  • Ok, we would need to check how wifi is performing, we have been using iperf in our tests with up to 10Mbps. Our top priority is clean audio, so Wifi throughput is relevant, but a secondary issue.

    That said, we have been testing a number of phones (Samsung Galaxy A5, A52, iPhone 11, Motorola g8) and all show similar audio glitches. BT bandwidth is quite used up as the device runs as a bridge. Lowering the max bitpool size of the SBC encoder/decoder limits BT bandwidth and makes things better a little - the number of audio glitches decreases, but the don't go away (we failed to lower bitrates or switch to mono as HS and phone refused these settings).

    What we did see, Wifi-wise, is that the WL1831 Wifi offers less bandwidth in P2P-GO mode vs. AP mode - propably due to a different channel configuration - in P2P it stays at 11 MHz bandwidth while in AP it configures with 24MHz with the same phone (Galaxy A5).

    Simon

  • Hey Simon,

    Can you take firmware and HCI logs according to this guide? There may be a message in the firmware that would signal a dropped packet. 

    Do you know if your Wi-Fi traffic is predominantly UDP or TCP?

    Thanks,
    Jacob