Buffer injection

[ice-beem]

Hi,

is it possible to inject own audio buffer to openers without allowing openears to control the mic ? Because another functionality in app is using coreaudio to collect the audio.

Thanks

[Halle Winkler]

Sorry, that isn’t possible via an API method.

[bloomqvist]

You said it’s not possible via an API method. Is there another method?
Is there a way we can pass audio buffers directly to Sphinx recognition methods?

If this is not possible, then how about the opposite? Let’s say OpenEars insists on controlling the mic. Can we then observe audio buffer events, so each time a new buffer arrives we can grab a copy of the audio buffer for the app’s other purposes?

Thanks
Bloomqvist

[Halle Winkler]

Welcome,

Let’s say OpenEars insists on controlling the mic.

Well, this is basically the purpose of the framework when you use it to perform speech recognition – it is a low-latency continuous listening tool and its audio driver is very adapted to that goal. I mention this because I’m happy to help to extent possible, but it can be a case of diminishing returns to work around a primary feature, and there is a danger of basing your rework on an implementation detail which isn’t permanent.

Is there another method?
Is there a way we can pass audio buffers directly to Sphinx recognition methods?

If you want to work with buffers, you can modify the source in many different ways to make that possible, but it isn’t possible for me to provide code for that. Take a look at ContinuousAudioUnit.m which is where the buffer callback lives. If you want to work with WAV files, OpenEars has two different methods that perform recognition on WAV files, either as a test file in the main loop or by using the less-supported WAV recognition method of PocketsphinxController.

[bloomqvist]

Halle,

Thanks for the response to the first two questions. How about the last question? Let’s say OpenEars does its job as usual, but as it is receiving audio buffers and recognizing spoken commands, we can tap in to the audio buffer event processing. Can we then observe audio buffer events, so each time a new buffer arrives we can grab a copy of the audio buffer for the app’s other purposes?

The reason I am asking this is that we cannot work with the wave file. What we are doing with the audio file requires the same level of low-latency that OpenEars provides for speech recognition (we need to process audio buffers nearly simultaneously alongside OpenEars).

Thanks

[Halle Winkler]

Hi,

Sure, you can make changes like that by modifying the source in a few different ways, but with the time available it unfortunately isn’t possible for me to give specific code for doing that.

[Author]

Posts