Make it simple to use !!! This is much harder than it looks, as the wifi people have found out over the years. To a first approximation, follow the historical wifi model (which initially had passwords which were ridiculously easy to crack, but people at least used wifi enough to demand better security). In particular, manufacturers have to work much harder on interoperability, on cleaner failure modes (what happens when there is “temporary” interference – does the user have to log out and log back in? – I hope not!), on re-establishing contact after an absence (wifi auto-logs in by remembering passwords), etc., etc.
Note that making things easy for the user may require a lot of hidden mechanism – e.g., continuously scanning in the background for changes in the radio environment – old channels become inaccessible, new channels become accessible, inaccessible channels become accessible again, etc., as well as continuous scanning of the audio environment – including physical sound (mic), analog input jack, digital USB channel, etc.
Re passwords/pins: once again, follow the wifi model, because (most) people already understand it.
Auracast could allow the user to choose the quality – e.g., 24kHz vs 48kHz – or allow for multiple simultaneous broadcasts at different qualities, so that those restricted to 24kHz can receive that quality, while those capable of receiving 48kHz can receive the higher quality. Or Auracast could automatically “negotiate” the quality based upon the choices of broadcast channels and receiver capabilties – this requires that “duplicate” broadcast channels need to be detected as “duplicates”, so that the negotiation process can choose the best of the duplicates available for the situation.
The current Auracast “helper app” model is too complicated and isn’t backward compatible with the real world. The “helper app” itself should NOT require the latest BT 5.3/5.4 HW in the phone in order to operate; I recommend the MoerLab model which allows earphones/earbuds/receivers to have the latest BT HW, while the helper app itself can continue to run on older phones using only “Classic” BT HW.
Minor complaint re Avantree Voyager: if the audio input channel goes silent for a certain amount of time (5 minutes ???), the Voyager turns itself off (presumably to save its battery), but doesn’t come back on when the audio channel comes back again. Apparently, the only way to get things restarted is to power cycle the Voyager (i.e., turn it off and on again); ideally, the Voyager should notice that the audio channel itself has come alive again, so that the Voyager starts transmitting again – without any additional input or fiddling by the user.
@Nerdrunner, I think there are technical limitations to what @PhoebeY can do, and they are imposed by how works:
Unlike Wifi, Auracast is unidirectional. This means the Voyage will blast out its Auracast stream, but it will never hear back from any listening devices. This is by design.
Secure passwords over an insecure channel (wireless!) require that both sides undergo a handshake procedure where they talk to each other first. During this handshake they establish encryption parameters for their subsequent communication session.
This is impossible for an unidirectional channel such as Auracast. Auracast is simply the wrong technology for anything that needs to be super secure. Hence my comment that I’m fine with a 4-digit PIN. It’s enough to deter a casual listener, which is all you can reasonably expect.
Resilience to interference: communication protocols typically achieve resilience by detecting missed packets and having a retransmit mechanism. Once again, that’s impossible on a unidirectional channel. The listener can’t tell the sender to retransmit anything.
There are other methods to increase resilience, such as adding redundancy to the transmitted data. It’s possible that Auracast has this already baked into its standard, but it’s not something a single vendor like Avantree can implement on their own. This has to be part of the standard.
The only thing Avantree could do is to design a high-power transmitter into their product. But there are probably limits to what the Bluetooth standard and the FCC allow.
The latest Voyager firmware already allows switching between 24kbit/s and 48kbit/s. Sending both streams simultaneously would be possible though.
Auracast helpers direct a device to which they are already paired, to latch onto an Auracast stream. This means it’s typically the responsibility of the listening device manufacturer to create the helper. Like ReSound/Jabra. Alternatively the operating system can also do it, because it has access to all paired devices.
I agree with your last point! And I will add that the sliding switch is very fiddly and that it’s hard to move it to the middle position.
How about suppressing the timeout completely if/when the Voyager battery is charging ? The battery can’t possibly run down if it’s being charged, so there’s no need to “save” the battery by timing out.
This handles the case where the Voyager is being used to broadcast audio from a TV and the Voyager is being powered/recharged via the USB connection. Only when the USB power goes down will the Voyager time out; but when the USB power comes back, the Voyager should automatically reboot into its previous state (i.e., try to re-establish connection if it is connected via Classic, or connected via , or connected via , etc.).
What’s ?
It’s the new Bluetooth “broadcast.” A transmitter (TV/phone/computer adapter) creates a channel that many listeners can join at once—like tuning into Wi-Fi—low-latency, with optional passcode for privacy.
Will it work with your Danalogic Ambio6 98 / Smart Ambio 98?
As far as we know, those are not Auracast-enabled, so they can’t join an Auracast broadcast directly. Auracast support in the GN/Danalogic family starts with newer models (e.g., Danalogic Extend / ReSound Nexia). If you ever move to an Auracast-ready pair, you’ll be able to use Auracast transmitters right away.
Is our “Voyager” like a listening device?
Voyager is an Auracast transmitter—it sends TV/PC audio out over Auracast. It’s not a personal microphone/remote-mic. Functionally it’s similar to assistive-listening systems, but your receiver must be Auracast-ready (hearing aids or earbuds).
What can you use today?
With your current Ambio 98s, best options are:
A manufacturer TV streamer for your aids, or
A standard Bluetooth TV transmitter + Bluetooth headphones, or
If you want speech help without streaming, our AS70P Aurago personal listener is a simple “listen closer” solution.
Thanks for the thoughtful suggestion! For safety and longevity, we don’t recommend using Voyager while it’s connected to power. It’s a battery-first, portable transmitter and the auto-timeout helps control temperature, protect the Li-ion cell, and avoid issues that can occur with TV USB power (noise/instability).
If you want a “always-on” TV setup, please use our Audikast 4. It’s -powered, designed for continuous operation, and won’t time out when the TV is on.
We’ll pass your idea (disabling timeout while charging) to our engineering team for future evaluation, but it isn’t something we plan to enable on Voyager right now.
I’ve been dreading any deep discussion of encrypted channels in , but since it’s been brought up, we might as well quickly go through some of the points. Perhaps you will then agree with my dread!
4-digit PIN’s can be cracked in milliseconds on a laptop with an nVidia GPU; indeed, the entire “rainbow table” (Google it) for 4-digit PIN’s probably fits in the cache of most modern CPU’s. So we have to reinvent all the wheels that wifi has already tripped over during the past several decades: we need to store passwords with crypto “salt” (Google it) and bcrypt (or better); we need WPA2/WP3, or better.
Even worse: my laptop could intercept and store an entire encrypted Auracast (as raw bits) broadcast, and decrypt it later. Or sooner, since the laptop could be storing the encrypted broadcast, while simultaneously brute-forcing all 10,000 PIN’s; and by playing back the decrypted broadcast a tiny bit faster, it could be fully caught up to real-time decryption in a matter of minutes.
So we really need a minimum of hundreds of bits in our passwords and/or authorization tokens, which QR codes can easily handle; so why waste valuable development engineering time with silly 4-digit PIN’s ?
Since strong encryption is going to be difficult in any case, and even more difficult to make it easy to use by the vast majority of non-techie people, I propose that valuable developer time be used first to improve ease of use, interoperability, resilience and reliability.
A 4 digit PIN is not secure and can be ‘brute force’ cracked almost immediately with the right tools
A cryptic 16 character password is much harder (but not impossible) to ‘brute force’. However I don’t want to type something like this into the Resound assistant:
If the Auracast assistant supports QR-codes, then a cryptic 16 character password is fine (because you don’t have to type it). But not all assistants support QR codes. Resound does not.
My main point is that I have a hard time imagining a scenario where you actually need strong password protection for Auracast. Earlier in this thread @HalfEar mentioned a few scenarios which I don’t really find convincing:
Family counselling: Why would you use Auracast for that? The whole family sits in a room with the counsellor and they all are hearing impaired and use Auracast to listen to the counsellor sitting next to them? Seems unlikely…
Breakout sessions for courses? Are they so secret that they need strong protection?
Health services offered to the public? If they are public, then why are they secret? If they are one-on-one sessions, then you don’t need Auracast.
Also, anybody concerned about Auracast privacy who also has Alexa or Google speaker at home should probably think about their priorities…
My main point is that I have a hard time imagining a scenario where you actually need strong password protection for Auracast. Earlier in this thread @HalfEar mentioned a few scenarios which I don’t really find convincing:
Family counselling: Why would you use Auracast for that? The whole family sits in a room with the counsellor and they all are hearing impaired and use Auracast to listen to the counsellor sitting next to them? Seems unlikely…
I think we need to consider that there are different levels of protection. It is not necessarily an all or none for any scenario. Having a meeting behind a closed door is less secure than a meeting behind a closed door on a secure access floor.
Using the Multi-Mic+ description from Resound:
The new Multi-Mic+*, enabled with broadcast audio, helps cut through the noise and keeps your conversations going when situations get extra loud. The audio picked up by the Multi-Mic+ is streamed directly to your ReSound Nexia hearing aids giving you extra support in situations where you struggle to hear. It’s also the world’s first remote mic with Auracast allowing the ability to broadcast sound to multiple listeners at once.
If I go to a doctors appointment & bring the Multi-Mic+ to help me hear then I would want that connection to be similar to the closed door for the room we are meeting in. I don’t want our discussion broadcast to everyone in the building. Many senior couples are hearing impaired, the ability for the couple to both hear what the doctor is saying in private without the doctor having to raise their voice is great.
If one remembers back to the days of party lines on land line telephones. One might choose their words carefully knowing that one of their neighbours might hear something they don’t want them to know about.
Then one also has to decide how the technology is being used and make decisions if it is safe to use. Some members of the US government recently found out the hard way that using the Signal app to discuss the real time bombing of another country may not have been the wisest choice.
In a clinic or other face-to-face conversation, unicast is usually the better option than .
It gives you true one-to-one privacy and lower latency, so voices are in sync and not accessible to others nearby.
Auracast is great for broadcasting to many listeners in public spaces, but for private talks I’d go with something like an unicast device — similar to what the AcuEar Pebble 29 uses.
Interesting form factor & capabilities (e.g., mic in charging case) for your Pebble 2.
Do you have any configurations optimized for tour groups ?
“Tour Group” use case:
A single “tour group leader” who transmits – ideally from a very high quality mic clipped to his/her collar or wearing on the head in front of the mouth like a rock star or Broadway performer.
Mild encryption in order to avoid “lookie loo’s” eavesdropping on the tour group.
ANC (audio noise canceling) sets of earbuds for the 15-25 tour participants. Earbuds should either be insanely cheap, or have cheap hygienic easily replaceable eartips. Tour participants might simply purchase the earbuds for themselves permanently, if they are of sufficient quality, and are useful for non-tour applications – e.g., classic telephony & media, , Auracast, ANC listening on airplanes, etc.
Even better for those participants who use hearing aids to easily pick up the broadcast with their own existing hearing aids – including the ability to decrypt the audio.
Many of the tour destinations are very quiet (<30dB), so the ability of the tour leader to whisper and be received by the tour participants is extremely important.
But many of the tour destinations are also extremely noisy (>80dB), with hundreds of screaming kids getting off school busses, etc., so the ability for the tour leader to speak normally and be heard by all of the ANC-earbud receivers in the midst of all this chaos is extremely important.
You can see why ANC is essential for this use case, as only ANC technology can render the audio intelligible in the midst of all this noise without excessive audio volume to the ears, which might damage the existing hearing capabilities of the earbud listeners.
Long range isn’t the main criterion, although everyone in a decent-sized room (or a decent-sized tour bus in the midst of heavy traffic noise) should be able to hear. In larger museums & churches, 50 meters from the tour leader should likely be sufficient range.
The earbuds should complain in natural language when going out of range, and should automatically re-connect (and announce this to the user) when coming back into range.
It should be relatively trivial for the entire tour group to “pair” with the group leader ONLY ONCE. After that, the earbuds should remain paired for the entire rest of the tour – surviving multiple power cycles/rechargings, through tour durations which might last a matter of weeks.
In a clinic or other face-to-face conversation, unicast is usually the better option than Auracast.
The time it takes to pair and connect is a disincentive though. In some scenarios (hospital admissions, ticket counter) you want a way of initiating an assisted conversation quickly. I don’t know if anyone at Bluetooth SIG has thought this through. Maybe there’s a standard solution in the works.
No pairing needed in this case.
We sell the solution as a complete set, and the charging case itself has a built-in pickup microphone.
Just place the case near the talker and the sound is transmitted directly to the earpieces — quick start, no extra setup.
I think they were envisioning the mic staying at the counter or whatever, and each new customer would need to pair/connect vs the mic staying with one customer, going from situation to situation.
Does anyone know the difference between the Avantree Audikast 4HA and Audikast 4? Both models mention and hearing aid support in their descriptions on Avantree.com5
Rural New England