[alsa-devel] [RFC 2/2] ASoC: Add MICFIL SoC Digital Audio Interface driver.

[Mark Brown]

On Fri, Dec 14, 2018 at 04:54:13PM +0200, Daniel Baluta wrote:
> On Thu, Dec 13, 2018 at 4:31 PM Mark Brown <broonie at kernel.org> wrote:

> > No, you're missing the point - why not set the sample rate based on the
> > sample rate the interface is running at?

> Hmm, definitely we somehow miss the point here. So what happens
> if we only do Voice Activity Detection (VAD) ?

> This means that there is no sample rate yet configured, so for this reason
> we get the sampling rate as above via ALSA kcontrol interface.

> My feeling is that somehow we will need to create maybe another type
> of stream (VAD?).

> This is a thing that we need to think. Suggestions are welcomed!

This is really easy if you do what other people have done and provide
the detected voice as a compressed stream.  On the other hand if there's
no stream and people just pick the audio out of the normal record path
is there any great reason why people would configure this at all.

> > > > Is this something that should be user selectable or is it going to be
> > > > controlled by the board design?
> >
> > > User should be able to select the clock source since, in theory,
> > > hardware could support any custom rate as long as you can provide the
> > > clock on extclk.
> >
> > What I'm saying is that this should not be selectable by the user at
> > runtime.  It's not like the user is going to open their system and start
> > soldering links onto the board or anything.
> 
> Of course, so would this be a better option to select it from dts?

Yes, or the machine driver.

> > > > Are you *sure* you need to and want to use atomic_set() here and that
> > > > there's no race conditions resulting from trying to use an atomic
> > > > variable?  It's much simpler and clearer to use mutexes, if for some
> > > > reason atomic variables make sense then the reasoning needs to be
> > > > clearly documented as they're quite tricky and easy to break or
> > > > misunderstand.

> We can go back to mutexes no problem, but we thought that atomic vars
> are lighter.

They do less than you might think unfortunately and are more complicated
to reason about so unless you're getting a useful performance gain from
them they're rarely worth the effort.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20181214/017d83c1/attachment.sig>