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, hollunder(a)gmx.at <hollunder(a)gmx.at> wrote:
From: hollunder(a)gmx.at <hollunder(a)gmx.at>
Subject: Re: [LAD] Timers, hpet, hrtimer -> kind of solved (for too old motherboards)
To: linux-audio-dev(a)lists.linuxaudio.org
Date: Tuesday, November 10, 2009, 8:40 AM
On Tue, 10 Nov 2009 12:48:42 +0100
Clemens Ladisch <clemens(a)ladisch.de>
wrote:
hollunder(a)gmx.at
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
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev