Philipp, 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):
cd alsa-lib-xxx ./configure make cd test make timer then, you can see what you have: ./timer list 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. J. --- On Tue, 11/10/09, [email protected] <[email protected]> wrote: > From: [email protected] <[email protected]> > Subject: Re: [LAD] Timers, hpet, hrtimer -> kind of solved (for too old > motherboards) > To: [email protected] > Date: Tuesday, November 10, 2009, 8:40 AM > On Tue, 10 Nov 2009 12:48:42 +0100 > Clemens Ladisch <[email protected]> > wrote: > > > [email protected] > wrote: > > > $ dmesg | grep -i hpet > > > Kernel command line: > > > > root=/dev/disk/by-uuid/3e47466f-5ca1-499b-85fc-152074f36364 > ro > > > 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 > said > something along the lines of: hpet isn't available, try > hpet=force > > > 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 > line > cat /var/log/syslog.log | grep -i hpet didn't find > anything > > > > 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. > > Regards, > Philipp > _______________________________________________ > Linux-audio-dev mailing list > [email protected] > http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev > _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
