Re: [LAD] Timers, hpet, hrtimer

> 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@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Tue Nov 10 20:15:02 2009