The Streaming Mix: One Hearing Aid Setting Behind a Lot of Support Tickets

A motorcyclist finds that when a navigation prompt arrives, the wind arrives louder with it. A Samsung owner finds his microphones cut out every time he opens an email. A Pixel owner finds his aids drop into streaming mode when he takes a screenshot on a phone that is already silent. And pulling in the exact opposite direction, a deafblind user finds that losing the room the instant a stream starts is worse for him than any of the above.

These are not four faults. They are one parameter seen from four sides — the streaming mix, the balance between what the environmental microphones are picking up and what is being streamed into the ear. It is set before the device reaches the customer, it is rarely explained to them, and it is behind a meaningful share of the "my hearing aids are broken" traffic that arrives in a brand's inbox.

For a distributor or private-label brand that makes it a sourcing question rather than a fitting detail, because whether the customer can reach the control at all is decided by the platform and its app. Below: what the parameter is, why there is no correct default for it, and what to put to a factory before you inherit the consequences.

What the streaming mix actually is

When audio starts streaming to a hearing aid, the device does not mute the room. It mixes. The stream is laid over whatever the microphones are picking up, at a ratio somebody chose during firmware design or during fitting.

Earbuds sidestep the question by physically plugging the ear canal. A hearing aid mostly cannot, and mostly is not trying to — the whole design premise is that the wearer still wants to hear the doorbell, the traffic, and the person who has just walked into the room. Keeping the microphones live during a stream is a deliberate awareness and safety decision, not an oversight.

The mix is a dial, not a switch. "Microphones muted while streaming" and "microphones fully live while streaming" are the two ends of the same parameter — and different customers genuinely need opposite ends of it.

Why there is no correct default

Take two real cases at opposite ends of that dial.

A rider streaming navigation at speed does not want ambient. Air hitting a microphone port under a helmet is turbulence right at the port, and turning the navigation volume up does not fix it — it gives you two loud things instead of one. He needs the microphones pulled well down while streaming.

A deafblind user needs the reverse. Losing environmental awareness the moment a call connects is not an irritation for him; it removes the channel he relies on to know that somebody is trying to get his attention. He needs the microphones to stay live regardless of what is streaming.

Both are right. No factory default serves both, which means the commercially useful question is not "what should the default be". It is "can the customer reach the control at all".

The layer above it, which is not your firmware

A second mechanism sits above the mix and is routinely mistaken for a device fault. Under ASHA and LE Audio, Android registers hearing aids as an accessibility device and gives them priority for media routing. The consequences look like malfunctions and are not:

• The aids take audio back from a Bluetooth speaker when the wearer walks back into range. They reconnect assertively, by design.
• They switch into streaming mode on a silent phone. What moves the audio route is an application opening an audio session, not sound being produced. A screenshot, a camera shutter or voice dictation all open one.
• Behaviour changes after a handset update. Android 16 and 17 reworked audio routing; a share of recent "it broke" reports are phone-side, and the aids did not change.
• Two customers on the same Android version get opposite results. ASHA support depends on the Bluetooth chipset, so it varies by phone model rather than by OS release.

None of these are firmware defects and none can be fixed at the factory. They matter commercially because the customer has no way of knowing that, and the ticket still arrives addressed to your brand. The four connectivity approaches underneath all of this are covered in the Bluetooth connectivity sourcing guide.

What it costs a brand

1. 01Support time spent diagnosing an operating-system behaviour as a device fault — frequently with the customer, the retailer and the factory all looking in the wrong place simultaneously.
2. 02Returns inside the trial window, filed as "does not work with my phone", on a device that was behaving exactly as designed.
3. 03Public reviews that attribute a handset behaviour to your product. Those outlive the ticket and cannot be corrected afterwards.

The first is an hourly cost, the second is a unit cost, and the third is a permanent one. All three are avoidable with a paragraph of documentation and one reachable setting.

The problem specific to OTC

In a prescription channel the mix is reachable. The fitter opens the manufacturer's fitting software, changes the microphone level in the streaming program, and the patient leaves satisfied. Slow, but solvable.

In OTC there is no fitter. The customer gets whatever the companion app exposes, and plenty of apps expose nothing at all — the mix stays locked in fitting software the buyer will never open. That is not an accusation aimed at any particular brand. It is a structural gap left over from adapting prescription platforms for direct sale, and it is worth naming plainly because it is the part a private-label brand can actually influence, at the sourcing stage, before anything is boxed.

If your product is sold over the counter, every control that lives only in fitting software is a control your customer does not have. For this parameter, that turns a one-setting fix into a return.

What to ask the factory

• While streaming, how far down are the environmental microphones by default — and is that figure documented anywhere?
• Can the mix be changed by the end user in the app, or does it live only in fitting software?
• Is there a separate streaming program the wearer can switch into deliberately, rather than a change to how streaming always behaves?
• Can the microphones be attenuated further, and is there a floor — can they be taken to silent?
• Is expansion available on the streaming program, so that circuit noise is not amplified while the link is open but nothing is playing?
• Which of these appear in the user manual, and in what words?

The last question earns its place. Most of this fits in a paragraph, and a paragraph in the manual costs a fraction of what the same explanation costs one ticket at a time.

A safety line worth putting in your own materials

If you do ship or recommend a heavily attenuated streaming program, say what it costs. Ambient down means sirens down. It means the person shouting a warning is down too. The defensible framing for a customer is a program they switch into on purpose, with some ambient still in it, rather than a permanent change to how streaming behaves. Down is not off, and the difference belongs in your documentation rather than in a review written after the fact.

Where sourcing fits in

Whether this parameter is reachable is decided by the platform and its companion app, and both are settled before the device is packed. A brand that ships an OTC product with the mix locked away has bought a support cost it cannot engineer out later.

Daerdo builds OTC hearing-device platforms — Bluetooth BTE, app-controlled RIC and CIC — for distributors and private-label brands at an FDA-registered facility (Establishment Registration No. 3013596029 — a registration, not an FDA approval or endorsement). Order a sample from a single unit, put it on the phones your market actually carries, and check what the app lets your customer change before you scale.