[BergeracMatt]

Thanks Halle for the quick reply like always. I’ve already written the AVAsset routines to downsample the SaveThatWave output to 8k but I was hoping to not need them.
I didn’t think it would be that big a deal for you to retain the Openears sampling rate through SaveThatWave – I didn’t think you would need to – or should, cater for any variations – simply prevent SaveThatWave from upsampling.
I don’t at all like the loss of fidelity with Openears sampling at 8kHz, SaveThatWave upsampling to 16kHz, then AVAsset downsampling to 8kHz.

My cloud recognition accuracy was extremely low when I was sending 16kHz wav files that contained 8khz bluetooth audio. Recognition rates were better after downsampling the files to 8kHz but nowhere near as good as when I record the audio myself at 8kHz with AVAudioSession

Also – just in case you didn’t know, this 8khz mode should not be applied to all bluetooth connections. Bluetooth HFP 1.6 supports “wideband audio” aka “HD audio” which is sampled at 16kHz. HFP 1.6 was specced around 2012. If both sides support HFP 1.6 or 1.7, then a 16kHz recording should be used.

[BergeracMatt]

Hi Halle, Would you be able to extend the use8kMode to SaveThatWave? As it is, with use8kMode set, wav files are still being created at 16kHz.
Thanks
Matt

[BergeracMatt]

Sorry Halle, I’ve suffered the consequences of doing 18 hour days here. I was doing something stupid, I thought I was calling a routine from the wavWasSavedAtLocation delegate but was in fact calling it from pocketsphinxDidReceiveHypothesis… my bad, sorry for costing your time.

[BergeracMatt]

################

DEVICE: Uniden BTS200
APPLE DEVICE: iPad Mini 2
iOS VERSION: 10.0
OPEN EARS VERSION: 2.5.03

BEHAVIOR: OE does not accept input from device.

FIX: Set disablePreferredBufferSize = YES.

Additional Info: This hardware combination worked perfectly with IOS 9 before upgrading to IOS 10

[BergeracMatt]

Thanks once more for the quick response. I had come across those compatibility options but hadn’t tried them because the hardware was working.
In my case, setting disablePreferredBufferSize got it working. I’ll add some info into the “bluetooth device results” thread shortly.
BTW – I had framework version 2.5.01 and it doesn’t have any of those compatibility properties even though the docs suggest 2.5.x does. I upgraded to 2.5.03 and I was able to set them.

In terms or releasing an app to support as wide a range of hardware as possible, do you think I/we should set all 3 compatibility properties to true? or give users some way of selecting all 6 combinations?
That might be impossible for you to answer – maybe a better question would be – what is the downside of setting all 3 options to true?

[BergeracMatt]

Hi Halle,
I looked for a couple of hours but only found a couple of posts where you talked about the improvements you had made in startup speed. I couldn’t find anything about how it’s likely lead to problems but I heard what you were saying and redesigned. For now, I’ve written a simple “Ignore wrapper” which ignores the first utterance heard. I’ll come back to it later and rewrite the startup so that OpenEars loads after the app’s first prompt is spoken.
Thx again.

[Author]

Posts