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).
Related
I need to feed two headphones from one audio source. In the past, I've done this with one of the many Bluetooth transmitters that support two headphones. I assume the transmitter did this by simply opening two Bluetooth connections, perhaps by using two Bluetooth chips.
My transmitter has recently broken, so it's time to buy another. I've seen various opinions on whether Bluetooth 5 has a new protocol feature that supports two headphones. If true, I'll look at transmitters supporting that feature. Presumably, since the protocol would be affected, I would also need new compatible headphones.
If anyone has definitive information on Bluetooth 5 support for two headphones, I'd like to see it. And, it would be useful it you can reference the specific Bluetooth 5 profile that defines the feature, or perhaps the section of the Bluetooth spec.
Thanks,
Ron
They say that Bluetooth Hearing Aid Profile will support multi-user HQ audio and audio broadcast, but it is not adopted yet.
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).
What I would like to do involves a small bit of hardware. 1) a phone headset, 2) a PCI-modem, and 3) a phone wire. What I would like to do is read audio from the modem, and then digitize it for processing. I'm sure the best way to do this is with Linux, but if it can be done in Windows as well that would be awesome. A second extension of this, is that I would like to be able to translate digital audio to analog audio and send that to the modem so it can be heard from the headset.
Any advice would be greatly appreciated. ( Also, if anybody has a general "pointer" to what I should investigate to replicate the audio stream to a TCP server so it can be accessed over LAN, that would be even cooler. I know how to handle TCP well enough, but I haven't a clue about audio encoding / decoding ).
If anybody's curious, I'm wanting to create a home-wide audio-stream with ears and mouths. Since the phone cables can do that with normal headsets, I thought "why not".
Not just any modem will do. You need a "voice modem", which includes audio capability as well as general modem functionality. These devices usually expose themselves as a regular sound card on the system, once the drivers are installed. From there, you can use any mechanism you want to read/write from those audio streams.
Be warned though that your plan of a whole-house speakerphone isn't simple at all. There are significant feedback issues when using regular POTS lines. There are entire companies that work to solve this problem. The best of them use microphone arrays that are steerable in software. You would be better off using one of these off-the-shelf systems.
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.
I'm evaluating building an application which, simplifying the requirements, records from a microphone equipped small computer (eg: a Raspberry PI) and streams the digitalized sound over wireless connection in almost realtime to a server on the same LAN (No Internet involved). Ideally, the server application would record different streams from various wifi microphones and mix them together..
I'm currently looking into obtain a pretty good quality out of this, comparable somehow to a 128Kb stereo MP3.
At this point, I'm still evaluating options here, so I'm also looking to see your opinion on the feasibility of this.. if you think it's doable, what libraries, APIs, protocols would you use? Consider that this will be likely deployed on Linux based embedded computers (for the wifi mic part) and Linux based servers.
Thanks for your help.
I listen often Shoutcast on the iPad. This sounds pretty good to me. I do not know the kb/s rate there, I think they stream mp3. So I do not think this would be a big issue if you can live with the quality loss which comes with mp3. The bigger issue might be, how good your wireless connection is. When your network is pretty busy, there are more errors and lower speed. It also depends on the wireless standard and the hardware you are using. You may think about buffering, too.