CirrusLogic / tinyhal

Configurable audio HAL for Android
Apache License 2.0
31 stars 17 forks source link

Android Studio Example? #6

Closed BeanStalka closed 4 years ago

BeanStalka commented 6 years ago

I have a project that needs to share the microphone's stream between several 3rd party libraries.

Hotword Detection, VOIP and Speech To Text.

Ideally we would always have the hot word detection running ( a client of the microphone stream) even during a VOIP call. That way the user can say 'Hang Up' and have the call terminated.

TinyHal is so configurable it seems like it would be able to allow for this functionality, but I am not sure since most of the 'read me' is beyond my audio know how.

Questions: 1.) Is TinyHal a good fit for what I am trying to accomplish? The goal is access to a shared microphone audio stream for all interested parties. These parties use something along the lines of _AudioRecord(MediaRecorder.AudioSource.MIC, RECORDER_SAMPLERATE, RECORDER_CHANNELS, RECORDER_AUDIOENCODING, BufferElements2Rec * BytesPerElement);

So we would want our shared stream to be used whenever MediaRecorder.AudioSource.MIC was invoked. If that makes sense

2.) Do you have a better idea or approach to get us this functionality?

3.) Do you have an android studio example or steps to use for TinyHal?

Any help would be greatly appreciated.

Thanks,

Bean

rfvirgil commented 5 years ago

Hi, Sorry about not replying to this question. For some reason the notification email for this never reached my inbox so I never noticed that you'd asked the question. I guess it's way too late now. But if you do have any more questions hopefully I'll get the notifications in future.

rfvirgil commented 5 years ago

In answer to your question about Android Studio examples - no, not really. Tinyhal is normally used by people building OEM devices (phones etc.) and so would be built as part of the full AOSP build rather than as a single component under Android Studio.

Useful examples of real-world configurations are limited by having to choose a suitable reference hardware that is meaningful. I think you really need to have a target hardware to compare any example config file against, a preferably run it on, otherwise it's difficult to really understand what the file is doing if it's just "virtual" and you can't relate it to something real. For very early versions of tinyhal there were a couple of configs for an old Google phone, assuming that you ported tinyhal to that phone. But phones become out-of-date and the example less useful. In any case commercial handsets often have various special features that are not open-sourced so couldn't be incorporated into a tinyhal port. Available Android development platforms are often targeting graphics, wifi, camera as the "features" with the audio only a minimal rudimentary ADC/DAC so they don't offer sufficient functionality to really demonstrate a wide range of configurations.

If you want to share the EXACT same stream between multiple clients (same input, output and audio routing) tinyhal does reference count the streams, so it would only close the stream when the final client releases it. Whether this would work in any situation depends on whether there are other factors that could conflict between those components - typically sharing the stream won't work because only one of them can open the underlying ALSA node.

rfvirgil commented 4 years ago

As this is old I'm closing it.