You’re ignoring this member’s posts.
New DNN principles in hearing aids
This topic is closed.
34 replies3k viewsLast reply
To the question of whether Oticon uses what Chatable labels as “inline” vs “hybrid”, my read of the Oticon tech papers is that its implementation appears to fit Chatable’s “hybrid” definition of using DNN for characterizing and categorizing inputs…
It is “passive” in the sense that its DNN is only used to characterize sound inputs using models from which the appropriate weights/biases are derived and which close the gap between observed/presumed outputs and real/ideal outputs…
Thank you for your detailed analysis based on your HPC systems engineering experience. Although I’m a EE by training, I have no HPC systems experience whatsoever, so I’d defer to your insights and expertise in this area for sure.
I clipped some of the points so made above in your post that are kind of take-aways for me to condense my follow-up thoughts on what you said.
Indeed I had no idea what Chatable meant by referring to mfgs that use passively, and I admitted as such in my previous post. But I guess if the Oticon approach to the More DNN is classified as a passive DNN, then that’s OK, too, and there’s nothing wrong with it, as long as it makes the implementation simpler and doable yet still very effective, as pointed out in the Chatable whitepaper as the big advantage.
I think the Chatable paper did a terrible job describing the downside of this passive DNN approach. They said that the potential sound processing itself is limited to what a traditional is capable of → OK, so what? Unless Chatable can elaborate on what the missing potential is, which they don’t. So without any clear elaboration on this, it really means nothing to me.
They also said that another big downside is that any attempt to rapidly adjust the parameters of the HA DSP will result in prohibitive latency because it will incorporate the DNN algorithmic latency into the audio path. I don’t see how this applies to the More flow. The whole More audio processing path on the Polaris platform is shown in the screenshot below that describes the entire flow with the MoreSound Intelligence (which contains the DNN) smack in the middle. So apparently Oticon has already figured out how to make whatever rapid parameters adjustments they need to make work out OK and still involved the DNN in the process just fine within acceptable latency.
The whole point here is that the 2 prohibitive disadvantages mentioned by Chatable for the Hybrid Passive DNN approach don’t seem to apply to the Oticon More to me. Chatable’s analogy of the Hybrid DNN that it’s like having a tiny audi living inside the chip and as long as he/she makes relatively modest, steady and infrequent adjustments, the time it takes him/her to analyze the sound environment and make changes does not cause a latency that you will notice. Well, I think this analogy is really not applicable to the Oticon flow at all. I still contend that this analogy is more like the AutoSense approach (where the AutoSense is the passive DNN) triggering automatic changes from one program to another entire program (that has different DSP parameters set inside) is more like the analogy used by Chatable for the Hybrid DNN.
The Oticon OPN/S/More do not have AutoSense that changes from 1 program to the next. You can practically just stay in the default P1 program all the times and the HA can still rapidly and continuously analyze the environment (500 times a second) and make adjustments to noise reduction and other parameters not in discrete steps or programs, but almost infinitely continuous. Below is a clip from the OpnSound Navigator whitepaper that mentioned this.

You’re ignoring this member’s posts.
Chatable claims an entirely different approach, whereby the network is deployed “directly” to both the analysis and re-processing of sound for delivery. It is “inline” in the sense that the network is supposedly utilized throughout the analyze/characterize/modify/deliver steps. This implies a dynamic end-to-end processing model. It’s at this point that the Chatable paper becomes (IMO) unpleasantly unhelpful. All it tells us is that its model mimics “how active neural circuits function when listening to speech”. …
That said, even with only performing a piece of what is required, if it were in fact dynamic and could create real-time pattern matches on the fly, then this would potentially be a game-changer. Is that possible? Certainly. And Chatable has apparently achieved this to some extent. …Getting from there to a mass-produced product is a long haul that will cost a whole lot of money. For the OEM HA manufacturer, while the reward would be huge, so would the risk. I will definitely stay tuned, but there is nothing here I see that changes what those looking at HA’s now, need to think about. Come back in a couple years.
Yeah, I don’t even pretend to understand what their “inline” approach is, exactly on how they’re able to come up with an entire dynamic end-to-end processing model. For sure they don’t even come close to explaining how it works with enough details to feel like they actually have enough substance to be credible. Simply waving your hands saying you have come up with the next best thing since the invention of sliced bread doesn’t cut it in a whitepaper for me. At least the Oticon whitepaper on their has enough detailed information consistent with how DNN works and gets trained to make what they’re saying credible. Heck they’ve already come out with a product even, and it’s starting to prove to be an effective and useful product to the community. Meanwhile, Chatable is still waving their hands …
Like you said, it’s one thing to come up with something in the lab and refine it to this point, but it’s another thing to turn it into a successful product. Who knows? Maybe in the end, one of the big 6 HA mfgs will end up buying the Chatable technology and turn it into a product themselves.
You’re ignoring this member’s posts.
Thanks for the observations and additional data re the Opn S.
I wanted to dig into this a bit more and ended up on what is IMO, for all practical purposes, a fools errand . . .
"Driscoll (a co-founder) told me the company’s technology and approach is “completely unique” because it doesn’t use noise filtering or other techniques. “It’s actually a deep learning neural net approach to speech and noise separation that doesn’t apply filters to the original audio but rather it listens and re-prints a brand new audio stream in near real-time which is a mimic of just the vocal components of the original audio . . .Or, put simply, unlike traditional approaches to background noise removal — which attempt to label and remove unwanted sounds — Chatable’s identifies the voice we want to hear, and creates a new, identical voice track which sounds (more or less) the same as the original but without any other background sounds. The technique is called end-to-end neural speech synthesis.”
And this is provided as an illustration, titled “Hearing Aid App for Conversation in Speech”: https://www.youtube.com/watch?v=wayFq0sjOkA1 , with these liner notes:
“Chatable removes noise and amplifies voice for use with or without a hearing aid. Chatable’s AI boosts the volume of voice and removes background noise, enhancing your ability to hear speech amongst everyday background noise.”
The video moderator claims the result is as good running on a $100 smartphone as is a $3000 hearing aid.
It was at this point that I suspected this all to be a confusing apples-to-oranges comparison.
When looked at this way and considering Chatable’s descriptions above and in the white paper, comparisons to ’s like Oticon’s More et al appear to be misplaced, to put it kindly.
This was a wild goose chase.
Edit: This may be of interest. Does the audiologist remark under "Do I need … " - kinda put a damper on Oticon’s differentiating ? . . .
Premium hearing aids may use artificial intelligence like machine learning and deep neural networks to help process sound. Learn why this is a significant improvement for people with hearing loss.
Edited for clean-up.
You’re ignoring this member’s posts.
So in a nutshell, my take is that Chatable is saying they’re doing away with the altogether to get rid of that bottleneck, and solely rely on the ’s smarts to sidestep the DSP functionality and come up with a more novel/unconventional way to recreate discrete components of sound types instead of doing DSP to filter/process/remove sounds that are diffused together → “creates a new, identical voice track which sounds the same as the original but without (the noise)”.
Well, in reading the Oticon More whitepaper, they never clearly said that they used this approach in their DNN because what’s inside their DNN is a black box and proprietary. But if you watch their video on the More DNN (https://youtu.be/qxelExG7qRs2), you can see that they’re implying that they use the DNN to recognize sound samples, learn to break them down (presumably into discrete sound components), then attempt to rebalance these discrete sound components together in a sound scene properly. If the rebalancing is different than (not as good or accurate as) the sampled reference sound scene, then this difference is propagated back into the DNN to tweak the weights and biases to minimize this difference. Then repeat 12 million times for 12 million sound scenes until the DNN gets good enough at rebalancing the discrete sound components so the recreated sound scene can sound just like the real sampled sound scenes. Then the recreated sound scene can be manipulated more easily and more effectively in accordance to the user’s preferences.
So lo and behold, this sounds an awful lot like what Chatable is saying they’re doing to the DNN, regardless of whether they want to label it hybrid or inline. But even more than that, what Chatable is describing, creating a new, identical voice without the diffused noise, sounds a lot more like what the DNN from the Philips HearLink 9030 whitepaper is describing, which is a much more narrowly and limited focus on just recreating the identical voice component free of the diffused noise to solely address the speech in noise issue. It doesn’t take the same overall approach of recreating all sound components in a sound scene and make them all discrete, THEN attempt to balance them to the way they should be balanced, like the More does. So the More DNN is not solely focused on solving the speech in noise issue only like the Philips HearLink 9030 DNN.
Again, it boils down to Oticon already has a DNN that’s already productized and released for sale, with successful outcomes so far. Even an affiliate company like Philips with licensed technology from Oticon’s parent company William Demant also already has another differently done DNN based product released out for sale as well (the 9030). Meanwhile Chatable is still at the whitepaper phase (a very poor whitepaper at that) with nothing productized yet.
You’re ignoring this member’s posts.
Amen and again, thanks for your comments and insights.
On that point, I’ve been navigating a lot around this site (I’m currently in Aud searching hell) and seen many other of your posts (particularly about the Oticons) which are very knowledgeable and helpful. You are doing folks a great service - my hat’s off to you.
You’re ignoring this member’s posts.
. . . which is a much more narrowly and limited focus on just recreating the identical voice component free of the diffused noise to solely address the speech in noise issue.
I intended but neglected to comment on this piece of your reply. I think you have nailed it precisely here. When you use the app (the instructions state to move your phone close to the source, whether speaker or device) it blocks out any sound other than the voice (there are sliders to adjust the volume/suppression mix). That is all. This is why I concluded, upon taking a closer look, that or other comparisons, are just not applicable.
As an aside, I saw in another post of yours a snapshot re the Velox SoC architecture and performance. I could not find any specs on the Polaris, only remarks claiming 2x the computational performance (most likely the result of higher-density fabrication). Point being, Chatable’s Edge chip is in no way comparable to what Oticon is doing. End.
You’re ignoring this member’s posts.
As an aside, I saw in another post of yours a snapshot re the Velox SoC architecture and performance. I could not find any specs on the Polaris, only remarks claiming 2x the computational performance which is most likely the result of higher-density fabrication.
I haven’t really seen a spec paper on any of the Oticon platforms per se, just whitepapers on them. Sometimes they do mention geometry size of the platform on them. They said that the Polaris chip is on the 28 nm technology. Not exactly the smallest like some of the 5 or 7 or 10 nm stuff out there, but that’s to be expected of technology to be trailing the current numbers. The Velox platform is based on 65 nm geometry. Strangely, I haven’t really been able to find any Velox S whitepaper to know if it’s still on the 65 nm or has gone down from there. But they do say that the Polaris DSP chip is double the # of transistors compared to the Velox S platform on a chip that’s half the size. And yes, also 2X the computational performance. The memory on the Polaris increased 8x compared to the Velox S.
Here’s a link to the Polaris whitepaper.
You’re ignoring this member’s posts.
I assumed that Oticon OPN was made using 16/14nm process technology and More chipset by 8/7nm process. This is shocking to hear that the chipsets are manufactured on decade-old nodes. Don’t the HA manufacturers know better that more smaller and powerful processors can be manufactured on the recent smaller nodes?
What is the reason behind the lag in manufacturing process adoption? Since there is not much demand for the older nodes by CPU/GPU companies, is it reasonable to assume that the wafer costs are very low compared to the latest nodes and therefore HA companies save a lot on the manufacturing cost and make more profit? Considering that limited 5/7nm wafer capacities have caused the GPU and automotive electronics shortages, it seems that we should be glad that the HA avoided the HA shortages by avoiding the use of the latest nodes.
You’re ignoring this member’s posts.
I don’t really know, but it could very well be that the technology has been simple enough compared to other more demanding and powerful computing platforms that they don’t really need the latest cutting edge nodes to be able to fit their chips all in.
The More is probably a memory hog in order to store all the nodes and weights and biases of the DNN altogether inside, and that’s why it has 8X the memory of the Velox S platform.
You’re ignoring this member’s posts.
In reply to @hearing-love_loss
It seems to me that you make a lot of assumptions without knowing much about IC development. My guess, why smaller nodes/process technologies are not used by the hearing aid manufactures are cost and availability. The cost of chips are more complex than the raw wafer price. (development, tools, init cost of manufacturing ,handing and mounting (smaller pitch sizes are more expensive have also a cost) etc.,)
The real small process technology can be hard to get into with small volume quantities like . try guessing on the no. of GPUs compared to HA
Another reason would be that speed is not every thing. Hearing aids consume very little energy, and ultra low power designs are not optimal in some process technologies. Sonova have shared tiny amount of information on there DSPs, try find a off the shelf DSP that can match it. Or find a DSP with a large amount of memory
My guess would be yes it could be possible to manufacture a DSP in 5nm for HAs but the cost would double or triple the end price for a HA, For once in this reply , I’m sure, that not many hearing impaired would pay for it. So I pretty sure that the HA manufactures know a lot more about process technologies, and there pro and cons, than you give them credit for.
You’re ignoring this member’s posts.
Excellent reply from @hearingama ! The low volume issue and high cost of going for the smaller/smallest technology nodes are right on point. Besides, if the requirements are not there to need the advantages of the smaller nodes, and the mfgs can meet their needs already using the older/larger nodes, why would they go for the smaller nodes and make the end users pay more?
You’re ignoring this member’s posts.
@hearingama, you make good points. This graph (from Onsemi) is instructive:
This is ~7 years old, so these per chip costs are probably at least 30% higher now than shown in the chart, and the graph would be many times steeper with the addition of each of the <=12nm steps non-existent at that time.
Performance comparisons between different types of devices and applications can be perilous. This is why chip manufacturers like Intel and Samsung have been trying to steer away from terms such as MIPS and nm which were until not many years ago the most useful metrics but now are effectively just marketing terms. E.g., a few years ago a 14nm Intel chip was shown to have the same number of transistors with equal performance to a similar function 12nm processor from Samsung, due to other characteristics in the Intel chip. As the graph illustrates, with each density step up at the higher end, the costs multiply significantly and at a level such as 5nm used for the A14, the step difference is an order of magnitude greater cost compared to where Oticon is. Comparing that to the Polaris 28nm is kinda silly; <10nm is IMO an impossible stretch for $2-3B companies like Demant or Sinova, and tier 2 manufacturer’s use commercial devices.
Btw, when Oticon says that the Polaris dsp chip is in 28nm technology, that is probably nearly the entire package given that the only additional pieces are the IC that handles analog/digital conversion along with power and the link, and a third IC for the radios. The Velox has an 11 core NoC architecture, and a good guess is that the space recovered also enabled a separate neural accelerator core to be added for dedicated processing. While the Polaris approach enables substantially more functionality it is at a much higher cost (the cost differential not only being in the development but also a penalty from much lower fab economies of scale as compared to high volume commercial devices) .
While a significant pct of the Velox functional design would have been leveraged into the Polaris, still going from 65nm to 28nm density is quite serious. But there are many other significant factors influencing functionality and performance and cost. The DNN may be a good example of this, where the functionality provided may deliver a result superior to what another oem may deliver albeit with as much or even more real estate. Ref the Intel/Samsung example above; there are innumerable examples of this in the computer industry. Sometimes the $ are better spent elsewhere.
You’re ignoring this member’s posts.
@mingus It wasn’t so much that I wanted a discussion on cost of IC development. It’s was more that some members of the forum, have strong opinions such as hearing aid manufactures are not doing there best help the impaired persons. Best seen as the latest and greatest.
Some could get the impression that once a smaller process technology are made commercially available all other nodes are suddenly uninterested. This is far from true, larger nodes many still have benefits and without known all the factors/choices, it’s simply impossible to guess why a specific process technology is chosen.
You’re ignoring this member’s posts.
Understood. I’m very new here and so I can’t speak to the “strong opinions” that you refer to. I can only say that technology choices can be counter-intuitive and so its best that speculation be clearly qualified. About business strategy and motivation, all the more so. But of course, this is commonplace and found most everywhere people discuss such things.
Unfortunately, sometimes my OCD takes over and I take an unnecessary deep dive into details.
You’re ignoring this member’s posts.
Related discussions
Hearing Aids12 replies
Scholarly Articles, News, and Other Resources0 replies
Fitting Software Requests1.1k replies
Fitting Software Requests513 replies
Fitting Software Requests419 replies