Re: [linux-audio-dev] timing

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] timing
From: David Olofson (david_AT_gardena.net)
Date: Fri Jun 21 2002 - 17:16:08 EEST


On Thursday 20 June 2002 16.37, Juan Linietsky wrote:
> On Thu, 20 Jun 2002 11:43:46 +0100
>
> dunk fordyce <mailinglist_AT_dunkfordyce.co.uk> wrote:
> > whats the best way to handle timing in a music app?
>
> I use /dev/rtc in shaketracker, It works very well, but the problem
> with it is that
> it cant be shared between apps (Athought i'm working on a patch
> that would enable it to be shared).

Great! I've been thinking about doing that as well. (For non-audio
stuff - which is why I got the idea. I didn't want my little project
to conflict with audio apps also wanting to use the RTC.)

I've also considered implementing the sharing in user space. How
about a library that implements an API similar to the multimedia
timers of Win32?

> Still, unless your app is root, you cant have a latency over 64hz,
> so for an userspace app,
> it's actually worse than the system timer (10ms)

Yeah... Why 64 Hz, when some platforms have HZ = 1000 or 1024 by
default, and other drivers are capable of producing much higher IRQ
frequencies? IMHO, this value is obsolete, and should be changed to
1024, at least.

Either way, with the user space lib solution for RTC sharing, one
could avoid this issue by using a root/CAP_RESOURCE daemon to program
the RTC frequency. No kernel hack needed. (Or am I missing something?)

Of cource, such a library could also be ported to whatever timer
implementation you like, including mmtimers or Win32, if anyone
cares. :-) (In fact, on platforms that have a usable timer API with
sharing, the "port" doesn't even need a lib. A wrapper header would
be sufficient.)

> I also did some experiments of other approaches, SIGALRM works very
> well (better than polling
> from what I tried, which skips a lot more).

Probably because signals are *slightly* closer to interrupts than
blocking methods, such as poll()...

> So far, I've also had
> some success for reducing
> latency by starting 20 threads constanty polling and updating the
> timer.

Uuurgh! :-D

[...]
> > i have been looking at tracker code but havent got any solid
> > ideas.
>
> Normal trackers (unless you mean shaketracker/tektracker) use
> the audio interrupt through blocking calls. It is a vaid approach
> to use those as timers,

Yes, and it sort of gives you internal audio/MIDI sync for free. You
just have to figure out what N samples mean in MIDI time.

> and it's the most common way one under
> windows.

Are you sure about that? (I don't read much Win32 source these days -
and there isn't much source available to read anyway... *heh*)

AFAIK, all major audio/MIDI sequencer apps on Win32 still use
mmtimers for MIDI-only projects, and I'm quite sure they use them
even with audio, since there's no way audio timing can match the
accuracy of the commonly used 1 kHz mmtimer rate.

> Still, I dont think it's a very clean.

I agree. Audio timing is fine for very low latency apps running on
Linux/lomlatency (ie > 1k fragments/s), but that's about it. You
can't use that kind of fragment sizes in other environments, and less
than 1 kHz "MIDI driver clock" degrades MIDI timing accuracy quite
substantially.

//David

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
`---------------------------> http://www.linuxdj.com/maia/ -'
.- David Olofson -------------------------------------------.
| Audio Hacker - Open Source Advocate - Singer - Songwriter |
`-------------------------------------> http://olofson.net -'


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Fri Jun 21 2002 - 17:28:15 EEST