Hello Takashi, Thank you for your response. I am not sure as to how the wait for 4.5ms can be applied there? Alternatively, does calling snd_pcm_format_set_silence(), be a safe method to silence the first few samples coming out of the buffer? Regards, Ankhit On Mon, Jan 18, 2016 at 8:22 PM, Takashi Sakamoto <o-takashi@xxxxxxxxxxxxx> wrote: > Hi, > > On Jan 19 2016 03:21, Ankhit Vivekananda wrote: > >> I am interfacing the ICS43432 MEMS microphone with McBSP interface. The >> data sheet of the ICS43432 microphone shows that it takes about 4.5ms >> (16kHz sampling rate) for startup. Because of this, I hear a transient >> noise at the beginning of every stream. Is there in any way I can discard >> the frames inside the kernel space itself before reading the samples using >> snd_pcm_readi() call? >> >> I was able to mute the first few frames after the readi() call, but would >> want to know if I could do it before the readi() call itself inside the >> kernel space. >> > > If the data transmission starts in 'struct snd_pcm_ops.prepare' callback > of the driver, we can wait what we want, because ALSA PCM core guarantees > to call it in process context. > > In userspace, this looks like (here I describe in alsa-lib API): > - calling snd_pcm_hw_params() > - snd_pcm_prepare() is called library internal > * struct snd_pcm_ops.prepare() is called in kernel mode. > * mute > * start data transmission > * wait for the 4.5ms or somewhat > * return > * return > - return > - PCM frame operation such as snd_pcm_writei() > * snd_pcm_ops.trigger(TRIGGER_START) is called in kernel mode. > * demute > * PCM frames starts to be transferred from userspace. > > > Regards > > Takashi Sakamoto > _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
