Oticon New Product: Oticon Reveal

@sherman said:

Of course, looking at the datasheet for the Reveal, it still looks like the max frequency for Reveal 1 is still only 10KHz.

The sampling rate is not the same as the frequency bandwidth of a device. It is how many samples are taken of a signal per second. The higher the sampling rate, the more faithful it will be to the original signal. CD's have a sampling rate of 44.1 kHz or 44,100 samples per second.

The Widex brand has used a sampling rate of ~33kHz for a very long time. Every other brand is significantly lower than this. Hearing aids use the same sampling rate for their streaming audio as they do every other output from the hearing aid. So streaming audio signals will be downsampled before being processed by the rest of the processing chain for output according to the parameters of your streaming program.

I would guess that Demant uses as sampling rate that is less than 24kHz given how much poorer streaming audio sounds when delivered via a regular Mifi signal vs Widex devices, which upsample 24kHz Mifi signals2. Apple Mifi can use either 24kHz or 16kHz and I suspect it's the latter that Oticon use for Mifi signals, at least in Intent.

The frequency bandwidth of commercially-available hearing aids doesn't go above 12kHz which is only available in top-tier Signia devices. Some brands go up to 10 kHz, but realistically most extended bandwidth devices don't achieve meaningful amplification above 7.5 kHz (and in most cases it's lower than this). Most speech information falls within this frequency range. The upper limit has gradually increased over the past 20 years as feedback management technologies and component miniaturisation has allowed for greater stable gain.

Yeah, I know the difference between sample rate and frequency bandweidth, and they are related, as the sample rate determines the max frequency that can be reproduced (eg: 24KHz sample rate can at best support frequencies up to 12KHz, although probably a little less to allow some headroom)

If the Oticon max fitting bandwidth is 10KHz, then the internal sample rate must be at least 20KHz. Probably 22KHz-24KHz to allow for some headroom.

FWIW, Dr Cliff did say in the video that the LE Audio quality was higher than Mfi, so there is that. But he wasn't specific about what he meant by "audio quality".

I think there might be a mixture of fact and fud in your explanation that's beyond my ability to sort out, so I'll leave the field to you. Just a couple of things though.

Phonaks use the SBC codec which is inferior to LC3 even at higher bitrates. You're probably right about my auditory system but you could say the same about pretty much anyone who uses hearing aids. We're not wearing hearing aids because we like the look of them. Audiophiles have been battling everyone else for years with very reasonable explanations of why their own particular preference ($100 speaker cables anybody?) is obviously superior. Best to congratulate them on their golden ears and move on.

It'd be interesting to know if Oticon are upsampling a 16kHz Mifi stream or downsampling at 24kHz Mifi stream. This could probably be determined by measuring the output of a streamed signal in a test box with a device that outputs measurable sound out to 10kHz. Perhaps @AbramBaileyAuD could ask his lab friends to check this out with Mifi and LC3 audio when the Reveal gets tested?

Does anyone know what version of Bluetooth the Oticon reveal uses?

Please comment on Apple MFI. Thanks.

I hope we can resolve who is correct here, you or Flash regarding how sampling rate and codec affect streaming quality. I do not understand the technology but it appears the answer will have a significant impact on how BT Classic streams on Apple MFI.

I am pretty sure that LE audio streams (to a suitable phone) in stereo with about the same kHz for each channel as classic BT which only streams one channel.

My first MP3 dubbings were at 16 kHz because of equipment capabilities, now I have stuff on my phone at 48 kHz using Ogg Vorbis.

@Jackhammer said:

Dr Cliff says audio streaming quality is so much better with LE Audio on his Android phone. How can that be if sound quality depends on sampling rate and not codec?

In response to your previous question, I agree to disagree with @Hearing_Potential. I strongly feel LE Audio is superior to Classic or MFi regarding sound quality. I'm not an iPhone user, but people I know, and others on this forum have a lot of complaints about apple's protocol.

I can't believe that I'm in agreement with Cliff for a change, but he's absolutely right.

Just do a search on audio quality vs bitrate efficiency using LEA vs Classic. The Bluetooth Sig has proven LC3 outperforms SBC full stop regardless of sampling rate, or bitrate.

@Jackhammer said:

Dr Cliff says audio streaming quality is so much better with LE Audio on his Android phone. How can that be if sound quality depends on sampling rate and not codec?

We're also needing to take into account the characteristics of the wireless bluetooth transmission. MFI uses a weak low energy bluetooth that was never designed for transmission of audio, but was designed for inter-device communication of the type that might exist between a controller and a switch which involves short bursts of energy rather than a continuous stream. MFi uses an adaptive bitrate that can get really low if the integrity of bluetooth low energy signal is poor, resulting in a much poorer sound quality, especially if you move further away from the devices.

Bluetooth Low Energy Audio using the LC3 codec is specifically developed for audio transmission, is more resistant to interference by design and can be transmitted over longer distances as it uses a higher power output than MFi.

Apple built a solution on the technology available at the time. The new technology built since then is the universal standard that will replace it.

The main effect of a lower sampling rate from an audio quality perspective is it reduces the maximum audio frequency that can be represented, which is half the sampling rate. For example, 16KHz sample rate limits the maximum audio frequency to at most 8KHz.

Many people with hearing loss probably can't even hear up to 8KHz, so they probably wouldn't really notice the limitations of 16KHz sampling rate. Those of us with reverse slope losses aren't so lucky...

I'd love to know what sampling rate oticon uses for LE Audio. It's probably possible to get that information from the bluetooth logging on an Android phone - no need for packet sniffing.

There are also aliasing distortions, such as frequency ghosting where high-pitched frequency re-appear as synthetic low-frequency sounds and loss of fine temporal structure because the sampling rate cannot resolve this. The latter affects the perception of timbre the acoustic separation of instruments and the perception of closely-spaced musical notes. I think what I hear a lot frequency ghosting with Oticon's implementation of MFi (at least in Intent) at least with my iPhone and iPad.

That's probably more down to poor quality resampling. When downsampling you must use a low-pass filter to remove higher frequencies before the downsample otherwise you get those sorts of artifacts.

It's quite possible that the phone is not bothering to properly downsample the audio, so it might not even be the hearing aids fault...

Even with CD the 44kHz sample gets more than halved to 21KHz to over sample by at least 2.1 to remove artifacts.

I understood that given the potential 10KHz response of the Oticons, you need a 20KHz bandwidth transmission. Or 16Bit to give you 96dB dynamic range. The difficulty with all the MFi/LE signalling iirc (aside from trying to squeeze down the power usage) is that it struggles with parallel function as there’s only so many slots per packet available in addition to handling your Apple Watch and insulin monitor.

If your IOS device thinks that the low energy broadcast is going to be narrower band than that, then I’ll bet they ‘optimise’ the signal to lower bit-rates to keep the energy usage down, while conventional Bluetooth just pumps out it’s standard wider band signal without being chopped.

I’d go one further with Oticon, perhaps the Oticon implementation is common across all of their models: and I haven’t checked the specs recently, but the uppermost models always always used to feature slightly wider receiver response. I’m willing to be wrong here, but if their connection is written for the Intent 4, it’s not going to fully utilise the bandwidth available on the Intent 1.