Bluetooth LE Audio Latency Test on Android 13

Поділитися
Вставка
  • Опубліковано 1 лип 2024
  • One of the major issues with Bluetooth Classic Audio is the audio latency, which makes A2DP unsuitable for interactive usages such as video games. Bluetooth LE Audio is the next generation of Bluetooth audio standards, and enables audio streaming that is better suited to movies, video games, etc.
    In this video, Apple AirPods Pro with USB-C, Bose QC Ultra Earbuds, Samsung Galaxy Buds2 Pro and Sony WF-1000XM5s will be connected to a Sony Xperia 5V running Android 13 and tested for the latency.
    00:00 Introduction
    00:55 Apple AirPods Pro with USB-C
    02:25 Bose QC Ultra Earbuds
    04:45 Samsung Galaxy Buds2 Pro
    07:01 Sony WF-1000XM5
    10:04 Conclusion
  • Наука та технологія

КОМЕНТАРІ • 36

  • @fdimb
    @fdimb 4 місяці тому

    Hey! Thanks for the video. There doesn't seem to be many info about LC3 out there (and not too many devices either, not to mention that it's only supported on Android and Linux -if you have a patched version of Pipewire, not by default-). Have you tested LC3+ compared to LC3? So far I've only found the Creative Zen Air Pro to support it but there are 0 reviews, I don't trust that.
    Does the duplex mode work properly (IE keeping the audio quality when using the mic -- for open spec bluetooth, up until now, the audio quality would degrade considerably when going into call mode. The duplex nature of Bluetooth LE should keep the quality, but hard to tell as there're not reviews at all).

    • @GadgeTweet-dn7gk
      @GadgeTweet-dn7gk  4 місяці тому +1

      @fdimb The Creative implementation of LC3plus is ULL, which supposedly provides lower latency and lower sound quality than standard LC3. We'll wait for some other implementations for the test.
      LE Audio expectedly produce clearer calls than Classic Audio, but we're still developing how we test and demonstrate it.

    • @fdimb
      @fdimb 4 місяці тому

      @@GadgeTweet-dn7gk thank you!!

    • @RxMaxx
      @RxMaxx 2 місяці тому

      Duplex mode works with the LC3 codec, but the quality is reduced, although the sound remains stereo. But for LC3+ the quality does not noticeably reduce! But the LC3+ has a shorter range.
      I mean headphones (output), it remains stereo in LE Audio. In classic mode, when using a microphone, the headphones play in mono. The microphone is mono in any mode.

    • @GadgeTweet-dn7gk
      @GadgeTweet-dn7gk  Місяць тому

      @@RxMaxx When you select an LE Audio device as an input device on Windows 11, the call quality will be 1-channel, 16-bit and 32kHz. And I've never seen LE Audio devices using LC3plus for calls. What devices did you use then?

    • @RxMaxx
      @RxMaxx Місяць тому

      @@GadgeTweet-dn7gk I mean headphones (output), it remains stereo in LE Audio. In classic mode, when using a microphone, the headphones play in mono. The microphone is mono in any mode.

  • @FrostArchon
    @FrostArchon 5 місяців тому

    Do you know how to enable lc3 codec on the samsung s23u? I have no idea how to force change the codec.

    • @GadgeTweet-dn7gk
      @GadgeTweet-dn7gk  5 місяців тому

      @FrostArchon No. Currently I have no access to a Galaxy S23 Ultra to check.

    • @GadgeTweet-dn7gk
      @GadgeTweet-dn7gk  4 місяці тому

      I've got a chance to try a Samsung Galaxy S23 Ultra.
      ua-cam.com/video/DwDbAv8XB5k/v-deo.html
      When you connect an LE Audio device to it, you'll find the LE Audio toggle switch in the device detail. You can use LE Audio/LC3 if you turn the toggle on.

    • @FrostArchon
      @FrostArchon 4 місяці тому

      Unfortunately the S23 doesn't allow the buds 2 pro to operate in LE Audio mode for some reason. When using the S23 with Buds 2 Pro it locks you to only use their samsung scalable codec.@@GadgeTweet-dn7gk

  • @dinimit4
    @dinimit4 5 місяців тому

    Is there a version of this app for windows?

  • @kmstar2230
    @kmstar2230 6 місяців тому

    Can you share the link to the app?

  • @flamyf
    @flamyf 4 місяці тому

    it freaking exists finally
    i wounder why galaxy buds lc3 is so bad compared to sony's

  • @user-qj2hk7oi7r
    @user-qj2hk7oi7r 4 місяці тому

    The total roundtrip within the smartphone with the LC3 codec was 83ms. In a complete scenario: audio source e.g. TV set with Auracast transmitter, the latency of the transmitter must also be added. This is probably also between 40ms and 80ms. This means that the total latency for LE Audio/Auracast is around 160ms. This is far too high for watching a movie, as video and audio are so far apart that it is almost impossible to understand, especially for the hard of hearing. The total latency must not exceed 30ms. LE Audio/Auracast is therefore not a technology for assistive listening.

    • @GadgeTweet-dn7gk
      @GadgeTweet-dn7gk  4 місяці тому

      Round-trip latency is the sum of output latency and input latency. Adding 80 msec to 83 msec will never give you the total latency for LE audio.

    • @user-qj2hk7oi7r
      @user-qj2hk7oi7r 4 місяці тому

      I understand your comment to mean that you are assuming an even higher latency. I have calculated very graciously. According to your information, Auracast is obviously even less suitable for assistive listening. This means that the Bluetooth SIG has raised false hopes for all hearing impaired people, who will now be bitterly disappointed. Moreover, Auracast is not barrier-free anyway, because an Auracast-enabled smartphone is always required in addition to new hearing systems. However, a smartphone is not a disability-related aid and is therefore not barrier-free. With Auracast, hearing and understanding are not only dependent on the hearing system, but also on a smartphone, its battery status and the user's ability to use it. According to a representative survey, more than half of people over the age of 65 do not use a smartphone, partly due to other disabilities. These people are therefore excluded from participation in social, cultural, political and religious life.

    • @GadgeTweet-dn7gk
      @GadgeTweet-dn7gk  4 місяці тому +1

      @@user-qj2hk7oi7r When you experience audio delay over the video, it's output latency. We've subtracted the 29 msec from 83 msec to get the output latency from the LE Audio transmission. Hence the 54 msec will be the latency you should experience when you have the same setup as we do. We haven't tested Auracast for the latency, but usually lower bitrate values are used for Auracast broadcast than LE Audio Unicast. Auracast expectedly provides slightly lower latency with lower sound quality.

    • @user-qj2hk7oi7r
      @user-qj2hk7oi7r 4 місяці тому

      @@GadgeTweet-dn7gk The 29ms is the time the audio system needs without a codec process, so the 54ms is the time the LC3 needs to decode. But if I have a full process: an Auracast transmitter that has to encode and needs 43ms like the GN-Resound TV Streamer+ and the signal goes directly into a hearing aid and has to be decoded there with a very weak CPU, then the whole thing adds up to at least 100ms or more. That's definitely too much for the lipreading, on which the profoundly hard of hearing depend.
      An example: in-ear monitoring for stage musicians must not exceed 10ms, otherwise the musicians will lose their rhythm. (Source: A Shure webinar on wireless audio transmission.) For the hearing impaired, the maximum latency between seeing and hearing is said to be 20-30ms. If I'm watching a movie on a newer TV, I may be able to delay the video, but if I'm in a lecture, that's not possible, as understanding is limited.
      But nevertheless: I think your work is great and you are only the testers for the technology, not the designers.

    • @GadgeTweet-dn7gk
      @GadgeTweet-dn7gk  4 місяці тому

      Whatever the audio signal must be decoded to PCM and handed over the Bluetooth module inside the smartphone. The Bluetooth module encodes it to LC3 and transmits it over the BLE radio. Then the earbuds receive, decode, and convert it to analog signal before outputting it. The 54 msec includes this whole process of the LE Audio transmission.
      According to ITU-R BT.1359-1, detectability thresholds in sound/picture timing are about +45 ms to -125 ms, and acceptability thresholds are about +90 ms to -185 ms. I wonder how you tested if 100 ms is too much for the lipreading.