[LAU] /dev/hpet, depends on kernel?

[Jonathan E. Brickman]

>> Should CONFIG_HPET_EMULATE_RTC be set to n on a realtime kernel?  Is
>> there something else which might invalidate CONFIG_HPET=y ?
>>      
> the RTC device is unrelated to HPET. your kernel can have HPET support
> but if your h/w doesn't, you don't get /dev/hpet. My motherboard, for
> example, does not have an HPET device.
>    

That is interesting.  I am interested principally because I'm seeing 
xruns and am hunting for causes, and that stood out.

Checked the BIOS; HPET is there, already turned on.  Running the 
vanilla-install Debian Testing (AMD64) kernel, package 
"linux-image-2.6.30-2-amd64" version 2.6.30-8, I do have a /dev/hpet.  
Running any of six or seven slightly different but very clean rtlinux 
builds (vanilla kernel source of 2.6.31.6, plus rtlinux 
patch-2.6.31.6-rt19.bz2), .config options verified and reverified very 
carefully, I don't have a /dev/hpet.  Anything I should check?  Do you 
think I should get on a kernel dev list?

But I understand now that hpet may have little or nothing to do with the 
xrun problem.  At least part of the symptomatology, is that Pulse 
talking to Jack on 64-bit Debian Testing / Gnome with GUI sound events 
off, seems to eat a whole lot more of Jack's DSP capacity than the same 
combination on 32-bit / LXDE.  On 32-bit, Pulse at idle ate zero CPU; 
now on 64-bit, Pulse at idle is eating about 2%.  I'm wondering right 
this minute if Gnome keeps its default sound open, delivering full-bore 
(albeit silent) audio even when it's told not to do so.

I suppose I'll try LXDE.  But any suggestions will be very much appreciated.

J.E.B.