From mboxrd@z Thu Jan 1 00:00:00 1970 From: Heikki Lindholm Subject: Re: POSIX clocks and ALSA Date: Mon, 26 Nov 2007 10:42:46 +0200 Message-ID: <474A8706.1070102@cs.helsinki.fi> References: <474A763E.7090001@cs.helsinki.fi> <474A7CE1.7080904@cs.helsinki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from emh07.mail.saunalahti.fi (emh07.mail.saunalahti.fi [62.142.5.117]) by alsa0.perex.cz (Postfix) with ESMTP id F3BD324797 for ; Mon, 26 Nov 2007 09:42:48 +0100 (CET) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: alsa-devel-bounces@alsa-project.org Errors-To: alsa-devel-bounces@alsa-project.org To: Takashi Iwai Cc: alsa-devel@alsa-project.org List-Id: alsa-devel@alsa-project.org 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. 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. Allowing clock selection between CLOCK_REALTIME (for backwards compatibility) and CLOCK_MONOTONIC would, however, be a start. -- Heikki Lindholm