> Since hrtimer uses hpet if available and apps use hrtimer, why would I > need to allow some audio group to access hpet directly?
Because it offers memory-mappable access to the actual timer hardware, significantly lowering overhead and latency for reading the value. > This system has no accessible HPET device (Device or resource busy) > > My interpretation of this is that my motherboard is simply too old and > simply doesn't have a hpet timer. This is typically because the device is busy - fully reserved already. The reason for this is typically because the device driver in kernel is broken. And still not fixed? HPET timer has one global time counter, which is the one JACK is interested in, and in addition three programmable sub-timers. The problem is that mapping the HPET device also reserves one of these sub-timers per mapping. Usually kernel is using one and two are left free, this usually allows JACK daemon and one client to be started before running out of those timers. Brokenness is that JACK is not interested on those sub-timers and the driver should allocate those only via corresponding ioctl() and give unlimited read access to the global timer value without failing early... Someone promised to fix the driver, but I haven't verified recently if it has been fixed. If not, maybe I have to add that to my TODO-list... BR, - Jussi _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev