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. > 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. Jaroslav ----- Jaroslav Kysela <perex@xxxxxxxx> Linux Kernel Sound Maintainer ALSA Project _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
