On Wed, 16 Oct 2024 15:02:24 +0200,
Amadeusz Sławiński wrote:
>
> There are some scenarios when using DSP where one may want to have
> partially active stream and fully enable it after some event occurs.
>
> Following patchset adds new "detect" state to ALSA state machine to
> allow waiting for condition to occur before fully starting a stream. In
> further patches the state is propagated through ASoC components to allow
> them to handling the state as necessary.
>
> Main goal of this patchset is to allow handling scenarios like keyphrase
> detection - where DSP analyses incoming signal and wakes userspace to
> consume stream only when keyphrase is detected.
>
> I'm sending this as RFC so we can discuss if this is the way to go or if
> there is perhaps another preferred way of adding such interface.
> Userspace part of implementation is available at
> https://github.com/amadeuszslawinski-intel/alsa-lib/tree/rfc_detect
>
> Amadeusz Sławiński (4):
> ALSA: core: Add support for running detect on capture stream
> ALSA: core: Allow polling for detection
> ASoC: pcm: Add support for running detect on capture stream
> ASoC: Propagate DETECT trigger
Generally speaking, the addition of a new PCM state should be avoided.
It'll influence too badly on all user-space programs. e.g. if an old
user-space program receives such a new state, what should it do?
How can it know it's a fatal error or it can be ignored / skipped?
And, if it's about the synchronization of the DSP readiness, can't it
be rather synced in each PCM open or prepare instead?
Takashi
[Index of Archives]
[Pulseaudio]
[Linux Audio Users]
[ALSA Devel]
[Fedora Desktop]
[Fedora SELinux]
[Big List of Linux Books]
[Yosemite News]
[KDE Users]