Subject: Re: [linux-audio-dev] rtcd vs hz > 100!
From: Benno Senoner (sbenno_AT_gardena.net)
Date: ke loka 27 1999 - 18:03:49 EDT
On Wed, 27 Oct 1999, est_AT_hyperreal.org wrote:
> Paul Barton-Davis discourseth:
>
> Hmm! I'm worried that milliseconds may end up too constraining.
> Also, one-shots with absolute times seems more reliable to me since it
> factors out the time to get the request to rtcd.
>
> Also, clients should probably be able to query the rtc rate..unless we
> do standardize on milliseconds, in which case things stay simpler. :)
>
> > in addition, i'd suggest that a client cancels a periodic request
> > with:
> >
> > req.rtcd_type = RTCD_PERIODIC_REQUEST;
> > req.rtcd_r.interval_msecs = 0;
>
> Heh..`note-off'.
>
> There's one idea I'm afraid to mention since I think *you'll* probably
> want it! :) rtcd could (optionally) signal pthread condition variables
> in shared memory.
>
> > this will be an exciting addition to our pantheon of "tools to make
> > cool applications". are you going to volunteer to write it as well ?
>
> I actually wrote the design a couple of months ago. I've been holding
> off on it because I was hoping HZ > 100 would take the day. Now, I'm
> of the feeling that even if a music distro does that, redhat/suse/etc
> won't..not for a while anyway. So, yeah, I volunteer..unless this
> thread talks me out of it. :)
>
> Eric
My suggestion is to use "struct timeval" to deal with time related isssues,
just as usleep() does:
In the meantime we will not provide the microsecond resolution,
but we let the user query the timer granularity, that means
if one uses 8192 RTC = 125usec granularity, or the UTIME patches will
get into the mainstream kernel, we are ready for the high precision timing !
Do we all agree no this ?
Benno.
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:28:00 EST