Subject: [linux-audio-dev] rtcd vs hz > 100!
From: est_AT_hyperreal.org
Date: ke loka 27 1999 - 16:04:25 EDT
Paul Barton-Davis discourseth:
> In message <19991027163649.18977.qmail_AT_hyperreal.org>you write:
> >[ I want to use /dev/rtc, but the idea that my app would block any
> > other app from using it bugs me. Thus, this. -est :]
>
> nice piece of work,
:D
> except this:
doh!
> we want to be able to use the /dev/rtcd connection semantically just like
> /dev/rtc, which means we should be able to get periodic "interrupts"
> from the daemon. the way this is written makes it sound as if the
> client *has* to always write back its "next wakeup time" every time it
> is woken by the daemon.
Yes. The design actually started out handling periodic interrupts.
Then I think I got fascinated with how minimalist I could get. :)
> thats ok for apps that want to use the rtcd as a non-periodic timing
> source, but there needs to be support for a client to say "wake me
> every N <unit of time>". this will help us minimize the client-daemon
> traffic and work done by the client.
OK.
> i would suggest that unit of time be milliseconds, specified as a
> uint16. thus, the request "packet" is now:
>
> #define RTCD_PERIODIC_REQUEST 1
> #define RTCD_ONESHOT_REQUEST 2
>
> struct rtcd_request {
> unsigned char rtcd_type;
> union {
> struct timespec when;
> uint16 interval_msecs;
> } rtcd_r;
> };
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
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:59 EST