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

[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*
  +1 (510) 388 1413


On Tue, Oct 14, 2014 at 5:58 PM, Tim Cussins <timcussins at eml.cc> wrote:

> Hi Nick,
>
> On Tue, Oct 14, 2014, at 04:31 PM, Nick Stoughton wrote:
> > 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... :)
>
> > 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*
> >   +1 (510) 388 1413
> > _______________________________________________
> > Alsa-devel mailing list
> > Alsa-devel at alsa-project.org
> > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel at alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>