The Bluetooth SIG dropped the ball by not already making a BLE profile for HA and similar devices.
It’s a work in progress afaik. When it is announced, it will probably be at a new level compared to mfi and asha, because it will use Bluetooth 5 and later features.
This is an interesting read. The evolution of Bluetooth audio18. Short on detail perhaps, and there’s obviously stuff that the author feels he can’t talk about. It gives me the impression though that the next generation in Bluetooth audio is on its way.
One has to wonder, If a company owns a preparatory Bluetooth standard known for low power consumption, and comes out with true wireless earbuds that reply on batteries, why would they choose to not use this standard in their own product? One may say that they want these earbuds to have the option to be used universally. Let’s say just for kicks, that this hypothetical company typically never cares about anyone using their products except with their other products. It does seem strange that a company would choose to go this direction, unless they are more aware of the limitations of the standard.
I think there is a lot of misinformation being stated here.
Frist of all, anyone who has used DAW’s (Digital Audio Workstation Software for mixing / recording music) has to deal with latency.
Generally 10ms or under is fine (1/100 of a second). Now people are arguing that the Marvel’s signal would be out of sync because of XX latency to the ear that is not directly connected to the phone / audio source – this could cause stereo audio to be out of phase between the left and right ear (noticeable), but not close to detectable when watching against a video stream. You would probably have trouble detecting even 100ms (1/10 of a second).
But all Phonak does is likely delay the signal in the earpiece directly connected to the phone by exactly the amount of the expected latency to get to the other earpiece – so there is effectively zero latency, and hence zero complaints on these boards.
Now – regarding audio and – there is no standard except for Apple’s proprietary standard for Audio over BLE. I worked on a product that attempted to stream audio using BLE, and it was not doable – the bitrate is not high enough for high quality audio.
Whereas, standard bluetooth has protocols already defined to handle phone calls and audio. Even though BLE stands for Bluetooth Low Energy, power can be managed to be the same in BLE vs. older protocols with the newer standards.
So give credit to Phonak for being first to market with ’s that properly support the only open protocol that works with all bluetooth devices.
My Marvels are new, but the streaming quality is wonderful (I have other issues with the way they were setup and work). Phone calls are great too except in noisy environments, but probably nothing is going to work well here.
I got the 312 batteries and I am on day 8 streaming or phone calls at least 2 hours a day and the batteries still work. The amplification required in each ear is likely more of a factor (my hearing loss is mild, so this is probably lower than some).
I agree! I’ve stated in other threads that Classic Bluetooth audio streaming from my Google Play Music subscription through my Phonak Audeo Marvel M90-R’s rivals my best quality headphones. I’ve been using the rechargeable Marvels for over 4 months and for the way I use my Marvels, I’m quite satisfied.
If you’re going to say misinformation is being stated, you should state what you claim to be misinformation so whomever posted it can reply.
I made the point above that Bluetooth Classic introduces latency, but it’s not enough for people to subjectively notice.
Bluetooth Classic was designed a long time ago, before anyone ever thought earbud and hearing aid technology would progress to the point where a wireless interface would be used. Additionally, devices originally intended for Bluetooth Classic were relatively large compared to earbuds and hearing aids, so they had a better power source.
The A2DP, HFP and HSP profiles were all designed on the assumption that there would be a single connection. This is an unfortunate limitation which directly results in both asymmetric power consumption and latency in the secondary device. If latency wasn’t a real concern, Qualcomm would not have developed aptX for low-latency bluetooth audio. Also, the above profiles are also bitrate limited.
Apple hasn’t publicly disclosed any details of their proprietary “standard”, but Android has been open, as is their approach. Like MFi, the new Android implementation also uses to get around the above limitations including power, latency and bitrate. Whatever you say about Apple, MFi is very well implemented and it works much better than Bluetooth Classic. I would be surprised if ASHA does not also work very well. Resound has said they will make it available using a firmware update. With MFi and ASHA, Bluetooth Classic for hearing aids will be a transitory product.
Also, both Phonak and Oticon use BLE for their TV connector devices. If Bluetooth Classic is so good, why would they develop proprietary BLE interfaces? To think the reasons don’t include getting around the limitations of power and latency (not to mention pairing) would be somewhat ludicrous.
If you are smart (like Phonak maybe?) you realise that a2dp is just a broadcast from the phone. As a manufacturer you have full control over the ha’s and only have to synchronise them on a by level so they both can listen to the same broadcast. No latency therefore. Synchronising should not require high bandwidth.
Using the ha’s as a headset Is indeed only possible via one ha and that is exactly the setup Phonak is using
Allow me to try and clarify a bit as there are a few issues here…
Latency – as darylm and I both state is not an issue either way (but for different reasons)
vs. Classic – BLE is newer, longer range, and intended for IoT…not Streaming audio and video. I also uses less power, but this is a non consideration because that can be managed on newer chipsets which all support BLE and Classic and the power savings of BLE is mostly for CoinCell powered IoT devices with superlong standby / wakeup modes.
My Android phone has a 5.0 chipset, and I believe the Marvels have 4.2 – BLE came out in 4.0 / 2011.
BLE between two devices you control is easy (like XXX Hearing Aids and XXX TV Remote, and yes even Apple phones because they are all similar).
BLE from Android phones is somewhat more challenging and you have to use a special library (or waste tons of time / money working around hardware differences in each phone chipset). I would argue that it is not even viable for reliable audio streaming today.
Bluetooth Classic and A2DP are made for exactly what hearing aid users want to do – take and make calls, and stream audio. There is no equivalent standard on BLE (there is on Apple) but all audio apps will stream on Android to the speaker, a headphone, or a Bluetooth headphone using A2DP profile…they won’t stream to some proprietary protocol, so there is no point.
Finally, because BLE (as a standard) is primarily intended for small bursts of data from IoT sensor devices, it is limited in bandwidth (<.3Mps, not guaranteed) whereas classic bluetooth is much higher). So if you want to make a device that works with all phones, TV’s computers, etc. – you have one option – create a Blutooth Classic A2DP protocol device.
Furthermore, everything that people are saying is wrong with this is useless technical mumbo jumbo:
Latency issues – not a problem because it is managed.
battery problems – not a significant difference in real world implementation and a small part of power budget compared to amplification and signal processing.
Unless you want to support Apple devices only, you have to use Bluetooth Classic and nothing about that is going to change in at least 3+ years until with new phones and new OS’s are out that support some non-existent protocol.
battery problems – not a significant difference in real world implementation and a small part of power budget compared to amplification and signal processing.
Er, then how come Phonak upfront announced for the Marvel R’s, 24 hours of battery life no streaming, 4 hours of streaming, 16 hours of battery life (that’s a 33% reduction in rechargeable battery life for only 4 hours of streaming). Whereas Resound, using a proprietary LE method advertises 30 hours no streaming, 24 hours with 12 hours of streaming, i.e. streaming 3x as much with BT LE only reduces your battery life 20% vs. 33% for classic BT 2.x streaming 3x less (not a fair comparison since perhaps ReSound’s battery is 30/24 times bigger?).
Also, too lazy to look up figures but I think you got your facts wrong on BT LE data transmission rate. You can have either a high transmission rate or a high transmission distance (relatively) but not both at the same time.
The application throughput for BT classic can be up to 2.1 Mbits/sec, that of BT LE 1.7 Mbits/sec, not as fast but certainly not < 0.3 Mps (you left something out in the data rate abbreviations).
Bluetooth Low Energy (Bluetooth LE, colloquially , formerly marketed as Bluetooth Smart) is a wireless personal area network technology designed and marketed by the Bluetooth Special Interest Group (Bluetooth SIG) aimed at novel applications in the healthcare, fitness, beacons, security, and home entertainment industries. Compared to Classic Bluetooth, Bluetooth Low Energy is intended to provide considerably reduced power consumption and cost while maintaining a similar communicati It is ind...
So if you’re going to be preachy "allow me …,’ it helps to get your facts straight… If BT Classic did not have a significant impact on battery life, all the HA OEM’s would have used it a long time ago as opposed to developing MFI, etc.
Slightly different table, setting out BT Classic vs. BT 4.0 LE vs. BT 5.0 LE more clearly, slightly lower max data rate for BT 5.0 LE given, 1,360 kbits/sec.
Many factors affect the range of Bluetooth Low Energy and Bluetooth 5. Learn about the distance limiting factors and get all the relevant numbers here.
I don’t believe I got any facts wrong, I am not trying to be argumentative and admit I did not consider 5.0 (which few few phones in the US support and presumably more will going forward).
But my point is mainly that was never intended as an audio streaming protocol, while bluetooth standard is, and there is little hope for non apple users that one will be available anytime soon.
As an example, go to Amazon and search for BLE headphones and there are none, because none implement it – they all do using classic even the very small in bud earphones some supporting up to 4-5 hours of streaming using bluetooth 4.1, 4.2, and 5 chipsets.
Apple’s own earbuds use a proprietary connection (probably BLE) when connecting to newer Apple devices, but require the latest OS be installed and fallback to traditional Bluetooth when working with older Apple and non-Apple devices. As far as I can tell, the pairing process is more involved on older devices, but there is no impact on battery life.
Apple <–> Mfg <–> HA peripherals can use whatever standard they want as long as it is supported by Apple phones and whatever chipsets they use in their hardware. And yes, it likely can be optimized for better battery usage – in this case I don’t know all the details.
When I started looking for HA’s I was quite surprised that they only worked with Apple phones – I thought this was quite crazy. MFI comes from iOS and is primarily a certification program (made for Apple), and I have no idea how it is implemented for HAs.
But I would imagine that others would follow Phonak’s lead as the worldwide market share of Android is much higher than iOS (I think it is over 85% in 2018).
I don’t think power was the biggest or only challenge. Think about this – even MFI connected HAs likely talk to the iOS device using MFI and must maintain connections to each other to coordinate noise cancellation, etc. So that would be 4 connections total vs. 3 for Phonak’s implementation (unless they talk through the phone connection or don’t communicate L<–>R during Streaming … who knows???
So yes, Bluetooth Classic A2DP probably uses more energy than Made For Apple HAs (and I assume that’s built on BLE, though I couldn’t even find this confirmation online).
Because of the much larger market share of Android, and the fact that that the standard is an while A2DP is used for all earbuds and headphones – it is going to be up to other HA manufacturers to support A2DP if they want to support non Apple (and Apple) users in a uniform and quick fashion.
And I believe there are zero latency issues, and the power impact is maybe 5-10%, it’s just harder to do and takes more work on the HA side.
But the alternative today (MFI on Android) simply doesn’t exist.
And I can say from personal experience, supporting anything BLE (I am talking simple IoT and wearables) across multiple Android devices is a challenge compared to supporting A2DP which all Android devices uniformly support.
I am sorry if my e-mails have sounded preachy or argumentative, I was just trying to clear up some misconceptions because I do work with BLE protocols quite often.
BTW – I have the Mavericks with the disposable 312 battery, and they lasted 9 days for my first week of using them…and that was wearing them all day, constantly connected to my phone (every alert came though), and streaming and / or phone calls 2+ hours / day.
But my point is mainly that BLE was never intended as an audio streaming protocol, while bluetooth standard is, and there is little hope for non apple users that one will be available anytime soon.
I’m sure you’re correct that the original ble was never intended for audio streaming. However, Bluetooth 5 extends ble and is intended to support pretty much everything in time. General audio and hearing aid protocols are still under development at Bluetooth SIG. Yes, they are taking their sweet time. I’ve heard that they might arrive with the next major Bluetooth release (6?). No confirmation of that though.
there are no plans for a BLE HA protocol (that I know of)
Apart from any official Bluetooth hearing aid protocol that may arise, there’s a.k.a. “Made for Android”. It’s non-official but it’s an open protocol. Due for later this year. One contributor here says his Oticon OPN1 aids already work with a beta version of Android on his Pixel phone.
I read it all – here are a couple of notes that may be of interest:
It is suggested elsewhere that this spec is built on / 5.0 which would make sense since it does allow for audio over BLE, yet the official spec in the link above above clearly states only BT 4.2 and above is required and that latency is sacrificed for error control (meaning buffering and extra data packets being sent).
This might be a dealbreaker for some: " Note : There is no audio backlink between the central and the peripherals. During a phone call the central (I.E. Android Device’s) microphones are used for voice input." So this is transmit only for audio, no transmit back of voice. Obviously a power savings, but it means you’ll be talking to your phone on calls.
The spec suggests that it provides a packet frame number for synchronization between left and right so technically it is feasible to do without a connection between L<-and->R, but since you have to incorporate error correction and synchronization including dropped packets, latency will likely suffer even more.
After reading the spec, I think Phonak’s current implementation is likely to be superior for most thing people care about:
Power: 2 bidirectional connections vs. a likely 2 one way + 1 two way connections total.
Microphone support;
100% compatibility with any current BT device that works with a wireless headset (any OS, TV, old iPad / tablet, etc).
The idea that is solely responsible for extended battery life on the Quattro, fails to look at the whole picture. There are many things that could contribute to the longer battery claim. For example, the Quattro is physically one of the larger rechargeable hearing aids in this class, and this may be due to a larger internal battery. The chip in the Quattro may also be more energy efficient. The battery life claims itself is also something that we don’t really know much about. As far as I could find, there isn’t an industry standard on battery life claims. Was the test hearing aid set up for a mild or profound hearing loss? Was the hearing aid configured with all the other features enabled and set to max? At what volume was the heating aid set? What was the power lever of the receiver used? When streaming, what type of audio was being streamed?
In addition to all of this, the OPN S is also a BLE rechargeable device and Oticon claims it has even less battery life, compared the Marvel.
Look I know that these devices cost A LOT of money and because of this It’s not uncommon for us to want to justify or defend our purchase decision. We may even want to want to look for faults in other products. I believe this is why we see never ending debates about Chevy vs Ford, Mercedes vs BMW, Samsung vs Apple, and so on.
When purchasing my new hearing aids I studied all the information I could find. I was confident that I could find a clear winner, however each of the devices I looked at from the top 5 manufacturers had great things going for them, they also had negatives. It really came down to my personal hearing loss, the device I personally thought had the best sound, the manufacturer my audiologist was most familiar with, and the features I personally found most important to me. That’s all we can really do.
The idea that BLE is solely responsible for extended battery life on the Quattro, fails to look at the whole picture.
Basically, you have to postulate that the Quattro’s do everything so much more efficiently than the Marvels to get around the simple facts. Classic streaming takes a big hit on the total % of Marvel rechargeabble battery life but the battery capacities are not that much different.
The Marvels, everything else being equal, have a battery life 80% of the Quattro’s (24/30 = 0.8).
Streaming the Marvels for 4 hours reduces the Marvel battery span from 24 to 16 (33% reduction)
Streaming the Quattros’ for 12 hours reduces the Quattro’s battery span from 30 to 24 (20%).
But let’s reduce the Quattro battery parameters to be in proportional to the Marvels
If the battery were Marvel size, streaming for 12 hours on a Quattro would reduce the 24 hour life to
0.8 x 24 (Quattro span after streaming) = 19.2 hours. That’s a 4.8 hour reduction for 12 hours streaming (24 hrs - 19.2 hrs). If we only streamed for 4 hours like the Marvels, we’d only reduce the battery life by 1.6 hours (4.8 x 4/12 streaming proportion Marvel to Quattro). So Quattro’s with proprietary BT LE and apportioned to same size battery stream 22.4 hours, Marvels stream 16 hours on BT Classic. You hypothesize that the Marvels are just inefficient hearing aids to lose 6.4 more battery hours by streaming the same amount. It seems given everything we know about BT Classic and the need for MFI, that the simple facts are demonstrating not the inefficiency of the Marvels, but the inefficiency of Bluetooth Classic as a streaming protocol.
My comments are not faulting the Marvel for anything or saying that the Quattro is intrinsically better for some reason. I am just saying that the relative hit on battery life for Marvel and Quattro seems to demonstrate the usually accepted fact that BT Classic is not as an energy-efficient streaming protocol as some form of BT LE, proprietary or not. For the efficiency price, there may be other advantages to BT Classic, e.g., the easy ability to connect to a wide variety of devices, etc. LE means LOW ENERGY and the facts seem to demonstrate that something running an LE protocol drains the battery a lot less.
I’m too lazy to find the source of this but presumably this is from the standard for the battery drain test - probably what both the Marvel and Quattro statements of battery life are based on - and what OEM’s are required to perform on their HA models to be ANSI compliant, I gather.
I have UP receiver on my Quattro rechargable. I never seen my hearing aid drop below 50% from 100% in one day. I firmly believe that Bluetooth classic master slave configuration is just terrible to be used as a hearing aid and . What if you have a CI in that ear and a hearing aid on the other ear. gets upgraded every 1-3 years while CI every 4-5 years.
How do they make sure that the hearing aid is compatable with CI to various streaming accessory? make streaming independent from HA and CI, this adds benefit of not sending data to the other side and not to worry about the hearing aid mfg changing the hearing aid to match the CI backward compatibility
Obviously what I said about people’s need to defend their purchase and to find faults in other products, went in one ear and out the other. Maybe that’s why they supposedly get better battery life…
Finally, because BLE (as a standard) is primarily intended for small bursts of data from IoT sensor devices, it is limited in bandwidth (<.3Mps, not guaranteed) whereas classic bluetooth is much higher). So if you want to make a HA device that works with all phones, TV’s computers, etc. – you have one option – create a Blutooth Classic A2DP protocol device.
Agree. I think Phonak changed the game with their introduction but I’m sure other manufacturers have tested this in research and will introduce their own version of classic Bluetooth hearing aids.
would limit the devices you could connect to, to just a phone. Classic would connect to laptops, tablets, and generic Bluetooth transmitters. If Classic is a viable option, it would be the obvious choice. Phonak has shown it is possible. Up to Resound and the others to refine it and put pressure back on Phonak.
Rio Rancho, NM
