When to start the capture device?

When to start the capture device?

[Sheng (Sean) Liu]

Hello everyone,
 
I am using ALSA to capture sound from a micrphone. I need to know when the
capture device starts. In Paul Davis' Tutorial, he mentioned two approaches.
But, I have questions on each of them.
  

When to start the device 

When you open the audio interface, ALSA ensures that it is not active - no
data is being moved to or from its external connectors. Presumably, at some
point you want this data transfer to begin. There are several options for
how to make this happen. 


1. The control point here the start threshold, which defines the number of
frames of space/data necessary to start the device automatically. If set to
some value other than zero for playback, it is necessary to prefill the
playback buffer before the device will start. If set to zero, the first data
written to the device (or first attempt to read from a capture stream) will
start the device. 
 
My question: what does he means on " If set to zero"? Does anyone know which
parameter of which API should be set to zero?

2. You can also start the device explicitly using snd_pcm_start, but this
requires buffer prefilling in the case of the playback stream. If you
attempt to start the stream without doing this, you will get -EPIPE as a
return code, indicating that there is no data waiting to deliver to the
playback hardware buffer.
 
My question: Is there anything to be done before calling snd_pcm_start in
the case of capturing stream? If there is, what are they?
 
 
Thanks in advance,
 
Sheng

Re: When to start the capture device?

[J. Scott Merritt]

On Wed, 19 Sep 2007 16:17:55 -0700
"Sheng \(Sean\) Liu" <shengl@uci.edu> wrote:


> 1. The control point here the start threshold, which defines the number of
> frames of space/data necessary to start the device automatically. If set to
> some value other than zero for playback, it is necessary to prefill the
> playback buffer before the device will start. If set to zero, the first data
> written to the device (or first attempt to read from a capture stream) will
> start the device. 
>  
> My question: what does he means on " If set to zero"? Does anyone know which
> parameter of which API should be set to zero?

I believe this would be snd_pcm_sw_params_set_start_threshold.
 
> 2. You can also start the device explicitly using snd_pcm_start, but this
> requires buffer prefilling in the case of the playback stream. If you
> attempt to start the stream without doing this, you will get -EPIPE as a
> return code, indicating that there is no data waiting to deliver to the
> playback hardware buffer.
>  
> My question: Is there anything to be done before calling snd_pcm_start in
> the case of capturing stream? If there is, what are they?

I use:
   snd_pcm_open
   SetUpHwParams ()  ... /* lots of snd_pcm_hw_params_set ... calls */
   SetUpSwParams () ...  /* lots of snd_pcm_sw_params_set ... calls */
   snd_pcm_prepare
   snd_pcm_start

Best regards, Scott.

Re: When to start the capture device?

[J. Scott Merritt]

On Wed, 19 Sep 2007 16:17:55 -0700
"Sheng \(Sean\) Liu" <shengl@uci.edu> wrote:


> 1. The control point here the start threshold, which defines the number of
> frames of space/data necessary to start the device automatically. If set to
> some value other than zero for playback, it is necessary to prefill the
> playback buffer before the device will start. If set to zero, the first data
> written to the device (or first attempt to read from a capture stream) will
> start the device. 
>  
> My question: what does he means on " If set to zero"? Does anyone know which
> parameter of which API should be set to zero?

I believe this would be snd_pcm_sw_params_set_start_threshold.
 
> 2. You can also start the device explicitly using snd_pcm_start, but this
> requires buffer prefilling in the case of the playback stream. If you
> attempt to start the stream without doing this, you will get -EPIPE as a
> return code, indicating that there is no data waiting to deliver to the
> playback hardware buffer.
>  
> My question: Is there anything to be done before calling snd_pcm_start in
> the case of capturing stream? If there is, what are they?

I use:
   snd_pcm_open
   SetUpHwParams ()  ... /* lots of snd_pcm_hw_params_set ... calls */
   SetUpSwParams () ...  /* lots of snd_pcm_sw_params_set ... calls */
   snd_pcm_prepare
   snd_pcm_start

Best regards, Scott.

Re: When to start the capture device?

[Takashi Iwai]

At Wed, 19 Sep 2007 16:17:55 -0700,
Sheng (Sean) Liu wrote:
> 
> Hello everyone,
>  
> I am using ALSA to capture sound from a micrphone. I need to know when the
> capture device starts. In Paul Davis' Tutorial, he mentioned two approaches.
> But, I have questions on each of them.
>   
> 
> When to start the device 
> 
> When you open the audio interface, ALSA ensures that it is not active - no
> data is being moved to or from its external connectors. Presumably, at some
> point you want this data transfer to begin. There are several options for
> how to make this happen. 
> 
> 
> 1. The control point here the start threshold, which defines the number of
> frames of space/data necessary to start the device automatically. If set to
> some value other than zero for playback, it is necessary to prefill the
> playback buffer before the device will start. If set to zero, the first data
> written to the device (or first attempt to read from a capture stream) will
> start the device. 
>  
> My question: what does he means on " If set to zero"? Does anyone know which
> parameter of which API should be set to zero?

It's about start_threshold for sw_params, corresponding to
snd_pcm_sw_params_set_start_threshold().

> 2. You can also start the device explicitly using snd_pcm_start, but this
> requires buffer prefilling in the case of the playback stream. If you
> attempt to start the stream without doing this, you will get -EPIPE as a
> return code, indicating that there is no data waiting to deliver to the
> playback hardware buffer.
>  
> My question: Is there anything to be done before calling snd_pcm_start in
> the case of capturing stream? If there is, what are they?

snd_pcm_hw_params(), and optionally, snd_pcm_sw_params().

The former is for the mandatory hardware settings, such as, access
mode, format, channels, sample rate, buffer size, period size, etc.
Once after snd_pcm_hw_params() is called and the device is set up,
it's ready to go.  In addition, you can do more fine tuning of some
parameters such as start_threshold in the above via
snd_pcm_sw_params().  This is an optional action.

Once after snd_pcm_hw_params() is done, you can start the stream via
snd_pcm_start() explicitly for the capture stream.  For the playback
stream, usually the automatic start via a proper start_threshold is
used.


Well, a graphical diagram would be good to explain such a thing.
We can put it to Wiki.  Any taker, please?


Takashi

Re: When to start the capture device?

[Takashi Iwai]

At Thu, 20 Sep 2007 10:14:27 -0400,
J. Scott Merritt wrote:
> 
> On Wed, 19 Sep 2007 16:17:55 -0700
> "Sheng \(Sean\) Liu" <shengl@uci.edu> wrote:
> 
> 
> > 1. The control point here the start threshold, which defines the number of
> > frames of space/data necessary to start the device automatically. If set to
> > some value other than zero for playback, it is necessary to prefill the
> > playback buffer before the device will start. If set to zero, the first data
> > written to the device (or first attempt to read from a capture stream) will
> > start the device. 
> >  
> > My question: what does he means on " If set to zero"? Does anyone know which
> > parameter of which API should be set to zero?
> 
> I believe this would be snd_pcm_sw_params_set_start_threshold.
>  
> > 2. You can also start the device explicitly using snd_pcm_start, but this
> > requires buffer prefilling in the case of the playback stream. If you
> > attempt to start the stream without doing this, you will get -EPIPE as a
> > return code, indicating that there is no data waiting to deliver to the
> > playback hardware buffer.
> >  
> > My question: Is there anything to be done before calling snd_pcm_start in
> > the case of capturing stream? If there is, what are they?
> 
> I use:
>    snd_pcm_open
>    SetUpHwParams ()  ... /* lots of snd_pcm_hw_params_set ... calls */
>    SetUpSwParams () ...  /* lots of snd_pcm_sw_params_set ... calls */
>    snd_pcm_prepare
>    snd_pcm_start

snd_pcm_prepare() can be omitted in this case.  After
snd_pcm_hw_params(), the stream is set to PREPARED state.  This isn't
changed after snd_pcm_sw_params(), too.

snd_pcm_prepare() is required to recover the stream from XRUN or any
other errors.  But, for the recovery purpose, we have now
snd_pcm_recover() as a generic solution, too.


Takashi

Re: When to start the capture device?

[J. Scott Merritt]

On Thu, 20 Sep 2007 16:23:30 +0200
Takashi Iwai <tiwai@suse.de> wrote:

> snd_pcm_prepare() is required to recover the stream from XRUN or any
> other errors.  But, for the recovery purpose, we have now
> snd_pcm_recover() as a generic solution, too.

It appears that (currently) the additional benefit of snd_pcm_recover
is simply that of resuming the stream.  However, I haven't seen any
details on when/why a stream would become suspened and require this
type of recovery.

Also, in SALSA, it appears that snd_pcm_recover can -block- even if
the stream has been configured for non-blocking behavior.

Re: When to start the capture device?

[Sheng (Sean) Liu]

Hi Mr. Iwai,

Thanks for your replies. I have another question for you.

After snd_pcm_start() is called, how long the first frame will be generated
by the sound card? Does this duration vary in different nodes (support
hardware+soundcard+OS are identical for all nodes)? If the duration is not a
constant, do you have any idea what will be the largest jitter?

This jitter matters so much for my location detection application.  After
the application starts, an user claps his/her hand. Then, the position of
the user is calculated from the application. 

I have four VIA EPIA-M+Linux2.6 machines. A global time is setup among these
four nodes. After the stream is started, the application detects a hand-clap
sound and counts the number of frames from the stream start to the clap
moment in each node. If I cannot have an accurate timestamp for the stream
start, the application cannot caculate the clap sound timestamp accurately.

Thanks,

Sheng

Re: When to start the capture device?

[Takashi Iwai]

At Thu, 20 Sep 2007 11:46:12 -0400,
J. Scott Merritt wrote:
> 
> On Thu, 20 Sep 2007 16:23:30 +0200
> Takashi Iwai <tiwai@suse.de> wrote:
> 
> > snd_pcm_prepare() is required to recover the stream from XRUN or any
> > other errors.  But, for the recovery purpose, we have now
> > snd_pcm_recover() as a generic solution, too.
> 
> It appears that (currently) the additional benefit of snd_pcm_recover
> is simply that of resuming the stream.  However, I haven't seen any
> details on when/why a stream would become suspened and require this
> type of recovery.

The audio apps (or system) usually want to know when the stream is
stopped unexpectedly.  The suspend/resume is exactly as same as XRUN
from this perspective.  That's why it's handled by the application.
snd_pcm_recover() is provided to handle it more easily.

> Also, in SALSA, it appears that snd_pcm_recover can -block- even if
> the stream has been configured for non-blocking behavior.

It's with ALSA-lib, too.  The snd_pcm_recover() code is identical in
both libraries.  This is the function that may block regardless what
mode you use.

The non-blocking mode isn't specified for ioctls but for
read/write in general.  In theory, the normal snd_pcm_prepare() could
block (take some time) if the driver is implemented in such a way.


Takashi

Re: When to start the capture device?

[Takashi Iwai]

At Thu, 20 Sep 2007 15:10:12 -0700,
Sheng (Sean) Liu wrote:
> 
> Hi Mr. Iwai,
> 
> Thanks for your replies. I have another question for you.
> 
> After snd_pcm_start() is called, how long the first frame will be generated
> by the sound card? Does this duration vary in different nodes (support
> hardware+soundcard+OS are identical for all nodes)? If the duration is not a
> constant, do you have any idea what will be the largest jitter?
> 
> This jitter matters so much for my location detection application.  After
> the application starts, an user claps his/her hand. Then, the position of
> the user is calculated from the application. 
> 
> I have four VIA EPIA-M+Linux2.6 machines. A global time is setup among these
> four nodes. After the stream is started, the application detects a hand-clap
> sound and counts the number of frames from the stream start to the clap
> moment in each node. If I cannot have an accurate timestamp for the stream
> start, the application cannot caculate the clap sound timestamp accurately.

Then it's rather a question about RT-OS.  Once after entering the
ioctl syscall of kernel, and if the device is exclusive (no multiple
substreams), the latency is almost deterministic on preempt kernel.
Mostly the latency of the hardware is the issue.  But, the problem is
the latency before entring the kernel.  This can be (a kind of)
guaranteed only with RT-task running on RT-kernel.


Takashi

Re: When to start the capture device?

[Sheng (Sean) Liu]

Hi Mr. Iwai,

Thanks for your info. We are now thinking that we should take the timestamp
of starting the device inside the kernel. The place to take this timestamp
should be as close as to hardware, which means, it should be taken right
after the device driver sets a hardware pin to start the device. Do you
think the approach is correct? If it is feasible, do you know where is the
exact position (setting the hardware pin) inside the kernel to take the
timestamp? (The sound card driver module is snd_via82xx)

Thanks,

Sheng

-----Original Message-----
From: Takashi Iwai [mailto:tiwai@suse.de] 
Sent: Friday, September 21, 2007 9:25 AM
To: Sheng (Sean) Liu
Cc: alsa-devel@alsa-project.org
Subject: Re: [alsa-devel] When to start the capture device?


At Thu, 20 Sep 2007 15:10:12 -0700,
Sheng (Sean) Liu wrote:
> 
> Hi Mr. Iwai,
> 
> Thanks for your replies. I have another question for you.
> 
> After snd_pcm_start() is called, how long the first frame will be 
> generated by the sound card? Does this duration vary in different 
> nodes (support
> hardware+soundcard+OS are identical for all nodes)? If the duration is 
> hardware+soundcard+not a
> constant, do you have any idea what will be the largest jitter?
> 
> This jitter matters so much for my location detection application.  
> After the application starts, an user claps his/her hand. Then, the 
> position of the user is calculated from the application.
> 
> I have four VIA EPIA-M+Linux2.6 machines. A global time is setup among 
> these four nodes. After the stream is started, the application detects 
> a hand-clap sound and counts the number of frames from the stream 
> start to the clap moment in each node. If I cannot have an accurate 
> timestamp for the stream start, the application cannot caculate the 
> clap sound timestamp accurately.

Then it's rather a question about RT-OS.  Once after entering the ioctl
syscall of kernel, and if the device is exclusive (no multiple substreams),
the latency is almost deterministic on preempt kernel. Mostly the latency of
the hardware is the issue.  But, the problem is the latency before entring
the kernel.  This can be (a kind of) guaranteed only with RT-task running on
RT-kernel.


Takashi