I'm posting for the first time in this forum and English is not my first language so sorry for any mistakes ;) .
I'm trying to find out if it's possible to live stream audio using Bluetooth LE 4.X technology maintaining a very low latency. Namely below 10 ms. I'm trying to live stream a music instrument via bluetooth and the difference between the instant the instrument is played and the musician hears it should be negligible.
I'm asking in particular for the BLE because of what i saw in this page: https://en.m.wikipedia.org/wiki/Bluetooth_low_energy.
In the technical specifications it says: Latency (from a non-connected state) 6 ms. but i cant find where that value came from and even so i don't know if that is the value that I'm looking for.
Thanks! :)
BLE is specifically for sending small amounts of data with an emphasis on saving power by sacrificing speed. If you're concerned about speed and latency then you probably shouldn't be using BLE.
To answer your question, though, the latency is dependent on the connection interval. The connection interval is how long the two devices wait between transfers of data.
The 6ms the wikipedia page is talking about the length of time it takes to do the initial connection between the two devices (BLE is faster at making initial connections than "classic" Bluetooth because I think they made it simpler), but that isn't related to the latency during the regular usage after the connection is established.
Most Bluetooth 4.0 devices that support BLE also support regular Bluetooth, so I'd suggest using that if at all possible (since your concern is latency and not power consumption).
Related
I have a question regarding BLE. It's my first time trying to use BLE and I am exploring some high level designs for a medical device. The structure would be that the device connects to a stand alone controller-device (wifi disabled) via BLE. The device would be collecting data such as heart rate throughout a 24 hour period. At some point the stand alone controller would be disconnected from the device and connected to an app to transfer the data collected. Can BLE handle the potential data size of this scenario? Is it fast enough to do it in a reasonable amount of time?
Thank you!
Take a look at the specification list provided by the Bluetooth SIG. Two documents describe the handling of heart rate measurements, the most interesting for you would be the Heart Rate Service specification (Download it here: https://www.bluetooth.com/specifications/specs/heart-rate-service-1-0/).
It contains a detailed description on how to transmit heart rate data via BLE. According to the specification you are supposed to use the 16-bit UUID 0x180Dfor the Heart Rate Service. You can find the UUIDs for other services and characteristics in the 16-bit UUID Numbers Document.
I am trying to evaluate the suitability of some different wireless interfaces for our project on 2xRaspberry Pi 4 and currently I’m evaluating Bluetooth Low Energy. Therefore I have written an Central and Peripheral device application with the Qt framework (5.15). In my case the latency time between messages is important, because of some security aspects. The message size of each command is around 80-100 Bytes. In one of my tests I have sent 80 Bytes commands every 80ms. Ideally the messages should be received on the other device in 80ms interval as well. For the LAN (TCP) interface this test works well.
For Bluetooth Low Energy I observed that messages, which are sent from Peripheral to Central work quite good and I measured no big delay. Different results I got for the Central to Peripheral direction. Here, I have received the messages in the interval of 100ms to 150ms really exactly. It seems that there couldn’t be a very big magic behind it, so is there any plausible explanation for this? I tested it with a Python script as well and I observed the same results. So it seems that the Qt implementation shouldn’t be the problem.
During research I found out, that the connection interval may influence this, but in Qt the QLowEnergyConnectionParameterRequest (QLowEnergyConnectionParameters Class | Qt Bluetooth 5.15.4) doesn’t work for me. Is there any command, where I can set the connection interval for test purposes at the command line on Linux?
Kind regards,
BenFR
It is possible that your code is slower from central to peripheral because WRITE is used instead of WRITE WITHOUT RESPONSE. The difference is that WRITE waits for an acknowledgement, therefore slowing the communication down, while WRITE WITHOUT RESPONSE is very much like how notifications/indications work in that there's no ACK at the ATT layer. You can change this by changing the write mode of your application and ensuring that the peripheral's characteristic supports WriteNoResponse.
Regarding changing the connection interval, the change needs to be accepted from the remote side in order for it to take effect. In other words, if you are requesting the connection parameter change from the peripheral, then the central needs to have code to receive this connection parameter change request and accept it.
Have a look at the links below for more information:-
How does BLE parameter negotiation work
Understand BLE connection intervals and events
The different types of BLE write
I'm using WebRTC in a sort of non-conventional way.
I have multiple streams generated by several 'broadcasting' peers being sent to a collection of several 'receiving' peer.
I intend to use an SFU media server (maybe Jitsi or Kurento)
It is very critical that these streams are presented at the receiving peers in a synchronized fashion.
What are the methods I can use for synchronization? Usually this isn't an issue with WebRTC because there is not usually a consistent clock between peers, but in my case there is a common clock for all the stream sources.
The only ways I can imagine doing it are:
Not worry about it and hope that WebRTC's low latency will cause everything to be in sync.
Somehow encoding timestamp metadata in the WebRTC stream frames, and somehow synchronizing display with javascript in the browser.
Using a tool like GStreamer that can perform video synchronization, mix the streams into a single stream and forward that to the media server (and thus to the receiving clients). I don't have a good idea of how I would actually perform the synchronization though.
Any thoughts and advice would be appreciated.
The only OTT system capable of synchronisation of low latency streams available (when writing this text), is the SYE system made by Net Insight. They are able to synchronise any device down to single digit millisecond in low latency mode.
They do not provide any open source that I know of but you can check it out by downloading a app that uses it.
Primetime
The game starts 20:00 CET every day, download it on several phones/tablets to verify the sync part.
However there are other systems that can synchronise playback that I found.
HibbTV
HibbTV seams to focus on more IPTV replacement solutions as I interpret the solution. They do not seam to target the wild west of internet. I might be wrong please correct me then.
W3C MULTI-DEVICE TIMING COMMUNITY GROUP
Spoke to the researchers a while back. They can synchronise playback but they target collaborative viewing. The low latency part is not part of the scope as I understand it.
Then when it comes to WebRTC, LHLS, MPEG-DASH CMAF and all other solutions they have no sense of time so it will not be possible to render the same video frame on different devices using various access technologies such as 4G, WiFi or cable or even if the devices uses the same technology because the rendering is buffer controlled not time controlled.
/Anders
I cannot understand how BLE 4.2 headphones are working.
As I know, with BLE protocol you can send 20 bytes only in each packet, so normal listening quality is not possible in this case.
Somebody knows the correct answer?
Thanks a lot!
Headsets running Bluetooth 4.2 spec doesn’t run audio via the BLE links. This is a quite common misunderstanding, but for streaming music and making phone calls etc all phones and computer as of today still use the Bluetooth 2.1 spec and what’s called “classic” profiles to do the work (eg., A2DP for music, HFP for voice calls, etc).
There are indeed streaming audio profiles for GATT/BLE in the making but nothing that’s available yet and consequently not anything that’s supported by products available today.
It’s quite common to see headsets that claim superior audio quality etc “because we use the latest Bluetooth 4.2 spec”. :) The only reason that the product IS indeed listed/qualified as a 4.2 or 5.0 spec is because you typically always qualify your products using the latest spec — but that’s doesn’t imply that the product USE all the latest bits and pieces in that spec...
Even though packets are small, the radio still operates at 1 Mbit/s when it actually sends/receives something. What you want to make sure is that the radio is active as much as possible with as low overhead as possible. With data length extension each packet can be up to 251 bytes instead of 27 bytes. And with several packets per connection event you can get very high throughput (over 800 kbit/s).
I'm making an application, that will be capable to make a VOIP communications on WAN, using AudioManager, specifically AudioTrack and AudioRecord, AudioRecord works fine but I have serious problems with the latency to play with AudioTrack. It is really high and unacceptable. I'm receiving chunks of 160Bytes and my audio settings are of 16 bit, 8KHz, 1 Channel, by that, in my chunk of 160 bytes I have about 10 ms by chunk, I will not have significative latency
I know that they are a lot of peoples with the same problem, but VOIP applications exists and probably the problem is mine.
PD: I'm programming in Java, I have tested it between a Motorola Milestone (Droid, android 2.2) and in another Samsung phone (android 2.3) and I have the same problems in both playing device. Also, I have tried to play my sound streamed to my computer and it is in real time. By that, the problem is in the player (AudioTrack). The latency of the network is very low (I'm on WAN) and I receive more than 99% of the packets (about 16Kb/s).
There is any way to continue with a VOIP program and make it usable?
Really thanks, beyond this problem, I haven't found some clear solution and it surely exist. It is a very usual and usefull, more in a communication device.
Do you use UDP instead of TCP? If not, consider Google for "Android UDP example". If yes, sorry for bothering.