Forum Replies Created
November 23, 2016 at 1:12 pm in reply to: OE and Bluetooth HFP 8kHz Audio signal #1031309
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.November 23, 2016 at 11:39 am in reply to: OE and Bluetooth HFP 8kHz Audio signal #1031306
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.
MattOctober 13, 2016 at 11:10 am in reply to: wavWasSavedAtLocation – not always "WasSaved" #1031082
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.October 3, 2016 at 11:30 am in reply to: Constructively share and discuss your results with bluetooth devices here #1031056
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 10October 3, 2016 at 11:10 am in reply to: Bluetooth problem with IOS 10 #1031055
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?October 3, 2016 at 7:09 am in reply to: pocketsphinx not suspended after pocketsphinxDidSuspendRecognition event fires #1031048
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.