[alsa-devel] POSIX clocks and ALSA
Takashi Iwai
tiwai at suse.de
Mon Nov 26 14:49:51 CET 2007
At Mon, 26 Nov 2007 14:04:47 +0100 (CET),
Jaroslav Kysela wrote:
>
> On Mon, 26 Nov 2007, Heikki Lindholm wrote:
>
> > Takashi Iwai kirjoitti:
> > > At Mon, 26 Nov 2007 09:59:29 +0200,
> > > Heikki Lindholm wrote:
> > > > Jaroslav Kysela kirjoitti:
> > > > > On Mon, 26 Nov 2007, Heikki Lindholm wrote:
> > > > >
> > > > > > Hello,
> > > > > >
> > > > > > Some years ago there was some talk about UST support in
> > > > > > Linux, but the support never happened. With the hrtimers
> > > > > > patch (and I'm not quite sure if even earlier?)
> > > > > > CLOCK_MONOTONIC would seem like a fairly good UST time
> > > > > > source. What I'd like to see, is a selectable clock for ALSA
> > > > > > timestamping, e.g. something like snd_sw_params_clock(...,
> > > > > > clockid_t clk). Would this seem plausible? I don't know that
> > > > > > much about ALSA internals, so, no idea whether different
> > > > > > clocks on different pcms/whatever would quickly turn into an
> > > > > > unmanageable mess.
> > > > > We are aware about this extension and I already proposed an
> > > > > implementation. I hope to implement it soon. Timestamps are not
> > > > > used in driver internally.
> > > > I can't seem to google up the proposal. I'd like to read it; was it
> > > > on the alsa ml?
> > >
> > > Yes, it was on alsa-devel ML. At that time I didn't like the proposal
> > > much because currently there was no real user of timestamps.
> > >
> > > The addition of monolithc clock isn't hard, but it's an API change
> > > that involves with the kernel-side change. So let's do it carefully.
> > >
> > > But, honestly, I'm still concerned what to be done first. Shouldn't
> > > we discuss about the usefulness of the timestamp at first? That is,
> > > whether the current form (API, implementation) is the best or not,
> > > what kind of user would be, and how it's used. So far, this feature
> > > is "simply there"...
> >
> > IMHO the current API definitely isn't the best possible, but nothing
> > better has been available on Linux, so it's a make-do situation. My
> > ideal would be something resembling or even 1:1 copying SGI's media
> > libraries where every media fragment is timestamped with the UST, and
> > the timestamps are the starting time of the media chunk in question
> > instead of ending/sometime after time. The problem with implementing the
> > SGI API on Linux is that AFAICT no Linux supported/available hardware
> > supports such timestamping.
>
> Unfortunately, we are not using audio "packets" at the moment, but
> basically, it shouldn't be difficult to implement - think one period ==
> one packet.
Yes. About the sync accuracy, this should be fine enough.
> > Additionally, it might be nice to be able to add audio clocks as system
> > wide clocks, so, that for example I could tell v4l to use timestamps
> > from an audio clock instead of the system clock.
>
> It's something I don't like. If you have multiple soundcards, it might be
> problematic to select a proper audio device for sync.
But, OTOH, the audio-video-sync is more popular demand than multiple
card sync. This might be a good working example for timestamping.
I remember I discussed about it a bit with Mauro. Nnow Cc'ed, in
case he has more comments on V4L/sound sync issue.
One possible problem is that the current ALSA timestamp API provides
only volatile reads, i.e. the timestamp is being constantly updated
and not logged/streamed coupled with the data.
That's the reason I suggested to consider the API again. We should
check the use case at first...
thanks,
Takashi
More information about the Alsa-devel
mailing list