Re: [alsa-devel] When to start the capture device?

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