[LAD] Timers, hpet, hrtimer -> kind of solved (for too old motherboards)
warjamy at yahoo.com
Tue Nov 10 14:14:10 UTC 2009
The alsa-lib source package comes with some test programs. One is called timer.c and can be compiled as well if you locally compile alsa-lib (no need to install, just compile):
then, you can see what you have:
and test some of them
./timer class=1 card=0 device=3 # that's the high res timer used by ALSA
(well, replace card by what makes sense to you, I personally do not have a hw:0, I reserve hw:0 for the onboard chip, which I disabled in the BIOS, so I use card=1, which is my PCI card).
class, sclass, device, etc are defined in the ALSA lib API doc.
class=1 is I think GLOBAL
sclass=-1 is slave class = NONE I think (not in front of the API doc).
device=3 seems to confirm what Clemens said about kernel reserved timers.
(when you list the timers with ./timer list, the GLOBAL ones will show up with a card=-1. Yet, to test them as I indicated above, you will need to invoke ./timer with card=X with X = some valid card index).
For the group permission, I am not sure this is needed. I did that because of some permission issue message I saw a long time ago. Not sure if this is relevant. Since I compiled my kernel with HR timer as default for ALSA, I guess all is fine, I do not need to invoke jackd with -ch, the hpet timer is used by default.
On the other hand, when I set rosegarden to use the HR timer, I get a complete total freeze of my system, nothing works at all, not even connecting to the machine remotely via LAN. Not sure what is going on here.
--- On Tue, 11/10/09, hollunder at gmx.at <hollunder at gmx.at> wrote:
> From: hollunder at gmx.at <hollunder at gmx.at>
> Subject: Re: [LAD] Timers, hpet, hrtimer -> kind of solved (for too old motherboards)
> To: linux-audio-dev at lists.linuxaudio.org
> Date: Tuesday, November 10, 2009, 8:40 AM
> On Tue, 10 Nov 2009 12:48:42 +0100
> Clemens Ladisch <clemens at ladisch.de>
> > hollunder at gmx.at
> > > $ dmesg | grep -i hpet
> > > Kernel command line:
> > >
> > > hpet=force pci 0000:00:11.0: Failed to force
> enable HPET
> > >
> > > /dev/hpet was still created,
> > Then you have it. The message is probably
> because it doesn't need
> > to be forced.
> I added hpet=force because I found a line in dmesg that
> something along the lines of: hpet isn't available, try
> > See /proc/iomem at address fed00000.
> cat /proc/iomem | grep -i fed00000 -> Nothing
> > It's possible that your log buffer is too small and
> that the earlier
> > HPET messages were lost. Do you have more
> HPET-releated messages
> > in /var/log/messages or /var/log/syslog?
> cat /var/log/messages.log | grep -i hpet only found the
> kernel command
> cat /var/log/syslog.log | grep -i hpet didn't find
> > > but when I changed its group and told jack to use
> it I got:
> > > This system has no accessible HPET device (Device
> or resource busy)
> > "Busy" means that it's there, but already being
> used. Many
> > motherboard BIOSes do not initialize the third HPET
> interrupt, and
> > the first two are taken by the kernel.
> > Best regards,
> > Clemens
> Thanks a lot Clemens, but I'm still not sure what the issue
> is or how
> to solve it.
> Linux-audio-dev mailing list
> Linux-audio-dev at lists.linuxaudio.org
More information about the Linux-audio-dev