[RFC] provide a simple mechanism to start playback at a given time

[Nick Stoughton]

As discussed at today's meeting, please find 2 patches (one to the 3.17
kernel, the other to alsa-lib) following this that implement a simple
interface to trigger playback at a given point in the future.

The API provides an absolute time, measured against a given clock, at which
to trigger DMA. If the point in the future appears to be less than 100ms
away, we fall back to the standard snd_pcm_start() behavior. This is
because this interface is designed to support networked devices
playing back in sync, and network latencies are likely to be over 100ms.
This value should probably be tunable ...

Also, we simply set up a timer and commence DMA when it expires. If the
devices to be synchronized have identical hardware, then there is no
problem. A future enhancement is to estimate the latency between the DMA
trigger and the codec driver (FIFO sizes etc) so that we can take that into
account.

Any comments gratefully accepted!
*______________________________*
*Nick Stoughton*
*Aether Things Inc *
*San Francisco*
[phone]

[Tim Cussins]

Hi Nick,

Post by Nick Stoughton
As discussed at today's meeting, please find 2 patches (one to the 3.17
kernel, the other to alsa-lib) following this that implement a simple
interface to trigger playback at a given point in the future.
The API provides an absolute time, measured against a given clock, at which
to trigger DMA. If the point in the future appears to be less than 100ms
away, we fall back to the standard snd_pcm_start() behavior. This is
because this interface is designed to support networked devices
playing back in sync, and network latencies are likely to be over 100ms.
This value should probably be tunable ...

I'm a little wary of baked in thresholds like this, esp one in an API
that isn't explicitly network oriented: In this case it's a policy
decision that should be left to the application. Maybe pass the
threshold as an argument?

My general preference is to keep the API contract simple and
unsurprising. I would just return an error if the request can't be
satisfied, for example if the timestamp is in the past, or too soon.
Failure shouldn't be information we hide from the application... :)

Post by Nick Stoughton
Also, we simply set up a timer and commence DMA when it expires. If the
devices to be synchronized have identical hardware, then there is no
problem. A future enhancement is to estimate the latency between the DMA
trigger and the codec driver (FIFO sizes etc) so that we can take that into
account.
Any comments gratefully accepted!
*______________________________*
*Nick Stoughton*
*Aether Things Inc *
*San Francisco*
[phone]
_______________________________________________
Alsa-devel mailing list
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

[Nick Stoughton]

I agree with these points in general. I will change the function to fail
(EINVAL) if the timestamp is in the past, but permit arbitrarily small
future times (which seems preferable to passing in an extra parameter to
something that can easily be checked in user space).

*______________________________*
*Nick Stoughton*
*Aether Things Inc *
*San Francisco*
[phone]

Post by Tim Cussins
Hi Nick,

Post by Nick Stoughton
As discussed at today's meeting, please find 2 patches (one to the 3.17
kernel, the other to alsa-lib) following this that implement a simple
interface to trigger playback at a given point in the future.
The API provides an absolute time, measured against a given clock, at which
to trigger DMA. If the point in the future appears to be less than 100ms
away, we fall back to the standard snd_pcm_start() behavior. This is
because this interface is designed to support networked devices
playing back in sync, and network latencies are likely to be over 100ms.
This value should probably be tunable ...

I'm a little wary of baked in thresholds like this, esp one in an API
that isn't explicitly network oriented: In this case it's a policy
decision that should be left to the application. Maybe pass the
threshold as an argument?
My general preference is to keep the API contract simple and
unsurprising. I would just return an error if the request can't be
satisfied, for example if the timestamp is in the past, or too soon.
Failure shouldn't be information we hide from the application... :)

Post by Nick Stoughton
Also, we simply set up a timer and commence DMA when it expires. If the
devices to be synchronized have identical hardware, then there is no
problem. A future enhancement is to estimate the latency between the DMA
trigger and the codec driver (FIFO sizes etc) so that we can take that into
account.
Any comments gratefully accepted!
*______________________________*
*Nick Stoughton*
*Aether Things Inc *
*San Francisco*
[phone]
_______________________________________________
Alsa-devel mailing list
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

_______________________________________________
Alsa-devel mailing list
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel