* Discarding the first few frames inside the kernel
@ 2016-01-18 18:21 Ankhit Vivekananda
2016-01-19 2:22 ` Takashi Sakamoto
0 siblings, 1 reply; 5+ messages in thread
From: Ankhit Vivekananda @ 2016-01-18 18:21 UTC (permalink / raw)
To: alsa-devel
Hello All,
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.
Appreciate any help!
Thanks,
Ankhit
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Discarding the first few frames inside the kernel
2016-01-18 18:21 Discarding the first few frames inside the kernel Ankhit Vivekananda
@ 2016-01-19 2:22 ` Takashi Sakamoto
2016-01-20 17:24 ` Ankhit Vivekananda
0 siblings, 1 reply; 5+ messages in thread
From: Takashi Sakamoto @ 2016-01-19 2:22 UTC (permalink / raw)
To: Ankhit Vivekananda, alsa-devel
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Discarding the first few frames inside the kernel
2016-01-19 2:22 ` Takashi Sakamoto
@ 2016-01-20 17:24 ` Ankhit Vivekananda
2016-01-21 2:18 ` Takashi Sakamoto
0 siblings, 1 reply; 5+ messages in thread
From: Ankhit Vivekananda @ 2016-01-20 17:24 UTC (permalink / raw)
To: Takashi Sakamoto; +Cc: alsa-devel
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@sakamocchi.jp>
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
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Discarding the first few frames inside the kernel
2016-01-20 17:24 ` Ankhit Vivekananda
@ 2016-01-21 2:18 ` Takashi Sakamoto
2016-01-21 16:28 ` Ankhit Vivekananda
0 siblings, 1 reply; 5+ messages in thread
From: Takashi Sakamoto @ 2016-01-21 2:18 UTC (permalink / raw)
To: Ankhit Vivekananda; +Cc: alsa-devel
Hi,
On Jan 21 2016 02:24, Ankhit Vivekananda wrote:
> I am not sure as to how the wait for 4.5ms can be applied there?
I think you asked about the way to achieve the idea.
Call kernel's process scheduler in the .prepare() implementation of your
driver. For example, msleep() in <linux/delay.h> (More geneous logic is
preferrable, I think.)
Don't do this in .trigger() implementation, because this can be called
in interrupt context, or between
spin_lock_irqsave()/spin_lock_irqstore() in process context.
> Alternatively, does calling snd_pcm_format_set_silence(), be a safe
> method to silence the first few samples coming out of the buffer?
I don't know exactly because I have no supplemental information about
your driver and hardware design.
Regards
Takashi Sakamoto
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Discarding the first few frames inside the kernel
2016-01-21 2:18 ` Takashi Sakamoto
@ 2016-01-21 16:28 ` Ankhit Vivekananda
0 siblings, 0 replies; 5+ messages in thread
From: Ankhit Vivekananda @ 2016-01-21 16:28 UTC (permalink / raw)
To: Takashi Sakamoto, alsa-devel
Hello Takashi,
Thank you very much for the explanation.
Regards,
Ankhit
On Wed, Jan 20, 2016 at 8:18 PM, Takashi Sakamoto <o-takashi@sakamocchi.jp>
wrote:
> Hi,
>
> On Jan 21 2016 02:24, Ankhit Vivekananda wrote:
>
>> I am not sure as to how the wait for 4.5ms can be applied there?
>>
>
> I think you asked about the way to achieve the idea.
>
> Call kernel's process scheduler in the .prepare() implementation of your
> driver. For example, msleep() in <linux/delay.h> (More geneous logic is
> preferrable, I think.)
>
> Don't do this in .trigger() implementation, because this can be called in
> interrupt context, or between spin_lock_irqsave()/spin_lock_irqstore() in
> process context.
>
> Alternatively, does calling snd_pcm_format_set_silence(), be a safe
>> method to silence the first few samples coming out of the buffer?
>>
>
> I don't know exactly because I have no supplemental information about your
> driver and hardware design.
>
>
> Regards
>
> Takashi Sakamoto
>
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2016-01-21 16:28 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-01-18 18:21 Discarding the first few frames inside the kernel Ankhit Vivekananda
2016-01-19 2:22 ` Takashi Sakamoto
2016-01-20 17:24 ` Ankhit Vivekananda
2016-01-21 2:18 ` Takashi Sakamoto
2016-01-21 16:28 ` Ankhit Vivekananda
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.