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@xxxxxxxxxx> 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.
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
