[alsa-devel] When to start the capture device?
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
On Wed, 19 Sep 2007 16:17:55 -0700 "Sheng (Sean) Liu" shengl@uci.edu wrote:
- 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.
- 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.
On Wed, 19 Sep 2007 16:17:55 -0700 "Sheng (Sean) Liu" shengl@uci.edu wrote:
- 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.
- 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.
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:
- 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.
- 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
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.
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
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.
- 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().
- 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
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
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
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
participants (4)
-
J. Scott Merritt -
J. Scott Merritt -
Sheng (Sean) Liu -
Takashi Iwai