On Thursday 20 June 2002 16.37, Juan Linietsky wrote: > On Thu, 20 Jun 2002 11:43:46 +0100 > > dunk fordyce <[EMAIL PROTECTED]> 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 -'
