Re: [RFC PATCH 0/4] Add support for detection

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



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]

  Powered by Linux