[LAD] timers

Hi
I'm confused about all the timers.
There is:
- system timer
- hpet (high precision event timer)
- hr-timer (high resolution timer)
- rtc (real time clock)
- cyclic (what's that? a coded loop?)
- anything else ?
What is the relation of all these ?
Which hardware devices are actually used by those ?
Which is the prefered timer for sequencing ? hr-timer / rtc ?
Some timers can be opened only once ?
For example if jackdbus is using hr-timer, no other application can too ?
But applications need to use the same timer in order to sync - right ?
Which concepts exist to share a certain timer ?
How to verify if a timer is working ?
Is there tool that would help ?
Opening the hr-timer with rosegarden freezes my whole system here,
what could cause that ?
Thanks
Related to my sytem:
I get:
------
$ lsmod | grep rtc
rtc_cmos 9680 0
rtc_core 16784 1 rtc_cmos
rtc_lib 2844 1 rtc_core
But the following command doesn't list any rtc-timer (is that
expected, what to do ?):
-------------------------------------------------------------
$ cat /proc/asound/timers
G0: system timer : 1000.000us (10000000 ticks)
G3: HR timer : 0.001us (1000000000 ticks)
Client sequencer queue 2 : running
Client sequencer queue 0 : running
P0-0-0: PCM playback 0-0-0 : SLAVE
P0-0-1: PCM capture 0-0-1 : SLAVE
P0-1-0: PCM playback 0-1-0 : SLAVE
P0-2-1: PCM capture 0-2-1 : SLAVE
P1-3-0: PCM playback 1-3-0 : SLAVE
P2-0-0: PCM playback 2-0-0 : SLAVE
P2-0-1: PCM capture 2-0-1 : SLAVE
P5-0-1: PCM capture 5-0-1 : SLAVE
$ ls /dev/rtc* -lh
lrwxrwxrwx 1 root root 4 2009-11-05 17:13 /dev/rtc -> rtc0
crw-rw---- 1 root audio 251, 0 2009-11-05 17:13 /dev/rtc0
$ uname -a
Linux 2.6.31-rt11-e1 #1 SMP PREEMPT RT Oct 27 CET 2009 i686 GNU/Linux Debian
--
E.R.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Emanuel Rumpf wrote:
> Hi
>
> I'm confused about all the timers.
>
> There is:
> - system timer
> - hpet (high precision event timer)
> - hr-timer (high resolution timer)
> - rtc (real time clock)
> - cyclic (what's that? a coded loop?)
> - anything else ?
>
>
> What is the relation of all these ?
> Which hardware devices are actually used by those ?
> Which is the prefered timer for sequencing ? hr-timer / rtc ?
>
If hardware is fine with Linux real-time audio, if I understand
correctly, the preferred timer for MIDI sequencers is (should be) system
timer at ! 1000 Hz ! For my hardware, that has got problems with
real-time audio, it's PCM playback and PCM capture. Using this timers
MIDI jitter will decrease a little bit.
This is the output I get for 64 Studio 3.0-beta3:
spinymouse-sudo@64studio:~$ cat /proc/asound/timers
G0: system timer : 1000.000us (10000000 ticks)
P0-0-0: PCM playback 0-0-0 : SLAVE
P0-0-1: PCM capture 0-0-1 : SLAVE
Client sequencer queue 0 : stopped
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Hi guys,
Here is what I have:
$ cat /proc/asound/timers
G0: system timer : 1000.000us (10000000 ticks)
G3: HR timer : 0.001us (1000000000 ticks)
Client sequencer queue 0 : running
P1-0-0: PCM playback 1-0-0 : SLAVE
P1-0-1: PCM capture 1-0-1 : SLAVE
Ralf, you do not benefit from a high res timer. See how much more precise t=
he HR timer is from the output above. Check which snd timer you have loaded:
$ lsmod | grep timer
snd_hrtimer 2148 1
snd_timer 17408 3 snd_hrtimer,snd_seq,snd_pcm
Of course, your h/w should have a HR timer:
$ ll /dev/hpet
crw-rw---- 1 root audio 10, 228 2009-11-05 12:59 /dev/hpet
you can specify the clock source to jackd:
$ jackd --help
...
[ --clocksource OR -c [ c(ycle) | h(pet) | s(ystem) ]
...
J.
--- On Sat, 11/7/09, Ralf Mardorf wrote:
> From: Ralf Mardorf
> Subject: Re: [LAD] timers
> To: "Emanuel Rumpf"
> Cc: linux-audio-dev@lists.linuxaudio.org
> Date: Saturday, November 7, 2009, 7:04 AM
> Emanuel Rumpf wrote:
> > Hi
> >
> > I'm confused about all the timers.
> >
> > There is:
> > - system timer
> > - hpet (high precision event timer)
> > - hr-timer (high resolution timer)
> > - rtc (real time clock)
> > - cyclic (what's that? a coded loop?)
> > - anything else ?
> >
> >
> > What is the relation of all these ?
> > Which hardware devices are actually used by those ?
> > Which is the prefered timer for sequencing ? hr-timer
> / rtc ?
> >=A0=A0=A0
> =
> If hardware is fine with Linux real-time audio, if I
> understand =
> correctly, the preferred timer for MIDI sequencers is
> (should be) system =
> timer at ! 1000 Hz ! For my hardware, that has got problems
> with =
> real-time audio, it's PCM playback and PCM capture. Using
> this timers =
> MIDI jitter will decrease a little bit.
> =
> This is the output I get for 64 Studio 3.0-beta3:
> =
> spinymouse-sudo@64studio:~$ cat /proc/asound/timers
> G0: system timer : 1000.000us (10000000 ticks)
> P0-0-0: PCM playback 0-0-0 : SLAVE
> P0-0-1: PCM capture 0-0-1 : SLAVE
> =A0 Client sequencer queue 0 : stopped
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
> =
=
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

I forgot to add that snd_hrtimer is used by jackd.
If I turn jackd off, the snd_hrtimer module is not used:
$ lsmod | grep timer
snd_hrtimer 2148 0 ## Subject: Re: [LAD] timers
> To: "Emanuel Rumpf" , "Ralf Mardorf"
> Cc: linux-audio-dev@lists.linuxaudio.org
> Date: Saturday, November 7, 2009, 7:34 AM
> Hi guys,
> =
> Here is what I have:
> =
> =
> $ cat /proc/asound/timers
> G0: system timer : 1000.000us (10000000 ticks)
> G3: HR timer : 0.001us (1000000000 ticks)
> =A0 Client sequencer queue 0 : running
> P1-0-0: PCM playback 1-0-0 : SLAVE
> P1-0-1: PCM capture 1-0-1 : SLAVE
> =
> Ralf, you do not benefit from a high res timer. See how
> much more precise the HR timer is from the output above.
> Check which snd timer you have loaded:
> =
> $ lsmod | grep timer
> =
> snd_hrtimer=A0 =A0 =A0 =A0 =A0
> =A0=A0=A02148=A0 1
> snd_timer=A0 =A0 =A0 =A0 =A0 =A0 =A0
> 17408=A0 3 snd_hrtimer,snd_seq,snd_pcm
> =
> Of course, your h/w should have a HR timer:
> =
> $ ll /dev/hpet
> crw-rw---- 1 root audio 10, 228 2009-11-05 12:59 /dev/hpet
> =
> you can specify the clock source to jackd:
> =
> $ jackd --help
> ...
> [ --clocksource OR -c [ c(ycle) | h(pet) | s(ystem) ]
> ...
> =
> =
> =
> J.
> =
> =
> --- On Sat, 11/7/09, Ralf Mardorf
> wrote:
> =
> > From: Ralf Mardorf
> > Subject: Re: [LAD] timers
> > To: "Emanuel Rumpf"
> > Cc: linux-audio-dev@lists.linuxaudio.org
> > Date: Saturday, November 7, 2009, 7:04 AM
> > Emanuel Rumpf wrote:
> > > Hi
> > >
> > > I'm confused about all the timers.
> > >
> > > There is:
> > > - system timer
> > > - hpet (high precision event timer)
> > > - hr-timer (high resolution timer)
> > > - rtc (real time clock)
> > > - cyclic (what's that? a coded loop?)
> > > - anything else ?
> > >
> > >
> > > What is the relation of all these ?
> > > Which hardware devices are actually used by those
> ?
> > > Which is the prefered timer for sequencing ?
> hr-timer
> > / rtc ?
> > >=A0=A0=A0
> > =
> > If hardware is fine with Linux real-time audio, if I
> > understand =
> > correctly, the preferred timer for MIDI sequencers is
> > (should be) system =
> > timer at ! 1000 Hz ! For my hardware, that has got
> problems
> > with =
> > real-time audio, it's PCM playback and PCM capture.
> Using
> > this timers =
> > MIDI jitter will decrease a little bit.
> > =
> > This is the output I get for 64 Studio 3.0-beta3:
> > =
> > spinymouse-sudo@64studio:~$ cat /proc/asound/timers
> > G0: system timer : 1000.000us (10000000 ticks)
> > P0-0-0: PCM playback 0-0-0 : SLAVE
> > P0-0-1: PCM capture 0-0-1 : SLAVE
> > =A0 Client sequencer queue 0 : stopped
> > _______________________________________________
> > Linux-audio-dev mailing list
> > Linux-audio-dev@lists.linuxaudio.org
> > http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
> > =
> =
> =
> =A0 =A0 =A0 =
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
> =
=
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Thank you Emanuel for this thread :)
thank you James for the information :)
hopefully this might narrow down my trouble with MIDI jitter for
external equipment, OTOH I don't have any MIDI jitter for MIDI internal
Linux. ALSA MIDI and JACK MIDI seems to be fine what ever timer I use,
this means there is absolutely no jitter when using a Linux sequencer to
control a Linux synth. Jitter only occurs when using my USB MIDInterface
to control external MIDI equipment. Unfortunately I can't get my
Envy24's MPU working.
There seems to be no hrtimer available yet:
$ lsmod | grep snd_hrtimer
$ lsmod | grep timer
snd_timer 22024 2 snd_pcm,snd_seq
snd 63800 21
snd_ice1712,snd_ak4xxx_adda,snd_cs8427,snd_ac97_codec,snd_i2c,snd_mpu401_uart,snd_usb_audio,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_hwdep,snd_seq_oss,snd_rawmidi,snd_seq,snd_timer,snd_seq_device
$ uname -a
Linux 64studio 2.6.29-1-multimedia-amd64 #1 SMP PREEMPT RT Thu Feb 26
16:18:05 UTC 2009 x86_64 GNU/Linux
Before I start googleing. Is this a feature for 2.6.31 only? I'm still
not able to boot the .31 kernel-rt from the Suse 11.2 RC repository and
compiling for Suse also failed, but in the past I never had trouble to
build kernel-rt for Debian/ Ubuntu based 64 Studio. Maybe I should try
to build a kernel .31 for 64 Studio? Or is it just a module I need to
add? Or is my hardware missing something?
Going to use Google now.
Bye,
Ralf
James Warden wrote:
> I forgot to add that snd_hrtimer is used by jackd.
> If I turn jackd off, the snd_hrtimer module is not used:
>
> $ lsmod | grep timer
> snd_hrtimer 2148 0 ##
> J.
>
> --- On Sat, 11/7/09, James Warden wrote:
>
>
>> From: James Warden
>> Subject: Re: [LAD] timers
>> To: "Emanuel Rumpf" , "Ralf Mardorf"
>> Cc: linux-audio-dev@lists.linuxaudio.org
>> Date: Saturday, November 7, 2009, 7:34 AM
>> Hi guys,
>>
>> Here is what I have:
>>
>>
>> $ cat /proc/asound/timers
>> G0: system timer : 1000.000us (10000000 ticks)
>> G3: HR timer : 0.001us (1000000000 ticks)
>> Client sequencer queue 0 : running
>> P1-0-0: PCM playback 1-0-0 : SLAVE
>> P1-0-1: PCM capture 1-0-1 : SLAVE
>>
>> Ralf, you do not benefit from a high res timer. See how
>> much more precise the HR timer is from the output above.
>> Check which snd timer you have loaded:
>>
>> $ lsmod | grep timer
>>
>> snd_hrtimer
>> 2148 1
>> snd_timer
>> 17408 3 snd_hrtimer,snd_seq,snd_pcm
>>
>> Of course, your h/w should have a HR timer:
>>
>> $ ll /dev/hpet
>> crw-rw---- 1 root audio 10, 228 2009-11-05 12:59 /dev/hpet
>>
>> you can specify the clock source to jackd:
>>
>> $ jackd --help
>> ...
>> [ --clocksource OR -c [ c(ycle) | h(pet) | s(ystem) ]
>> ...
>>
>>
>>
>> J.
>>
>>
>> --- On Sat, 11/7/09, Ralf Mardorf
>> wrote:
>>
>>
>>> From: Ralf Mardorf
>>> Subject: Re: [LAD] timers
>>> To: "Emanuel Rumpf"
>>> Cc: linux-audio-dev@lists.linuxaudio.org
>>> Date: Saturday, November 7, 2009, 7:04 AM
>>> Emanuel Rumpf wrote:
>>>
>>>> Hi
>>>>
>>>> I'm confused about all the timers.
>>>>
>>>> There is:
>>>> - system timer
>>>> - hpet (high precision event timer)
>>>> - hr-timer (high resolution timer)
>>>> - rtc (real time clock)
>>>> - cyclic (what's that? a coded loop?)
>>>> - anything else ?
>>>>
>>>>
>>>> What is the relation of all these ?
>>>> Which hardware devices are actually used by those
>>>>
>> ?
>>
>>>> Which is the prefered timer for sequencing ?
>>>>
>> hr-timer
>>
>>> / rtc ?
>>>
>>>>
>>>>
>>> If hardware is fine with Linux real-time audio, if I
>>> understand
>>> correctly, the preferred timer for MIDI sequencers is
>>> (should be) system
>>> timer at ! 1000 Hz ! For my hardware, that has got
>>>
>> problems
>>
>>> with
>>> real-time audio, it's PCM playback and PCM capture.
>>>
>> Using
>>
>>> this timers
>>> MIDI jitter will decrease a little bit.
>>>
>>> This is the output I get for 64 Studio 3.0-beta3:
>>>
>>> spinymouse-sudo@64studio:~$ cat /proc/asound/timers
>>> G0: system timer : 1000.000us (10000000 ticks)
>>> P0-0-0: PCM playback 0-0-0 : SLAVE
>>> P0-0-1: PCM capture 0-0-1 : SLAVE
>>> Client sequencer queue 0 : stopped
>>> _______________________________________________
>>> Linux-audio-dev mailing list
>>> Linux-audio-dev@lists.linuxaudio.org
>>> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
>>>
>>>
>>
>> _______________________________________________
>> Linux-audio-dev mailing list
>> Linux-audio-dev@lists.linuxaudio.org
>> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
>>
>>
>
>
>
>
>
--
Secret of Tux: http://images.wallaceandgromit.com/user_uploads/forum_thumbnails/5/75/355.jpg
"Gromit bit me" says HMV dog: http://img.dailymail.co.uk/i/pix/2007/03_03/GomitHMVPA_468x319.jpg
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Oops, I forgot something too:
spinymouse-sudo@64studio:~$ ll /dev/hpet
bash: ll: command not found
spinymouse-sudo@64studio:~$ ls /dev | grep hpet
hpet
Ralf Mardorf wrote:
> Thank you Emanuel for this thread :)
> thank you James for the information :)
>
> hopefully this might narrow down my trouble with MIDI jitter for
> external equipment, OTOH I don't have any MIDI jitter for MIDI internal
> Linux. ALSA MIDI and JACK MIDI seems to be fine what ever timer I use,
> this means there is absolutely no jitter when using a Linux sequencer to
> control a Linux synth. Jitter only occurs when using my USB MIDInterface
> to control external MIDI equipment. Unfortunately I can't get my
> Envy24's MPU working.
>
> There seems to be no hrtimer available yet:
>
> $ lsmod | grep snd_hrtimer
> $ lsmod | grep timer
> snd_timer 22024 2 snd_pcm,snd_seq
> snd 63800 21
> snd_ice1712,snd_ak4xxx_adda,snd_cs8427,snd_ac97_codec,snd_i2c,snd_mpu401_uart,snd_usb_audio,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_hwdep,snd_seq_oss,snd_rawmidi,snd_seq,snd_timer,snd_seq_device
> $ uname -a
> Linux 64studio 2.6.29-1-multimedia-amd64 #1 SMP PREEMPT RT Thu Feb 26
> 16:18:05 UTC 2009 x86_64 GNU/Linux
>
> Before I start googleing. Is this a feature for 2.6.31 only? I'm still
> not able to boot the .31 kernel-rt from the Suse 11.2 RC repository and
> compiling for Suse also failed, but in the past I never had trouble to
> build kernel-rt for Debian/ Ubuntu based 64 Studio. Maybe I should try
> to build a kernel .31 for 64 Studio? Or is it just a module I need to
> add? Or is my hardware missing something?
>
> Going to use Google now.
>
> Bye,
> Ralf
>
> James Warden wrote:
>
>> I forgot to add that snd_hrtimer is used by jackd.
>> If I turn jackd off, the snd_hrtimer module is not used:
>>
>> $ lsmod | grep timer
>> snd_hrtimer 2148 0 ## snd_timer 17408 3 snd_hrtimer,snd_seq,snd_pcm
>>
>> J.
>>
>> --- On Sat, 11/7/09, James Warden wrote:
>>
>>
>>
>>> From: James Warden
>>> Subject: Re: [LAD] timers
>>> To: "Emanuel Rumpf" , "Ralf Mardorf"
>>> Cc: linux-audio-dev@lists.linuxaudio.org
>>> Date: Saturday, November 7, 2009, 7:34 AM
>>> Hi guys,
>>>
>>> Here is what I have:
>>>
>>>
>>> $ cat /proc/asound/timers
>>> G0: system timer : 1000.000us (10000000 ticks)
>>> G3: HR timer : 0.001us (1000000000 ticks)
>>> Client sequencer queue 0 : running
>>> P1-0-0: PCM playback 1-0-0 : SLAVE
>>> P1-0-1: PCM capture 1-0-1 : SLAVE
>>>
>>> Ralf, you do not benefit from a high res timer. See how
>>> much more precise the HR timer is from the output above.
>>> Check which snd timer you have loaded:
>>>
>>> $ lsmod | grep timer
>>>
>>> snd_hrtimer
>>> 2148 1
>>> snd_timer
>>> 17408 3 snd_hrtimer,snd_seq,snd_pcm
>>>
>>> Of course, your h/w should have a HR timer:
>>>
>>> $ ll /dev/hpet
>>> crw-rw---- 1 root audio 10, 228 2009-11-05 12:59 /dev/hpet
>>>
>>> you can specify the clock source to jackd:
>>>
>>> $ jackd --help
>>> ...
>>> [ --clocksource OR -c [ c(ycle) | h(pet) | s(ystem) ]
>>> ...
>>>
>>>
>>>
>>> J.
>>>
>>>
>>> --- On Sat, 11/7/09, Ralf Mardorf
>>> wrote:
>>>
>>>
>>>
>>>> From: Ralf Mardorf
>>>> Subject: Re: [LAD] timers
>>>> To: "Emanuel Rumpf"
>>>> Cc: linux-audio-dev@lists.linuxaudio.org
>>>> Date: Saturday, November 7, 2009, 7:04 AM
>>>> Emanuel Rumpf wrote:
>>>>
>>>>
>>>>> Hi
>>>>>
>>>>> I'm confused about all the timers.
>>>>>
>>>>> There is:
>>>>> - system timer
>>>>> - hpet (high precision event timer)
>>>>> - hr-timer (high resolution timer)
>>>>> - rtc (real time clock)
>>>>> - cyclic (what's that? a coded loop?)
>>>>> - anything else ?
>>>>>
>>>>>
>>>>> What is the relation of all these ?
>>>>> Which hardware devices are actually used by those
>>>>>
>>>>>
>>> ?
>>>
>>>
>>>>> Which is the prefered timer for sequencing ?
>>>>>
>>>>>
>>> hr-timer
>>>
>>>
>>>> / rtc ?
>>>>
>>>>
>>>>>
>>>>>
>>>>>
>>>> If hardware is fine with Linux real-time audio, if I
>>>> understand
>>>> correctly, the preferred timer for MIDI sequencers is
>>>> (should be) system
>>>> timer at ! 1000 Hz ! For my hardware, that has got
>>>>
>>>>
>>> problems
>>>
>>>
>>>> with
>>>> real-time audio, it's PCM playback and PCM capture.
>>>>
>>>>
>>> Using
>>>
>>>
>>>> this timers
>>>> MIDI jitter will decrease a little bit.
>>>>
>>>> This is the output I get for 64 Studio 3.0-beta3:
>>>>
>>>> spinymouse-sudo@64studio:~$ cat /proc/asound/timers
>>>> G0: system timer : 1000.000us (10000000 ticks)
>>>> P0-0-0: PCM playback 0-0-0 : SLAVE
>>>> P0-0-1: PCM capture 0-0-1 : SLAVE
>>>> Client sequencer queue 0 : stopped
>>>> _______________________________________________
>>>> Linux-audio-dev mailing list
>>>> Linux-audio-dev@lists.linuxaudio.org
>>>> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Linux-audio-dev mailing list
>>> Linux-audio-dev@lists.linuxaudio.org
>>> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
>>>
>>>
>>>
>>
>>
>>
>>
>
>
--
Secret of Tux: http://images.wallaceandgromit.com/user_uploads/forum_thumbnails/5/75/355.jpg
"Gromit bit me" says HMV dog: http://img.dailymail.co.uk/i/pix/2007/03_03/GomitHMVPA_468x319.jpg
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Ralf,
It depends how ALSA was compiled in the kernel. Here is my kernel config re=
lated to this matter:
CONFIG_SND=3Dm
CONFIG_SND_TIMER=3Dm
CONFIG_SND_PCM=3Dm
CONFIG_SND_HWDEP=3Dm
CONFIG_SND_RAWMIDI=3Dm
CONFIG_SND_SEQUENCER=3Dm
CONFIG_SND_SEQ_DUMMY=3Dm
# CONFIG_SND_MIXER_OSS is not set
# CONFIG_SND_PCM_OSS is not set
# CONFIG_SND_SEQUENCER_OSS is not set
CONFIG_SND_HRTIMER=3Dm
CONFIG_SND_SEQ_HRTIMER_DEFAULT=3Dy
J.
--- On Sat, 11/7/09, Ralf Mardorf wrote:
> From: Ralf Mardorf
> Subject: Re: [LAD] timers
> To: "James Warden"
> Cc: "Emanuel Rumpf" , linux-audio-dev@lists.linuxaudio.org
> Date: Saturday, November 7, 2009, 8:36 AM
> Thank you Emanuel for this thread :)
> thank you James for the information :)
> =
> hopefully this might narrow down my trouble with MIDI
> jitter for external equipment, OTOH I don't have any MIDI
> jitter for MIDI internal Linux. ALSA MIDI and JACK MIDI
> seems to be fine what ever timer I use, this means there is
> absolutely no jitter when using a Linux sequencer to control
> a Linux synth. Jitter only occurs when using my USB
> MIDInterface to control external MIDI equipment.
> Unfortunately I can't get my Envy24's MPU working.
> =
> There seems to be no hrtimer available yet:
> =
> $ lsmod | grep snd_hrtimer
> $ lsmod | grep timer
> snd_timer=A0 =A0 =A0 =A0 =A0 =A0 =A0
> 22024=A0 2 snd_pcm,snd_seq
> snd=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0
> =A0 =A0 63800=A0 21
> snd_ice1712,snd_ak4xxx_adda,snd_cs8427,snd_ac97_codec,snd_i2c,snd_mpu401_=
uart,snd_usb_audio,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_hwdep,snd_seq_oss,=
snd_rawmidi,snd_seq,snd_timer,snd_seq_device
> $ uname -a
> Linux 64studio 2.6.29-1-multimedia-amd64 #1 SMP PREEMPT RT
> Thu Feb 26 16:18:05 UTC 2009 x86_64 GNU/Linux
> =
> Before I start googleing. Is this a feature for 2.6.31
> only? I'm still not able to boot the .31 kernel-rt from the
> Suse 11.2 RC repository and compiling for Suse also failed,
> but in the past I never had trouble to build kernel-rt for
> Debian/ Ubuntu based 64 Studio. Maybe I should try to build
> a kernel .31 for 64 Studio? Or is it just a module I need to
> add? Or is my hardware missing something?
> =
> Going to use Google now.
> =
> Bye,
> Ralf
> =
> James Warden wrote:
> > I forgot to add that snd_hrtimer is used by jackd.
> > If I turn jackd off, the snd_hrtimer module is not
> used:
> > =
> > $ lsmod | grep timer
> > snd_hrtimer=A0 =A0 =A0 =A0 =A0
> =A0=A0=A02148=A0 0 ## snd_timer=A0 =A0 =A0 =A0 =A0 =A0
> =A0 17408=A0 3 snd_hrtimer,snd_seq,snd_pcm
> > =
> > J.
> > =
> > --- On Sat, 11/7/09, James Warden
> wrote:
> > =
> >=A0=A0=A0
> >> From: James Warden
> >> Subject: Re: [LAD] timers
> >> To: "Emanuel Rumpf" ,
> "Ralf Mardorf"
> >> Cc: linux-audio-dev@lists.linuxaudio.org
> >> Date: Saturday, November 7, 2009, 7:34 AM
> >> Hi guys,
> >> =
> >> Here is what I have:
> >> =
> >> =
> >> $ cat /proc/asound/timers
> >> G0: system timer : 1000.000us (10000000 ticks)
> >> G3: HR timer : 0.001us (1000000000 ticks)
> >>=A0=A0=A0Client sequencer queue 0 :
> running
> >> P1-0-0: PCM playback 1-0-0 : SLAVE
> >> P1-0-1: PCM capture 1-0-1 : SLAVE
> >> =
> >> Ralf, you do not benefit from a high res timer.
> See how
> >> much more precise the HR timer is from the output
> above.
> >> Check which snd timer you have loaded:
> >> =
> >> $ lsmod | grep timer
> >> =
> >> snd_hrtimer=A0 =A0 =A0 =A0 =A0
> =A0 2148=A0 1
> >> snd_timer=A0 =A0 =A0 =A0 =A0
> =A0=A0=A017408=A0 3 snd_hrtimer,snd_seq,snd_pcm
> >> =
> >> Of course, your h/w should have a HR timer:
> >> =
> >> $ ll /dev/hpet
> >> crw-rw---- 1 root audio 10, 228 2009-11-05 12:59
> /dev/hpet
> >> =
> >> you can specify the clock source to jackd:
> >> =
> >> $ jackd --help
> >> ...
> >> [ --clocksource OR -c [ c(ycle) | h(pet) |
> s(ystem) ]
> >> ...
> >> =
> >> =
> >> =
> >> J.
> >> =
> >> =
> >> --- On Sat, 11/7/09, Ralf Mardorf
> >> wrote:
> >> =
> >>=A0 =A0=A0=A0
> >>> From: Ralf Mardorf
> >>> Subject: Re: [LAD] timers
> >>> To: "Emanuel Rumpf"
> >>> Cc: linux-audio-dev@lists.linuxaudio.org
> >>> Date: Saturday, November 7, 2009, 7:04 AM
> >>> Emanuel Rumpf wrote:
> >>>=A0 =A0 =A0=A0=A0
> >>>> Hi
> >>>> =
> >>>> I'm confused about all the timers.
> >>>> =
> >>>> There is:
> >>>> - system timer
> >>>> - hpet (high precision event timer)
> >>>> - hr-timer (high resolution timer)
> >>>> - rtc (real time clock)
> >>>> - cyclic (what's that? a coded loop?)
> >>>> - anything else ?
> >>>> =
> >>>> =
> >>>> What is the relation of all these ?
> >>>> Which hardware devices are actually used
> by those
> >>>>=A0 =A0 =A0 =A0=A0=A0
> >> ?
> >>=A0 =A0=A0=A0
> >>>> Which is the prefered timer for sequencing
> ?
> >>>>=A0 =A0 =A0 =A0=A0=A0
> >> hr-timer
> >>=A0 =A0=A0=A0
> >>> / rtc ?
> >>>=A0 =A0 =A0=A0=A0
> >>>>=A0 =A0 =A0 =A0 =A0 =A0 =
> >>> If hardware is fine with Linux real-time
> audio, if I
> >>> understand correctly, the preferred timer for
> MIDI sequencers is
> >>> (should be) system timer at ! 1000 Hz ! For my
> hardware, that has got
> >>>=A0 =A0 =A0=A0=A0
> >> problems
> >>=A0 =A0=A0=A0
> >>> with real-time audio, it's PCM playback and
> PCM capture.
> >>>=A0 =A0 =A0=A0=A0
> >> Using
> >>=A0 =A0=A0=A0
> >>> this timers MIDI jitter will decrease a little
> bit.
> >>> =
> >>> This is the output I get for 64 Studio
> 3.0-beta3:
> >>> =
> >>> spinymouse-sudo@64studio:~$ cat
> /proc/asound/timers
> >>> G0: system timer : 1000.000us (10000000
> ticks)
> >>> P0-0-0: PCM playback 0-0-0 : SLAVE
> >>> P0-0-1: PCM capture 0-0-1 : SLAVE
> >>>=A0=A0=A0Client sequencer queue 0 :
> stopped
> >>>
> _______________________________________________
> >>> Linux-audio-dev mailing list
> >>> Linux-audio-dev@lists.linuxaudio.org
> >>> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
> >>> =
> >>>=A0 =A0 =A0=A0=A0
> >>=A0 =A0
> =A0=A0=A0_______________________________________________
> >> Linux-audio-dev mailing list
> >> Linux-audio-dev@lists.linuxaudio.org
> >> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
> >> =
> >>=A0 =A0=A0=A0
> > =
> > =
> >=A0 =A0 =A0=A0=A0
> >=A0=A0=A0
> =
> -- Secret of Tux: http://images.wallaceandgromit.com/user_uploads/forum_t=
humbnails/5/75/355.jpg
> "Gromit bit me" says HMV dog: http://img.dailymail.co.uk/i/pix/2007/03_03=
/GomitHMVPA_468x319.jpg
> =
> =
=
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

James Warden wrote:
> Ralf,
>
> It depends how ALSA was compiled in the kernel. Here is my kernel config related to this matter:
>
>
> CONFIG_SND=m
> CONFIG_SND_TIMER=m
> CONFIG_SND_PCM=m
> CONFIG_SND_HWDEP=m
> CONFIG_SND_RAWMIDI=m
> CONFIG_SND_SEQUENCER=m
> CONFIG_SND_SEQ_DUMMY=m
> # CONFIG_SND_MIXER_OSS is not set
> # CONFIG_SND_PCM_OSS is not set
> # CONFIG_SND_SEQUENCER_OSS is not set
> CONFIG_SND_HRTIMER=m
> CONFIG_SND_SEQ_HRTIMER_DEFAULT=y
>
> J.
There is another question I've got :S.
spinymouse-sudo@64studio:~$ ls -l /dev | grep hpet
crw-rw---- 1 root root 10, 228 2009-11-07 13:38 hpet
The group for hpet isn't audio, thus I guess a user won't be able to use
it?!
Oops, "# CONFIG_SND_HRTIMER is not set", has this now become something I
should post to the 64 Studio list? It's the default for the 64 Studio
kernel. It's not a self build kernel.
spinymouse-sudo@64studio:~$ cat /boot/config-2.6.29-1-multimedia-amd64 |
grep CONFIG_SND
CONFIG_SND=m
CONFIG_SND_TIMER=m
CONFIG_SND_PCM=m
CONFIG_SND_HWDEP=m
CONFIG_SND_RAWMIDI=m
CONFIG_SND_JACK=y
CONFIG_SND_SEQUENCER=m
CONFIG_SND_SEQ_DUMMY=m
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=m
CONFIG_SND_PCM_OSS=m
CONFIG_SND_PCM_OSS_PLUGINS=y
CONFIG_SND_SEQUENCER_OSS=y
# CONFIG_SND_HRTIMER is not set
# CONFIG_SND_DYNAMIC_MINORS is not set
CONFIG_SND_SUPPORT_OLD_API=y
CONFIG_SND_VERBOSE_PROCFS=y
# CONFIG_SND_VERBOSE_PRINTK is not set
# CONFIG_SND_DEBUG is not set
CONFIG_SND_VMASTER=y
CONFIG_SND_MPU401_UART=m
CONFIG_SND_OPL3_LIB=m
CONFIG_SND_VX_LIB=m
CONFIG_SND_AC97_CODEC=m
CONFIG_SND_DRIVERS=y
CONFIG_SND_PCSP=m
CONFIG_SND_DUMMY=m
CONFIG_SND_VIRMIDI=m
CONFIG_SND_MTS64=m
CONFIG_SND_SERIAL_U16550=m
CONFIG_SND_MPU401=m
CONFIG_SND_PORTMAN2X4=m
CONFIG_SND_AC97_POWER_SAVE=y
CONFIG_SND_AC97_POWER_SAVE_DEFAULT=0
CONFIG_SND_SB_COMMON=m
CONFIG_SND_SB16_DSP=m
CONFIG_SND_PCI=y
CONFIG_SND_AD1889=m
CONFIG_SND_ALS300=m
CONFIG_SND_ALS4000=m
CONFIG_SND_ALI5451=m
CONFIG_SND_ATIIXP=m
CONFIG_SND_ATIIXP_MODEM=m
CONFIG_SND_AU8810=m
CONFIG_SND_AU8820=m
CONFIG_SND_AU8830=m
# CONFIG_SND_AW2 is not set
CONFIG_SND_AZT3328=m
CONFIG_SND_BT87X=m
# CONFIG_SND_BT87X_OVERCLOCK is not set
CONFIG_SND_CA0106=m
CONFIG_SND_CMIPCI=m
CONFIG_SND_OXYGEN_LIB=m
CONFIG_SND_OXYGEN=m
CONFIG_SND_CS4281=m
CONFIG_SND_CS46XX=m
CONFIG_SND_CS46XX_NEW_DSP=y
CONFIG_SND_CS5530=m
CONFIG_SND_DARLA20=m
CONFIG_SND_GINA20=m
CONFIG_SND_LAYLA20=m
CONFIG_SND_DARLA24=m
CONFIG_SND_GINA24=m
CONFIG_SND_LAYLA24=m
CONFIG_SND_MONA=m
CONFIG_SND_MIA=m
CONFIG_SND_ECHO3G=m
CONFIG_SND_INDIGO=m
CONFIG_SND_INDIGOIO=m
CONFIG_SND_INDIGODJ=m
CONFIG_SND_EMU10K1=m
CONFIG_SND_EMU10K1X=m
CONFIG_SND_ENS1370=m
CONFIG_SND_ENS1371=m
CONFIG_SND_ES1938=m
CONFIG_SND_ES1968=m
CONFIG_SND_FM801=m
CONFIG_SND_FM801_TEA575X_BOOL=y
CONFIG_SND_FM801_TEA575X=m
CONFIG_SND_HDA_INTEL=m
# CONFIG_SND_HDA_HWDEP is not set
CONFIG_SND_HDA_INPUT_BEEP=y
CONFIG_SND_HDA_CODEC_REALTEK=y
CONFIG_SND_HDA_CODEC_ANALOG=y
CONFIG_SND_HDA_CODEC_SIGMATEL=y
CONFIG_SND_HDA_CODEC_VIA=y
CONFIG_SND_HDA_CODEC_ATIHDMI=y
CONFIG_SND_HDA_CODEC_NVHDMI=y
CONFIG_SND_HDA_CODEC_INTELHDMI=y
CONFIG_SND_HDA_ELD=y
CONFIG_SND_HDA_CODEC_CONEXANT=y
CONFIG_SND_HDA_CODEC_CMEDIA=y
CONFIG_SND_HDA_CODEC_SI3054=y
CONFIG_SND_HDA_GENERIC=y
CONFIG_SND_HDA_POWER_SAVE=y
CONFIG_SND_HDA_POWER_SAVE_DEFAULT=0
CONFIG_SND_HDSP=m
CONFIG_SND_HDSPM=m
CONFIG_SND_HIFIER=m
CONFIG_SND_ICE1712=m
CONFIG_SND_ICE1724=m
CONFIG_SND_INTEL8X0=m
CONFIG_SND_INTEL8X0M=m
CONFIG_SND_KORG1212=m
CONFIG_SND_MAESTRO3=m
CONFIG_SND_MIXART=m
CONFIG_SND_NM256=m
CONFIG_SND_PCXHR=m
CONFIG_SND_RIPTIDE=m
CONFIG_SND_RME32=m
CONFIG_SND_RME96=m
CONFIG_SND_RME9652=m
CONFIG_SND_SONICVIBES=m
CONFIG_SND_TRIDENT=m
CONFIG_SND_VIA82XX=m
CONFIG_SND_VIA82XX_MODEM=m
CONFIG_SND_VIRTUOSO=m
CONFIG_SND_VX222=m
CONFIG_SND_YMFPCI=m
CONFIG_SND_SPI=y
CONFIG_SND_USB=y
CONFIG_SND_USB_AUDIO=m
CONFIG_SND_USB_USX2Y=m
CONFIG_SND_USB_CAIAQ=m
CONFIG_SND_USB_CAIAQ_INPUT=y
CONFIG_SND_USB_US122L=m
CONFIG_SND_PCMCIA=y
CONFIG_SND_VXPOCKET=m
CONFIG_SND_PDAUDIOCF=m
# CONFIG_SND_SOC is not set
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

--0016369207099ade950477c84a56
Content-Type: text/plain; charset=ISO-8859-1
> CONFIG_SND=m
> CONFIG_SND_TIMER=m
> CONFIG_SND_PCM=m
> CONFIG_SND_HWDEP=m
> CONFIG_SND_RAWMIDI=m
> CONFIG_SND_SEQUENCER=m
> CONFIG_SND_SEQ_DUMMY=m
> # CONFIG_SND_MIXER_OSS is not set
> # CONFIG_SND_PCM_OSS is not set
> # CONFIG_SND_SEQUENCER_OSS is not set
> CONFIG_SND_HRTIMER=m
> CONFIG_SND_SEQ_HRTIMER_DEFAULT=y
Are defaults. You need:
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
CONFIG_HPET=y
CONFIG_HPET_MMAP=y
It's inside one of the first few menus.
--0016369207099ade950477c84a56
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
> CONFIG_SND=3Dm&g=
t; CONFIG_SND_TIMER=3Dm> CONFIG_SND_PCM=3Dm> CONFIG_SND_HWDEP=
=3Dm> CONFIG_SND_RAWMIDI=3Dm
> CONFIG_SND_SEQUENCER=3Dm> CONFIG_SND_SEQ_DUMMY=3Dm> # CO=
NFIG_SND_MIXER_OSS is not set> # CONFIG_SND_PCM_OSS is not set&g=
t; # CONFIG_SND_SEQUENCER_OSS is not set> CONFIG_SND_HRTIMER=3Dm=
> CONFIG_SND_SEQ_HRTIMER_DEFAULT=3Dy
Are defaults. You need:CONFIG=
_HPET_TIMER=3DyCONFIG_HPET_EMULATE_RTC=3DyCONFIG_HPET=
=3DyCONFIG_HPET_MMAP=3DyIt's insid=
e one of the first few menus.
--0016369207099ade950477c84a56--

yeah, I have added a few things in a startup script. Among other things, I =
have:
chgrp audio /dev/hpet
echo 1024 > /proc/sys/dev/hpet/max-user-freq
modprobe snd-hrtimer
The modprobe may not be needed anymore as my kernel is using hr-timer by de=
fault. I wrote this script quite some time ago and forgot about it :)
J.
--- On Sat, 11/7/09, Ralf Mardorf wrote:
> From: Ralf Mardorf
> Subject: Re: [LAD] timers
> To: =
> Cc: linux-audio-dev@lists.linuxaudio.org
> Date: Saturday, November 7, 2009, 8:52 AM
> James Warden wrote:
> > Ralf,
> >
> > It depends how ALSA was compiled in the kernel. Here
> is my kernel config related to this matter:
> >
> >
> > CONFIG_SND=3Dm
> > CONFIG_SND_TIMER=3Dm
> > CONFIG_SND_PCM=3Dm
> > CONFIG_SND_HWDEP=3Dm
> > CONFIG_SND_RAWMIDI=3Dm
> > CONFIG_SND_SEQUENCER=3Dm
> > CONFIG_SND_SEQ_DUMMY=3Dm
> > # CONFIG_SND_MIXER_OSS is not set
> > # CONFIG_SND_PCM_OSS is not set
> > # CONFIG_SND_SEQUENCER_OSS is not set
> > CONFIG_SND_HRTIMER=3Dm
> > CONFIG_SND_SEQ_HRTIMER_DEFAULT=3Dy
> >
> > J.
> =
> There is another question I've got :S.
> =
> spinymouse-sudo@64studio:~$ ls -l /dev | grep hpet
> crw-rw----=A0 1 root=A0=A0=A0root=A0
> =A0=A0=A010, 228 2009-11-07 13:38 hpet
> =
> The group for hpet isn't audio, thus I guess a user won't
> be able to use =
> it?!
> =
> Oops, "# CONFIG_SND_HRTIMER is not set", has this now
> become something I =
> should post to the 64 Studio list? It's the default for the
> 64 Studio =
> kernel. It's not a self build kernel.
> =
> spinymouse-sudo@64studio:~$ cat
> /boot/config-2.6.29-1-multimedia-amd64 | =
> grep CONFIG_SND
> CONFIG_SND=3Dm
> CONFIG_SND_TIMER=3Dm
> CONFIG_SND_PCM=3Dm
> CONFIG_SND_HWDEP=3Dm
> CONFIG_SND_RAWMIDI=3Dm
> CONFIG_SND_JACK=3Dy
> CONFIG_SND_SEQUENCER=3Dm
> CONFIG_SND_SEQ_DUMMY=3Dm
> CONFIG_SND_OSSEMUL=3Dy
> CONFIG_SND_MIXER_OSS=3Dm
> CONFIG_SND_PCM_OSS=3Dm
> CONFIG_SND_PCM_OSS_PLUGINS=3Dy
> CONFIG_SND_SEQUENCER_OSS=3Dy
> # CONFIG_SND_HRTIMER is not set
> # CONFIG_SND_DYNAMIC_MINORS is not set
> CONFIG_SND_SUPPORT_OLD_API=3Dy
> CONFIG_SND_VERBOSE_PROCFS=3Dy
> # CONFIG_SND_VERBOSE_PRINTK is not set
> # CONFIG_SND_DEBUG is not set
> CONFIG_SND_VMASTER=3Dy
> CONFIG_SND_MPU401_UART=3Dm
> CONFIG_SND_OPL3_LIB=3Dm
> CONFIG_SND_VX_LIB=3Dm
> CONFIG_SND_AC97_CODEC=3Dm
> CONFIG_SND_DRIVERS=3Dy
> CONFIG_SND_PCSP=3Dm
> CONFIG_SND_DUMMY=3Dm
> CONFIG_SND_VIRMIDI=3Dm
> CONFIG_SND_MTS64=3Dm
> CONFIG_SND_SERIAL_U16550=3Dm
> CONFIG_SND_MPU401=3Dm
> CONFIG_SND_PORTMAN2X4=3Dm
> CONFIG_SND_AC97_POWER_SAVE=3Dy
> CONFIG_SND_AC97_POWER_SAVE_DEFAULT=3D0
> CONFIG_SND_SB_COMMON=3Dm
> CONFIG_SND_SB16_DSP=3Dm
> CONFIG_SND_PCI=3Dy
> CONFIG_SND_AD1889=3Dm
> CONFIG_SND_ALS300=3Dm
> CONFIG_SND_ALS4000=3Dm
> CONFIG_SND_ALI5451=3Dm
> CONFIG_SND_ATIIXP=3Dm
> CONFIG_SND_ATIIXP_MODEM=3Dm
> CONFIG_SND_AU8810=3Dm
> CONFIG_SND_AU8820=3Dm
> CONFIG_SND_AU8830=3Dm
> # CONFIG_SND_AW2 is not set
> CONFIG_SND_AZT3328=3Dm
> CONFIG_SND_BT87X=3Dm
> # CONFIG_SND_BT87X_OVERCLOCK is not set
> CONFIG_SND_CA0106=3Dm
> CONFIG_SND_CMIPCI=3Dm
> CONFIG_SND_OXYGEN_LIB=3Dm
> CONFIG_SND_OXYGEN=3Dm
> CONFIG_SND_CS4281=3Dm
> CONFIG_SND_CS46XX=3Dm
> CONFIG_SND_CS46XX_NEW_DSP=3Dy
> CONFIG_SND_CS5530=3Dm
> CONFIG_SND_DARLA20=3Dm
> CONFIG_SND_GINA20=3Dm
> CONFIG_SND_LAYLA20=3Dm
> CONFIG_SND_DARLA24=3Dm
> CONFIG_SND_GINA24=3Dm
> CONFIG_SND_LAYLA24=3Dm
> CONFIG_SND_MONA=3Dm
> CONFIG_SND_MIA=3Dm
> CONFIG_SND_ECHO3G=3Dm
> CONFIG_SND_INDIGO=3Dm
> CONFIG_SND_INDIGOIO=3Dm
> CONFIG_SND_INDIGODJ=3Dm
> CONFIG_SND_EMU10K1=3Dm
> CONFIG_SND_EMU10K1X=3Dm
> CONFIG_SND_ENS1370=3Dm
> CONFIG_SND_ENS1371=3Dm
> CONFIG_SND_ES1938=3Dm
> CONFIG_SND_ES1968=3Dm
> CONFIG_SND_FM801=3Dm
> CONFIG_SND_FM801_TEA575X_BOOL=3Dy
> CONFIG_SND_FM801_TEA575X=3Dm
> CONFIG_SND_HDA_INTEL=3Dm
> # CONFIG_SND_HDA_HWDEP is not set
> CONFIG_SND_HDA_INPUT_BEEP=3Dy
> CONFIG_SND_HDA_CODEC_REALTEK=3Dy
> CONFIG_SND_HDA_CODEC_ANALOG=3Dy
> CONFIG_SND_HDA_CODEC_SIGMATEL=3Dy
> CONFIG_SND_HDA_CODEC_VIA=3Dy
> CONFIG_SND_HDA_CODEC_ATIHDMI=3Dy
> CONFIG_SND_HDA_CODEC_NVHDMI=3Dy
> CONFIG_SND_HDA_CODEC_INTELHDMI=3Dy
> CONFIG_SND_HDA_ELD=3Dy
> CONFIG_SND_HDA_CODEC_CONEXANT=3Dy
> CONFIG_SND_HDA_CODEC_CMEDIA=3Dy
> CONFIG_SND_HDA_CODEC_SI3054=3Dy
> CONFIG_SND_HDA_GENERIC=3Dy
> CONFIG_SND_HDA_POWER_SAVE=3Dy
> CONFIG_SND_HDA_POWER_SAVE_DEFAULT=3D0
> CONFIG_SND_HDSP=3Dm
> CONFIG_SND_HDSPM=3Dm
> CONFIG_SND_HIFIER=3Dm
> CONFIG_SND_ICE1712=3Dm
> CONFIG_SND_ICE1724=3Dm
> CONFIG_SND_INTEL8X0=3Dm
> CONFIG_SND_INTEL8X0M=3Dm
> CONFIG_SND_KORG1212=3Dm
> CONFIG_SND_MAESTRO3=3Dm
> CONFIG_SND_MIXART=3Dm
> CONFIG_SND_NM256=3Dm
> CONFIG_SND_PCXHR=3Dm
> CONFIG_SND_RIPTIDE=3Dm
> CONFIG_SND_RME32=3Dm
> CONFIG_SND_RME96=3Dm
> CONFIG_SND_RME9652=3Dm
> CONFIG_SND_SONICVIBES=3Dm
> CONFIG_SND_TRIDENT=3Dm
> CONFIG_SND_VIA82XX=3Dm
> CONFIG_SND_VIA82XX_MODEM=3Dm
> CONFIG_SND_VIRTUOSO=3Dm
> CONFIG_SND_VX222=3Dm
> CONFIG_SND_YMFPCI=3Dm
> CONFIG_SND_SPI=3Dy
> CONFIG_SND_USB=3Dy
> CONFIG_SND_USB_AUDIO=3Dm
> CONFIG_SND_USB_USX2Y=3Dm
> CONFIG_SND_USB_CAIAQ=3Dm
> CONFIG_SND_USB_CAIAQ_INPUT=3Dy
> CONFIG_SND_USB_US122L=3Dm
> CONFIG_SND_PCMCIA=3Dy
> CONFIG_SND_VXPOCKET=3Dm
> CONFIG_SND_PDAUDIOCF=3Dm
> # CONFIG_SND_SOC is not set
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
> =
=
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

yeps, forgot to copy this part of the config here, thanks :)
J.
--- On Sat, 11/7/09, Ray Rashif wrote:
> From: Ray Rashif
> Subject: Re: [LAD] timers
> To: "Linux Audio Developers"
> Date: Saturday, November 7, 2009, 8:53 AM
> >
> CONFIG_SND=m
> > CONFIG_SND_TIMER=m
> > CONFIG_SND_PCM=m
> > CONFIG_SND_HWDEP=m
> > CONFIG_SND_RAWMIDI=m
>
>
> > CONFIG_SND_SEQUENCER=m
> > CONFIG_SND_SEQ_DUMMY=m
> > # CONFIG_SND_MIXER_OSS is not set
> > # CONFIG_SND_PCM_OSS is not set
> > # CONFIG_SND_SEQUENCER_OSS is not set
> > CONFIG_SND_HRTIMER=m
> > CONFIG_SND_SEQ_HRTIMER_DEFAULT=y
>
>
> Are defaults. You need:
> CONFIG_HPET_TIMER=yCONFIG_HPET_EMULATE_RTC=yCONFIG_HPET=yCONFIG_HPET_MMAP=y
> It's inside one of the first few
> menus.
>
>
>
> -----Inline Attachment Follows-----
>
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
>

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Thank you very much James and Ray :).
Ralf
James Warden wrote:
> yeah, I have added a few things in a startup script. Among other things, I have:
>
> chgrp audio /dev/hpet
> echo 1024 > /proc/sys/dev/hpet/max-user-freq
> modprobe snd-hrtimer
>
> The modprobe may not be needed anymore as my kernel is using hr-timer by default. I wrote this script quite some time ago and forgot about it :)
>
> J.
>
> --- On Sat, 11/7/09, Ralf Mardorf wrote:
>
>
>> From: Ralf Mardorf
>> Subject: Re: [LAD] timers
>> To:
>> Cc: linux-audio-dev@lists.linuxaudio.org
>> Date: Saturday, November 7, 2009, 8:52 AM
>> James Warden wrote:
>>
>>> Ralf,
>>>
>>> It depends how ALSA was compiled in the kernel. Here
>>>
>> is my kernel config related to this matter:
>>
>>> CONFIG_SND=m
>>> CONFIG_SND_TIMER=m
>>> CONFIG_SND_PCM=m
>>> CONFIG_SND_HWDEP=m
>>> CONFIG_SND_RAWMIDI=m
>>> CONFIG_SND_SEQUENCER=m
>>> CONFIG_SND_SEQ_DUMMY=m
>>> # CONFIG_SND_MIXER_OSS is not set
>>> # CONFIG_SND_PCM_OSS is not set
>>> # CONFIG_SND_SEQUENCER_OSS is not set
>>> CONFIG_SND_HRTIMER=m
>>> CONFIG_SND_SEQ_HRTIMER_DEFAULT=y
>>>
>>> J.
>>>
>> There is another question I've got :S.
>>
>> spinymouse-sudo@64studio:~$ ls -l /dev | grep hpet
>> crw-rw---- 1 root root
>> 10, 228 2009-11-07 13:38 hpet
>>
>> The group for hpet isn't audio, thus I guess a user won't
>> be able to use
>> it?!
>>
>> Oops, "# CONFIG_SND_HRTIMER is not set", has this now
>> become something I
>> should post to the 64 Studio list? It's the default for the
>> 64 Studio
>> kernel. It's not a self build kernel.
>>
>> spinymouse-sudo@64studio:~$ cat
>> /boot/config-2.6.29-1-multimedia-amd64 |
>> grep CONFIG_SND
>> CONFIG_SND=m
>> CONFIG_SND_TIMER=m
>> CONFIG_SND_PCM=m
>> CONFIG_SND_HWDEP=m
>> CONFIG_SND_RAWMIDI=m
>> CONFIG_SND_JACK=y
>> CONFIG_SND_SEQUENCER=m
>> CONFIG_SND_SEQ_DUMMY=m
>> CONFIG_SND_OSSEMUL=y
>> CONFIG_SND_MIXER_OSS=m
>> CONFIG_SND_PCM_OSS=m
>> CONFIG_SND_PCM_OSS_PLUGINS=y
>> CONFIG_SND_SEQUENCER_OSS=y
>> # CONFIG_SND_HRTIMER is not set
>> # CONFIG_SND_DYNAMIC_MINORS is not set
>> CONFIG_SND_SUPPORT_OLD_API=y
>> CONFIG_SND_VERBOSE_PROCFS=y
>> # CONFIG_SND_VERBOSE_PRINTK is not set
>> # CONFIG_SND_DEBUG is not set
>> CONFIG_SND_VMASTER=y
>> CONFIG_SND_MPU401_UART=m
>> CONFIG_SND_OPL3_LIB=m
>> CONFIG_SND_VX_LIB=m
>> CONFIG_SND_AC97_CODEC=m
>> CONFIG_SND_DRIVERS=y
>> CONFIG_SND_PCSP=m
>> CONFIG_SND_DUMMY=m
>> CONFIG_SND_VIRMIDI=m
>> CONFIG_SND_MTS64=m
>> CONFIG_SND_SERIAL_U16550=m
>> CONFIG_SND_MPU401=m
>> CONFIG_SND_PORTMAN2X4=m
>> CONFIG_SND_AC97_POWER_SAVE=y
>> CONFIG_SND_AC97_POWER_SAVE_DEFAULT=0
>> CONFIG_SND_SB_COMMON=m
>> CONFIG_SND_SB16_DSP=m
>> CONFIG_SND_PCI=y
>> CONFIG_SND_AD1889=m
>> CONFIG_SND_ALS300=m
>> CONFIG_SND_ALS4000=m
>> CONFIG_SND_ALI5451=m
>> CONFIG_SND_ATIIXP=m
>> CONFIG_SND_ATIIXP_MODEM=m
>> CONFIG_SND_AU8810=m
>> CONFIG_SND_AU8820=m
>> CONFIG_SND_AU8830=m
>> # CONFIG_SND_AW2 is not set
>> CONFIG_SND_AZT3328=m
>> CONFIG_SND_BT87X=m
>> # CONFIG_SND_BT87X_OVERCLOCK is not set
>> CONFIG_SND_CA0106=m
>> CONFIG_SND_CMIPCI=m
>> CONFIG_SND_OXYGEN_LIB=m
>> CONFIG_SND_OXYGEN=m
>> CONFIG_SND_CS4281=m
>> CONFIG_SND_CS46XX=m
>> CONFIG_SND_CS46XX_NEW_DSP=y
>> CONFIG_SND_CS5530=m
>> CONFIG_SND_DARLA20=m
>> CONFIG_SND_GINA20=m
>> CONFIG_SND_LAYLA20=m
>> CONFIG_SND_DARLA24=m
>> CONFIG_SND_GINA24=m
>> CONFIG_SND_LAYLA24=m
>> CONFIG_SND_MONA=m
>> CONFIG_SND_MIA=m
>> CONFIG_SND_ECHO3G=m
>> CONFIG_SND_INDIGO=m
>> CONFIG_SND_INDIGOIO=m
>> CONFIG_SND_INDIGODJ=m
>> CONFIG_SND_EMU10K1=m
>> CONFIG_SND_EMU10K1X=m
>> CONFIG_SND_ENS1370=m
>> CONFIG_SND_ENS1371=m
>> CONFIG_SND_ES1938=m
>> CONFIG_SND_ES1968=m
>> CONFIG_SND_FM801=m
>> CONFIG_SND_FM801_TEA575X_BOOL=y
>> CONFIG_SND_FM801_TEA575X=m
>> CONFIG_SND_HDA_INTEL=m
>> # CONFIG_SND_HDA_HWDEP is not set
>> CONFIG_SND_HDA_INPUT_BEEP=y
>> CONFIG_SND_HDA_CODEC_REALTEK=y
>> CONFIG_SND_HDA_CODEC_ANALOG=y
>> CONFIG_SND_HDA_CODEC_SIGMATEL=y
>> CONFIG_SND_HDA_CODEC_VIA=y
>> CONFIG_SND_HDA_CODEC_ATIHDMI=y
>> CONFIG_SND_HDA_CODEC_NVHDMI=y
>> CONFIG_SND_HDA_CODEC_INTELHDMI=y
>> CONFIG_SND_HDA_ELD=y
>> CONFIG_SND_HDA_CODEC_CONEXANT=y
>> CONFIG_SND_HDA_CODEC_CMEDIA=y
>> CONFIG_SND_HDA_CODEC_SI3054=y
>> CONFIG_SND_HDA_GENERIC=y
>> CONFIG_SND_HDA_POWER_SAVE=y
>> CONFIG_SND_HDA_POWER_SAVE_DEFAULT=0
>> CONFIG_SND_HDSP=m
>> CONFIG_SND_HDSPM=m
>> CONFIG_SND_HIFIER=m
>> CONFIG_SND_ICE1712=m
>> CONFIG_SND_ICE1724=m
>> CONFIG_SND_INTEL8X0=m
>> CONFIG_SND_INTEL8X0M=m
>> CONFIG_SND_KORG1212=m
>> CONFIG_SND_MAESTRO3=m
>> CONFIG_SND_MIXART=m
>> CONFIG_SND_NM256=m
>> CONFIG_SND_PCXHR=m
>> CONFIG_SND_RIPTIDE=m
>> CONFIG_SND_RME32=m
>> CONFIG_SND_RME96=m
>> CONFIG_SND_RME9652=m
>> CONFIG_SND_SONICVIBES=m
>> CONFIG_SND_TRIDENT=m
>> CONFIG_SND_VIA82XX=m
>> CONFIG_SND_VIA82XX_MODEM=m
>> CONFIG_SND_VIRTUOSO=m
>> CONFIG_SND_VX222=m
>> CONFIG_SND_YMFPCI=m
>> CONFIG_SND_SPI=y
>> CONFIG_SND_USB=y
>> CONFIG_SND_USB_AUDIO=m
>> CONFIG_SND_USB_USX2Y=m
>> CONFIG_SND_USB_CAIAQ=m
>> CONFIG_SND_USB_CAIAQ_INPUT=y
>> CONFIG_SND_USB_US122L=m
>> CONFIG_SND_PCMCIA=y
>> CONFIG_SND_VXPOCKET=m
>> CONFIG_SND_PDAUDIOCF=m
>> # CONFIG_SND_SOC is not set
>> _______________________________________________
>> Linux-audio-dev mailing list
>> Linux-audio-dev@lists.linuxaudio.org
>> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
>>
>>
>
>
>
>
>
--
Secret of Tux: http://images.wallaceandgromit.com/user_uploads/forum_thumbnails/5/75/355.jpg
"Gromit bit me" says HMV dog: http://img.dailymail.co.uk/i/pix/2007/03_03/GomitHMVPA_468x319.jpg
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Another thing you can check:
dmesg | grep -i hpet
You'll see if your h/w supports it.
You can read more at
http://en.wikipedia.org/wiki/High_Precision_Event_Timer
J. =
--- On Sat, 11/7/09, Ralf Mardorf wrote:
> From: Ralf Mardorf
> Subject: Re: [LAD] timers
> To: "James Warden"
> Cc: linux-audio-dev@lists.linuxaudio.org
> Date: Saturday, November 7, 2009, 8:57 AM
> Thank you very much James and Ray
> :).
> =
> Ralf
> =
> James Warden wrote:
> > yeah, I have added a few things in a startup script.
> Among other things, I have:
> > =
> > chgrp audio /dev/hpet
> > echo 1024 > /proc/sys/dev/hpet/max-user-freq
> > modprobe snd-hrtimer
> > =
> > The modprobe may not be needed anymore as my kernel is
> using hr-timer by default. I wrote this script quite some
> time ago and forgot about it :)
> > =
> > J.
> > =
> > --- On Sat, 11/7/09, Ralf Mardorf
> wrote:
> > =
> >=A0=A0=A0
> >> From: Ralf Mardorf
> >> Subject: Re: [LAD] timers
> >> To: Cc: linux-audio-dev@lists.linuxaudio.org
> >> Date: Saturday, November 7, 2009, 8:52 AM
> >> James Warden wrote:
> >>=A0 =A0=A0=A0
> >>> Ralf,
> >>> =
> >>> It depends how ALSA was compiled in the
> kernel. Here
> >>>=A0 =A0 =A0=A0=A0
> >> is my kernel config related to this matter:
> >>=A0 =A0=A0=A0
> >>> CONFIG_SND=3Dm
> >>> CONFIG_SND_TIMER=3Dm
> >>> CONFIG_SND_PCM=3Dm
> >>> CONFIG_SND_HWDEP=3Dm
> >>> CONFIG_SND_RAWMIDI=3Dm
> >>> CONFIG_SND_SEQUENCER=3Dm
> >>> CONFIG_SND_SEQ_DUMMY=3Dm
> >>> # CONFIG_SND_MIXER_OSS is not set
> >>> # CONFIG_SND_PCM_OSS is not set
> >>> # CONFIG_SND_SEQUENCER_OSS is not set
> >>> CONFIG_SND_HRTIMER=3Dm
> >>> CONFIG_SND_SEQ_HRTIMER_DEFAULT=3Dy
> >>> =
> >>> J.
> >>>=A0 =A0 =A0=A0=A0
> >> There is another question I've got :S.
> >> =
> >> spinymouse-sudo@64studio:~$ ls -l /dev | grep
> hpet
> >> crw-rw----=A0 1
> root=A0=A0=A0root=A0 =A0 10, 228 2009-11-07
> 13:38 hpet
> >> =
> >> The group for hpet isn't audio, thus I guess a
> user won't
> >> be able to use it?!
> >> =
> >> Oops, "# CONFIG_SND_HRTIMER is not set", has this
> now
> >> become something I should post to the 64 Studio
> list? It's the default for the
> >> 64 Studio kernel. It's not a self build kernel.
> >> =
> >> spinymouse-sudo@64studio:~$ cat
> >> /boot/config-2.6.29-1-multimedia-amd64 | grep
> CONFIG_SND
> >> CONFIG_SND=3Dm
> >> CONFIG_SND_TIMER=3Dm
> >> CONFIG_SND_PCM=3Dm
> >> CONFIG_SND_HWDEP=3Dm
> >> CONFIG_SND_RAWMIDI=3Dm
> >> CONFIG_SND_JACK=3Dy
> >> CONFIG_SND_SEQUENCER=3Dm
> >> CONFIG_SND_SEQ_DUMMY=3Dm
> >> CONFIG_SND_OSSEMUL=3Dy
> >> CONFIG_SND_MIXER_OSS=3Dm
> >> CONFIG_SND_PCM_OSS=3Dm
> >> CONFIG_SND_PCM_OSS_PLUGINS=3Dy
> >> CONFIG_SND_SEQUENCER_OSS=3Dy
> >> # CONFIG_SND_HRTIMER is not set
> >> # CONFIG_SND_DYNAMIC_MINORS is not set
> >> CONFIG_SND_SUPPORT_OLD_API=3Dy
> >> CONFIG_SND_VERBOSE_PROCFS=3Dy
> >> # CONFIG_SND_VERBOSE_PRINTK is not set
> >> # CONFIG_SND_DEBUG is not set
> >> CONFIG_SND_VMASTER=3Dy
> >> CONFIG_SND_MPU401_UART=3Dm
> >> CONFIG_SND_OPL3_LIB=3Dm
> >> CONFIG_SND_VX_LIB=3Dm
> >> CONFIG_SND_AC97_CODEC=3Dm
> >> CONFIG_SND_DRIVERS=3Dy
> >> CONFIG_SND_PCSP=3Dm
> >> CONFIG_SND_DUMMY=3Dm
> >> CONFIG_SND_VIRMIDI=3Dm
> >> CONFIG_SND_MTS64=3Dm
> >> CONFIG_SND_SERIAL_U16550=3Dm
> >> CONFIG_SND_MPU401=3Dm
> >> CONFIG_SND_PORTMAN2X4=3Dm
> >> CONFIG_SND_AC97_POWER_SAVE=3Dy
> >> CONFIG_SND_AC97_POWER_SAVE_DEFAULT=3D0
> >> CONFIG_SND_SB_COMMON=3Dm
> >> CONFIG_SND_SB16_DSP=3Dm
> >> CONFIG_SND_PCI=3Dy
> >> CONFIG_SND_AD1889=3Dm
> >> CONFIG_SND_ALS300=3Dm
> >> CONFIG_SND_ALS4000=3Dm
> >> CONFIG_SND_ALI5451=3Dm
> >> CONFIG_SND_ATIIXP=3Dm
> >> CONFIG_SND_ATIIXP_MODEM=3Dm
> >> CONFIG_SND_AU8810=3Dm
> >> CONFIG_SND_AU8820=3Dm
> >> CONFIG_SND_AU8830=3Dm
> >> # CONFIG_SND_AW2 is not set
> >> CONFIG_SND_AZT3328=3Dm
> >> CONFIG_SND_BT87X=3Dm
> >> # CONFIG_SND_BT87X_OVERCLOCK is not set
> >> CONFIG_SND_CA0106=3Dm
> >> CONFIG_SND_CMIPCI=3Dm
> >> CONFIG_SND_OXYGEN_LIB=3Dm
> >> CONFIG_SND_OXYGEN=3Dm
> >> CONFIG_SND_CS4281=3Dm
> >> CONFIG_SND_CS46XX=3Dm
> >> CONFIG_SND_CS46XX_NEW_DSP=3Dy
> >> CONFIG_SND_CS5530=3Dm
> >> CONFIG_SND_DARLA20=3Dm
> >> CONFIG_SND_GINA20=3Dm
> >> CONFIG_SND_LAYLA20=3Dm
> >> CONFIG_SND_DARLA24=3Dm
> >> CONFIG_SND_GINA24=3Dm
> >> CONFIG_SND_LAYLA24=3Dm
> >> CONFIG_SND_MONA=3Dm
> >> CONFIG_SND_MIA=3Dm
> >> CONFIG_SND_ECHO3G=3Dm
> >> CONFIG_SND_INDIGO=3Dm
> >> CONFIG_SND_INDIGOIO=3Dm
> >> CONFIG_SND_INDIGODJ=3Dm
> >> CONFIG_SND_EMU10K1=3Dm
> >> CONFIG_SND_EMU10K1X=3Dm
> >> CONFIG_SND_ENS1370=3Dm
> >> CONFIG_SND_ENS1371=3Dm
> >> CONFIG_SND_ES1938=3Dm
> >> CONFIG_SND_ES1968=3Dm
> >> CONFIG_SND_FM801=3Dm
> >> CONFIG_SND_FM801_TEA575X_BOOL=3Dy
> >> CONFIG_SND_FM801_TEA575X=3Dm
> >> CONFIG_SND_HDA_INTEL=3Dm
> >> # CONFIG_SND_HDA_HWDEP is not set
> >> CONFIG_SND_HDA_INPUT_BEEP=3Dy
> >> CONFIG_SND_HDA_CODEC_REALTEK=3Dy
> >> CONFIG_SND_HDA_CODEC_ANALOG=3Dy
> >> CONFIG_SND_HDA_CODEC_SIGMATEL=3Dy
> >> CONFIG_SND_HDA_CODEC_VIA=3Dy
> >> CONFIG_SND_HDA_CODEC_ATIHDMI=3Dy
> >> CONFIG_SND_HDA_CODEC_NVHDMI=3Dy
> >> CONFIG_SND_HDA_CODEC_INTELHDMI=3Dy
> >> CONFIG_SND_HDA_ELD=3Dy
> >> CONFIG_SND_HDA_CODEC_CONEXANT=3Dy
> >> CONFIG_SND_HDA_CODEC_CMEDIA=3Dy
> >> CONFIG_SND_HDA_CODEC_SI3054=3Dy
> >> CONFIG_SND_HDA_GENERIC=3Dy
> >> CONFIG_SND_HDA_POWER_SAVE=3Dy
> >> CONFIG_SND_HDA_POWER_SAVE_DEFAULT=3D0
> >> CONFIG_SND_HDSP=3Dm
> >> CONFIG_SND_HDSPM=3Dm
> >> CONFIG_SND_HIFIER=3Dm
> >> CONFIG_SND_ICE1712=3Dm
> >> CONFIG_SND_ICE1724=3Dm
> >> CONFIG_SND_INTEL8X0=3Dm
> >> CONFIG_SND_INTEL8X0M=3Dm
> >> CONFIG_SND_KORG1212=3Dm
> >> CONFIG_SND_MAESTRO3=3Dm
> >> CONFIG_SND_MIXART=3Dm
> >> CONFIG_SND_NM256=3Dm
> >> CONFIG_SND_PCXHR=3Dm
> >> CONFIG_SND_RIPTIDE=3Dm
> >> CONFIG_SND_RME32=3Dm
> >> CONFIG_SND_RME96=3Dm
> >> CONFIG_SND_RME9652=3Dm
> >> CONFIG_SND_SONICVIBES=3Dm
> >> CONFIG_SND_TRIDENT=3Dm
> >> CONFIG_SND_VIA82XX=3Dm
> >> CONFIG_SND_VIA82XX_MODEM=3Dm
> >> CONFIG_SND_VIRTUOSO=3Dm
> >> CONFIG_SND_VX222=3Dm
> >> CONFIG_SND_YMFPCI=3Dm
> >> CONFIG_SND_SPI=3Dy
> >> CONFIG_SND_USB=3Dy
> >> CONFIG_SND_USB_AUDIO=3Dm
> >> CONFIG_SND_USB_USX2Y=3Dm
> >> CONFIG_SND_USB_CAIAQ=3Dm
> >> CONFIG_SND_USB_CAIAQ_INPUT=3Dy
> >> CONFIG_SND_USB_US122L=3Dm
> >> CONFIG_SND_PCMCIA=3Dy
> >> CONFIG_SND_VXPOCKET=3Dm
> >> CONFIG_SND_PDAUDIOCF=3Dm
> >> # CONFIG_SND_SOC is not set
> >> _______________________________________________
> >> Linux-audio-dev mailing list
> >> Linux-audio-dev@lists.linuxaudio.org
> >> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
> >> =
> >>=A0 =A0=A0=A0
> > =
> > =
> >=A0 =A0 =A0=A0=A0
> >=A0=A0=A0
> =
> -- Secret of Tux: http://images.wallaceandgromit.com/user_uploads/forum_t=
humbnails/5/75/355.jpg
> "Gromit bit me" says HMV dog: http://img.dailymail.co.uk/i/pix/2007/03_03=
/GomitHMVPA_468x319.jpg
> =
> =
=
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

2009/11/7 James Warden :
>
> You can read more at
> http://en.wikipedia.org/wiki/High_Precision_Event_Timer
>
Thanks for your interrest.
I found some kernel docu:
http://www.mjmwired.net/kernel/Documentation/timers/
And:
http://lwn.net/Articles/167897/
Looks like HPET and RTC are hardware devices, where HPET is meant
to be superior and replace the RTC.
I still don't get: What is the HR-timer ?
I mean how does it compare to the HPET ?
When to decide for the HPET, when for the HRT api ?
Does one if it depend on the other ?
The kernel-devs seem to distinguish between "high-resolution clock" (=hpet ??)
and HR-timer :
" We used the high-resolution clock subsystem ontop of hrtimers to verify
152 the hrtimer implementation details in praxis ... "
--
E.R.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

On Sat, Nov 7, 2009 at 2:51 PM, Emanuel Rumpf wrote:
> Looks like HPET and RTC are hardware devices, where HPET is meant
> to be superior and replace the RTC.
correct, to a large extent.
> I still don't get: What is the HR-timer ?
> I mean how does it compare to the HPET ?
> When to decide for the HPET, when for the HRT =A0api ?
> Does one if it depend on the other ?
Modern motherboads come with timers that are capable of massively
higher precision than older ones, and allow for very precise
scheduling of timer interrupts quite along time in advance of the
timer going off. The existence of this kind of capability can be used
to implement system scheduling in some moderately different ways.
HR-Timer is the name given to some kernel patches (now in the
mainstream kernel) that allowed the use of this timing hardware. The
changes were a mix of new code that deals with the new capabilities,
and patches that reimplement the existing system timer/scheduling
design using the new hardware.
So, HR-Timer (patches/code/design) requires a high res clock (like HPET).
Note that one of the possible ways to use the HR Time infrastructure
is to go totally tickless. In this design, the kernel is no longer
woken at fixed, regular intervals as has been the case for the entire
history of Linux. Instead, the kernel constantly adds new deadline
times which, when expired, generate an interrupt. In the very, very
unlikely case of there being only one process that is runnable, you
can it without any timer deadlines at all (until some other process
becomes runnable). Obviously, its rather complex, but also totally
awesome stuff. This is separate from HR-Timer, but relies upon it, and
it generally referred to as a "tickless kernel".
the HR-Timer infrastructure is a MUCH better basis for scheduling
MIDI. Even with RTC=3D10000 (10^4), you still don't have a clock that is
running in sync with the nominal MIDI data rate. with HR-Timer in
place, you can actually schedule the delivery of MIDI bytes precisely
on time ("wake me up in another 0.3msecs") and not rely on a
metronomic tick like RTC.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Summarized:
I guess my mobo supports hpet :).
$ dmesg | grep -i hpet
[ 0.000000] ACPI: HPET 77EE89C0, 0038 (r1 ATI ASUSACPI 42302E31
AWRD 98)
[ 0.000000] ACPI: HPET id: 0x8200 base: 0xfed00000
[ 0.000999] hpet clockevent registered
[ 0.000999] HPET: 4 timers in total, 0 timers will be used for
per-cpu timer
[ 0.177117] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0, 0
[ 0.177123] hpet0: 4 comparators, 32-bit 14.318180 MHz counter
[ 1.166497] rtc0: alarms up to one month, 242 bytes nvram, hpet irqs
1. The kernel has to support it too.
2. If the kernel-rt does support it, I need to add a startup script:
chgrp audio /dev/hpet
echo 1024 > /proc/sys/dev/hpet/max-user-freq
modprobe snd-hrtimer

Here I don't understand what the value 1024, written to max-user-freq
does mean ;).
3. I need to launch JACK2 with the option "-c", e.g.:
jackd -Rc h -dalsa -dhw:0 -r96000 -p512 -n2 -Xseq
4. The sequencer timing source needs to be set up to hpet or hrtimer too?
rosegarden -v 1.7.3 and qtractor -v 0.4.3.1418 aren't able to do it?
Or will the "-c" option for JACK2 replace a chosen timer for Qtractor or
Rosegarden with hpet?
---
"With a Linux kernel, you need the newer "rtc-cmos" hardware clock
device driver rather than the original "rtc" driver."
(http://en.wikipedia.org/wiki/High_Precision_Event_Timer)
I guess this is within the vanilla kernel source code?!
Cheers,
Ralf
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Ralph,
As I said, this startup script is something I wrote a long time ago. The ma=
x-user-freq is for apps like video players, some polling frequency for impr=
oving the playback performance (smoother playback). The default used to be =
64Hz. Increasing it to 1024 was making mplayer or xine much more performant=
. =
Actually, I will reboot my DAW when I have some spare time without this sta=
rtup script (except for the /dev/hpet group permission) and see what the ne=
wer kernel sets as default. =
J.
--- On Sat, 11/7/09, Ralf Mardorf wrote:
> From: Ralf Mardorf
> Subject: Re: [LAD] timers
> To: "Paul Davis" , "Emanuel Rumpf" , "James Warden"
> Cc: linux-audio-dev@lists.linuxaudio.org
> Date: Saturday, November 7, 2009, 4:40 PM
> Summarized:
> =
> I guess my mobo supports hpet :).
> =
> $ dmesg | grep -i hpet
> [=A0 =A0 0.000000] ACPI: HPET 77EE89C0, 0038 (r1
> ATI=A0 =A0 ASUSACPI 42302E31 AWRD=A0 =A0
> =A0=A0=A098)
> [=A0 =A0 0.000000] ACPI: HPET id: 0x8200 base:
> 0xfed00000
> [=A0 =A0 0.000999] hpet clockevent registered
> [=A0 =A0 0.000999] HPET: 4 timers in total, 0 timers
> will be used for per-cpu timer
> [=A0 =A0 0.177117] hpet0: at MMIO 0xfed00000, IRQs 2,
> 8, 0, 0
> [=A0 =A0 0.177123] hpet0: 4 comparators, 32-bit
> 14.318180 MHz counter
> [=A0 =A0 1.166497] rtc0: alarms up to one month, 242
> bytes nvram, hpet irqs
> =
> 1. The kernel has to support it too.
> 2. If the kernel-rt does support it, I need to add a
> startup script:
> =
> =A0=A0=A0chgrp audio /dev/hpet
> =A0=A0=A0echo 1024 >
> /proc/sys/dev/hpet/max-user-freq
> =A0=A0=A0modprobe snd-hrtimer
> =A0 =A0=A0=A0
> Here I don't understand what the value 1024, written to
> max-user-freq does mean ;).
> =
> 3. I need to launch JACK2 with the option "-c", e.g.:
> =
> jackd -Rc h -dalsa -dhw:0 -r96000 -p512 -n2 -Xseq
> =
> 4. The sequencer timing source needs to be set up to hpet
> or hrtimer too?
> rosegarden -v 1.7.3 and qtractor -v 0.4.3.1418 aren't able
> to do it?
> =
> Or will the "-c" option for JACK2 replace a chosen timer
> for Qtractor or Rosegarden with hpet?
> =
> ---
> =
> "With a Linux kernel, you need the newer "rtc-cmos"
> hardware clock device driver rather than the original "rtc"
> driver." (http://en.wikipedia.org/wiki/High_Precision_Event_Timer)
> =
> I guess this is within the vanilla kernel source code?!
> =
> Cheers,
> Ralf
> =
=
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

On Sat, Nov 07, 2009 at 02:42:56PM +0100, Ralf Mardorf wrote:
> spinymouse-sudo@64studio:~$ ll /dev/hpet
> bash: ll: command not found
See below.
> spinymouse-sudo@64studio:~$ ls /dev | grep hpet
> hpet
Useless Use Of Pipe.
> spinymouse-sudo@64studio:~$ cat /boot/config-2.6.29-1-multimedia-amd64 |
> grep CONFIG_SND
Useless Use Of Cat.[0]
Why is it that you constantly prove your lack of knowledge on LAD? Looks
like you don't even know the most basic UNIX commands. That is:
adi@chopin:~$ ls -l /dev/hpet
crw-rw---- 1 root root 10, 228 Nov 7 16:03 /dev/hpet
"ll" has historically been an alias for "ls -l" on some systems, let's
say SuSE 4.x ;)
I suggest you check what the "D" in "LAD" stands for and ask yourself if
this is really the right audience for your Linux n00b questions.
HTH
[0] http://en.wikipedia.org/wiki/Cat_%28Unix%29#Useless_use_of_cat
--
mail: adi@thur.de http://adi.thur.de PGP/GPG: key via keyserver
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

--0016369207094aa32c0477dd24b2
Content-Type: text/plain; charset=ISO-8859-1
2009/11/8 Adrian Knoth
> On Sat, Nov 07, 2009 at 02:42:56PM +0100, Ralf Mardorf wrote:
>
> > spinymouse-sudo@64studio:~$ ll /dev/hpet
> > bash: ll: command not found
>
> See below.
>
> > spinymouse-sudo@64studio:~$ ls /dev | grep hpet
> > hpet
>
> Useless Use Of Pipe.
>
> > spinymouse-sudo@64studio:~$ cat /boot/config-2.6.29-1-multimedia-amd64 |
> > grep CONFIG_SND
>
> Useless Use Of Cat.[0]
>
>
>
> Why is it that you constantly prove your lack of knowledge on LAD? Looks
> like you don't even know the most basic UNIX commands. That is:
>
> adi@chopin:~$ ls -l /dev/hpet
> crw-rw---- 1 root root 10, 228 Nov 7 16:03 /dev/hpet
>
> "ll" has historically been an alias for "ls -l" on some systems, let's
> say SuSE 4.x ;)
>
> I suggest you check what the "D" in "LAD" stands for and ask yourself if
> this is really the right audience for your Linux n00b questions.
>
>
> HTH
>
>
> [0] http://en.wikipedia.org/wiki/Cat_%28Unix%29#Useless_use_of_cat
Holy shit, wait, is that one a demonstration of a "useless use of reply in
e-mail"? Good one!
People should _never_ post aliases. What SuSE or corporationX/distributionY
does is their useless business, and customers/users should never bring the
resulting useless habits outside.
There are countless users on this and related lists (there is no way to bar
them from subscribing) who possess such useless knowledge, maybe we should
start crucifying them for being uselessly inferior?
Oh wait, sorry. Ignore this (yet another useless) reply!
--0016369207094aa32c0477dd24b2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
2009/11/8 Adrian Knoth <adi@drcomp.erfurt.thur.de>
On Sat, Nov 07, 2009 at 02:42:56PM +0100, Ralf Mardorf wr=
ote:

> spinymouse-sudo@64studio:~$ ll /dev/hpet
> bash: ll: command not found

See below.

> spinymouse-sudo@64studio:~$ ls /dev | grep hpet
> hpet

Useless Use Of Pipe.

> spinymouse-sudo@64studio:~$ cat /boot/config-2.6.29-1-multimedia-amd64=
|
> grep CONFIG_SND

Useless Use Of Cat.[0]



Why is it that you constantly prove your lack of knowledge on LAD? Looks
like you don't even know the most basic UNIX commands. That is:

adi@chopin:~$ ls -l /dev/hpet
crw-rw---- 1 root root 10, 228 Nov =A07 16:03 /dev/hpet

"ll" has historically been an alias for "ls -l" on some=
systems, let's
say SuSE 4.x ;)

I suggest you check what the "D" in "LAD" stands for an=
d ask yourself if
this is really the right audience for your Linux n00b questions.


HTH


[0] http://en.wikipedia.org/wiki/Cat_%28Unix%29#Useless_u=
se_of_catHoly shit, wait, is that one =
a demonstration of a "useless use of reply in e-mail"? Good one!
People should _never_ post aliases. What SuSE or corpor=
ationX/distributionY does is their useless business, and customers/users sh=
ould never bring the resulting useless habits outside.
There are countless users on this and related lists (there is no way t=
o bar them from subscribing) who possess such useless knowledge, maybe we s=
hould start crucifying them for being uselessly inferior?
Oh wait, sorry. Ignore this (yet another useless) reply!
--0016369207094aa32c0477dd24b2--

--001636920709b3c4a40477dd3694
Content-Type: text/plain; charset=ISO-8859-1
2009/11/8 Ray Rashif
> 2009/11/8 Adrian Knoth
>
>> On Sat, Nov 07, 2009 at 02:42:56PM +0100, Ralf Mardorf wrote:
>>
>> > spinymouse-sudo@64studio:~$ ll /dev/hpet
>> > bash: ll: command not found
>>
>> See below.
>>
>> > spinymouse-sudo@64studio:~$ ls /dev | grep hpet
>> > hpet
>>
>> Useless Use Of Pipe.
>>
>> > spinymouse-sudo@64studio:~$ cat /boot/config-2.6.29-1-multimedia-amd64
>> |
>> > grep CONFIG_SND
>>
>> Useless Use Of Cat.[0]
>>
>>
>>
>> Why is it that you constantly prove your lack of knowledge on LAD? Looks
>> like you don't even know the most basic UNIX commands. That is:
>>
>> adi@chopin:~$ ls -l /dev/hpet
>> crw-rw---- 1 root root 10, 228 Nov 7 16:03 /dev/hpet
>>
>> "ll" has historically been an alias for "ls -l" on some systems, let's
>> say SuSE 4.x ;)
>>
>> I suggest you check what the "D" in "LAD" stands for and ask yourself if
>> this is really the right audience for your Linux n00b questions.
>>
>>
>> HTH
>>
>>
>> [0] http://en.wikipedia.org/wiki/Cat_%28Unix%29#Useless_use_of_cat
>
>
> Holy shit, wait, is that one a demonstration of a "useless use of reply in
> e-mail"? Good one!
>
> People should _never_ post aliases. What SuSE or corporationX/distributionY
> does is their useless business, and customers/users should never bring the
> resulting useless habits outside.
>
> There are countless users on this and related lists (there is no way to bar
> them from subscribing) who possess such useless knowledge, maybe we should
> start crucifying them for being uselessly inferior?
>
> Oh wait, sorry. Ignore this (yet another useless) reply!
>
On a serious note, someone has got to enforce a way to stop topics like
these from being posted to LAD. Some kind of warning at
http://linuxaudio.org/mailarchive/ should suffice, I think.
--001636920709b3c4a40477dd3694
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
2009/11/8 Ray Rashif <schivmeister@gmail.com>
2009/11/8 Adrian Knoth <adi@drcomp.erfurt.thur.de>
On Sat, Nov 07, 2009 at 02:42:56PM +0100, Ralf Mardorf wrote:

> spinymouse-sudo@64studio:~$ ll /dev/hpet
> bash: ll: command not found

See below.

> spinymouse-sudo@64studio:~$ ls /dev | grep hpet
> hpet

Useless Use Of Pipe.

> spinymouse-sudo@64studio:~$ cat /boot/config-2.6.29-1-multimedia-amd64=
|
> grep CONFIG_SND

Useless Use Of Cat.[0]



Why is it that you constantly prove your lack of knowledge on LAD? Looks
like you don't even know the most basic UNIX commands. That is:

adi@chopin:~$ ls -l /dev/hpet
crw-rw---- 1 root root 10, 228 Nov =A07 16:03 /dev/hpet

"ll" has historically been an alias for "ls -l" on some=
systems, let's
say SuSE 4.x ;)

I suggest you check what the "D" in "LAD" stands for an=
d ask yourself if
this is really the right audience for your Linux n00b questions.


HTH


[0] http://en.wikipedia.org/wiki/Cat_%28Unix%29#Useless_u=
se_of_catHoly shit, wait, is tha=
t one a demonstration of a "useless use of reply in e-mail"? Good=
one!
People should _never_ post aliases. What SuSE or corpor=
ationX/distributionY does is their useless business, and customers/users sh=
ould never bring the resulting useless habits outside.
There are countless users on this and related lists (there is no way t=
o bar them from subscribing) who possess such useless knowledge, maybe we s=
hould start crucifying them for being uselessly inferior?
Oh wait, sorry. Ignore this (yet another useless) reply!
On a serious note, someone has got to enforce a=
way to stop topics like these from being posted to LAD. Some kind of warni=
ng at=A0http://linuxaudio.or=
g/mailarchive/ should suffice, I think.
--001636920709b3c4a40477dd3694--

hey guys,
I suggest we leave it here.
Ralph got some info about timers, and that's what counts. Why crap over wha=
t really matters ?
J.
--- On Sun, 11/8/09, Ray Rashif wrote:
> From: Ray Rashif
> Subject: Re: [LAD] timers
> To: linux-audio-dev@lists.linuxaudio.org
> Date: Sunday, November 8, 2009, 9:46 AM
> 2009/11/8 Adrian Knoth
> =
> =
> On Sat, Nov 07, 2009 at 02:42:56PM +0100,
> Ralf Mardorf wrote:
> =
> =
> =
> > spinymouse-sudo@64studio:~$ ll /dev/hpet
> =
> > bash: ll: command not found
> =
> =
> =
> See below.
> =
> =
> =
> > spinymouse-sudo@64studio:~$ ls /dev | grep hpet
> =
> > hpet
> =
> =
> =
> Useless Use Of Pipe.
> =
> =
> =
> > spinymouse-sudo@64studio:~$ cat
> /boot/config-2.6.29-1-multimedia-amd64 |
> =
> > grep CONFIG_SND
> =
> =
> =
> Useless Use Of Cat.[0]
> =
> =
> =
> =
> =
> =
> =
> Why is it that you constantly prove your lack of knowledge
> on LAD? Looks
> =
> like you don't even know the most basic UNIX commands.
> That is:
> =
> =
> =
> adi@chopin:~$ ls -l /dev/hpet
> =
> crw-rw---- 1 root root 10, 228 Nov =A07 16:03 /dev/hpet
> =
> =
> =
> "ll" has historically been an alias for "ls
> -l" on some systems, let's
> =
> say SuSE 4.x ;)
> =
> =
> =
> I suggest you check what the "D" in
> "LAD" stands for and ask yourself if
> =
> this is really the right audience for your Linux n00b
> questions.
> =
> =
> =
> =
> =
> HTH
> =
> =
> =
> =
> =
> [0] http://en.wikipedia.org/wiki/Cat_%28Unix%29#Useless_use_of_cat
> Holy shit, wait, is that one a demonstration of
> a "useless use of reply in e-mail"? Good
> one!
> =
> =
> People should _never_ post aliases. What SuSE or
> corporationX/distributionY does is their useless business,
> and customers/users should never bring the resulting useless
> habits outside.
> =
> =
> There are countless users on this and related lists
> (there is no way to bar them from subscribing) who possess
> such useless knowledge, maybe we should start crucifying
> them for being uselessly inferior?
> =
> =
> Oh wait, sorry. Ignore this (yet another
> useless) reply!
> =
> -----Inline Attachment Follows-----
> =
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
> =
=
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

On Sun, Nov 8, 2009 at 2:46 PM, Ray Rashif wrote:
> 2009/11/8 Adrian Knoth
>> [...]
>> [0] http://en.wikipedia.org/wiki/Cat_%28Unix%29#Useless_use_of_cat
>
> Holy shit, wait, is that one a demonstration of a "useless use of reply in
> e-mail"? Good one!
It's certainly a candidate for weirdest irrelevant flame interjected
into an otherwise reasonable thread.
> On a serious note, someone has got to enforce a way to stop topics like these from being posted to LAD.
No, this is fine for LAD. Emanuel is a developer and he had a
question that's relevant to developers. The thread digressed a bit,
but in a gentle enough way, and we all know how to ignore a thread if
we don't want to read it.
This is not such a high-traffic list, at least when you weed out the
stupid flames.
Chris
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Thanx to everybody :). JACK can use hpet and hrtimer is available in
Qtractors options :).
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Emanuel Rumpf wrote:
> Opening the hr-timer with rosegarden freezes my whole system here,
> what could cause that ?
>
I guess Open Octave is based on Rosegarden. While Qtractor is fine with
HR timer on my system, Open Octave freezes my system too. I only was
able to push reset, resp. I didn't try magic keys.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

On Mon, 09 Nov 2009 16:40:41 +0100
Ralf Mardorf wrote:
> Emanuel Rumpf wrote:
> > Opening the hr-timer with rosegarden freezes my whole system here,
> > what could cause that ?
> >
>
> I guess Open Octave is based on Rosegarden. While Qtractor is fine
> with HR timer on my system, Open Octave freezes my system too. I only
> was able to push reset, resp. I didn't try magic keys.
Hmmm, I only find system-timer in either application.
I recently found a line in dmesg that hpet wasn't enabled and I could
try the boot option hpet=force.
After doing this I have a /dev/hpet entry but still, only system, no rt
or hpet in either app.
Also no freezes tough ;)
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

On Mon, Nov 9, 2009 at 3:40 PM, Ralf Mardorf wrote:
> Emanuel Rumpf wrote:
>> Opening the hr-timer with rosegarden freezes my whole system here,
>> what could cause that ?
>
> I guess Open Octave is based on Rosegarden. While Qtractor is fine with
> HR timer on my system, Open Octave freezes my system too. I only was
> able to push reset, resp. I didn't try magic keys.
If using the timer locks the system, then it's a kernel problem.
I believe that's why Emanuel was asking here in the first place --
he'd already discussed it on rosegarden-devel, but got nowhere.
Chris
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

On Mon, 9 Nov 2009 16:47:07 +0100
wrote:
> On Mon, 09 Nov 2009 16:40:41 +0100
> Ralf Mardorf wrote:
>
> > Emanuel Rumpf wrote:
> > > Opening the hr-timer with rosegarden freezes my whole system here,
> > > what could cause that ?
> > >
> >
> > I guess Open Octave is based on Rosegarden. While Qtractor is fine
> > with HR timer on my system, Open Octave freezes my system too. I
> > only was able to push reset, resp. I didn't try magic keys.
>
> Hmmm, I only find system-timer in either application.
> I recently found a line in dmesg that hpet wasn't enabled and I could
> try the boot option hpet=force.
> After doing this I have a /dev/hpet entry but still, only system, no
> rt or hpet in either app.
>
> Also no freezes tough ;)
Ralf helped me a bit further off-list.
It seems I needed to modprobe snd-hrtimer
Now oom pretty much freezes as well when I tell it to use that,
qtractor doesn't complain, at least not immediately, couldn't try
further yet.
Kernel is 2.6.31.4-rt14
Haven't tried this yet since I'm not sure it makes sense:
chgrp audio /dev/hpet
So even when hpet is available, hrtimer is the one to use?
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

On Mon, 9 Nov 2009 17:43:12 +0100
wrote:
> On Mon, 9 Nov 2009 16:47:07 +0100
> wrote:
>
> > On Mon, 09 Nov 2009 16:40:41 +0100
> > Ralf Mardorf wrote:
> >
> > > Emanuel Rumpf wrote:
> > > > Opening the hr-timer with rosegarden freezes my whole system
> > > > here, what could cause that ?
> > > >
> > >
> > > I guess Open Octave is based on Rosegarden. While Qtractor is fine
> > > with HR timer on my system, Open Octave freezes my system too. I
> > > only was able to push reset, resp. I didn't try magic keys.
> >
> > Hmmm, I only find system-timer in either application.
> > I recently found a line in dmesg that hpet wasn't enabled and I
> > could try the boot option hpet=force.
> > After doing this I have a /dev/hpet entry but still, only system, no
> > rt or hpet in either app.
> >
> > Also no freezes tough ;)
>
> Ralf helped me a bit further off-list.
> It seems I needed to modprobe snd-hrtimer
> Now oom pretty much freezes as well when I tell it to use that,
> qtractor doesn't complain, at least not immediately, couldn't try
> further yet.
>
> Kernel is 2.6.31.4-rt14
>
> Haven't tried this yet since I'm not sure it makes sense:
> chgrp audio /dev/hpet
>
> So even when hpet is available, hrtimer is the one to use?
Sorry for replying to myself again, but I'm still not sure about this
point:
chgrp audio /dev/hpet
... will make hpet usable for the group audio.

--00504502eacd54ee5b0477fb15c2
Content-Type: text/plain; charset=ISO-8859-1
2009/11/10
> On Mon, 9 Nov 2009 17:43:12 +0100
> wrote:
>
> > On Mon, 9 Nov 2009 16:47:07 +0100
> > wrote:
> >
> > > On Mon, 09 Nov 2009 16:40:41 +0100
> > > Ralf Mardorf wrote:
> > >
> > > > Emanuel Rumpf wrote:
> > > > > Opening the hr-timer with rosegarden freezes my whole system
> > > > > here, what could cause that ?
> > > > >
> > > >
> > > > I guess Open Octave is based on Rosegarden. While Qtractor is fine
> > > > with HR timer on my system, Open Octave freezes my system too. I
> > > > only was able to push reset, resp. I didn't try magic keys.
> > >
> > > Hmmm, I only find system-timer in either application.
> > > I recently found a line in dmesg that hpet wasn't enabled and I
> > > could try the boot option hpet=force.
> > > After doing this I have a /dev/hpet entry but still, only system, no
> > > rt or hpet in either app.
> > >
> > > Also no freezes tough ;)
> >
> > Ralf helped me a bit further off-list.
> > It seems I needed to modprobe snd-hrtimer
> > Now oom pretty much freezes as well when I tell it to use that,
> > qtractor doesn't complain, at least not immediately, couldn't try
> > further yet.
> >
> > Kernel is 2.6.31.4-rt14
> >
> > Haven't tried this yet since I'm not sure it makes sense:
> > chgrp audio /dev/hpet
> >
> > So even when hpet is available, hrtimer is the one to use?
>
> Sorry for replying to myself again, but I'm still not sure about this
> point:
>
> chgrp audio /dev/hpet
> ... will make hpet usable for the group audio.
> HR Timer as sequencer source will use HPET.
>
> Since hrtimer uses hpet if available and apps use hrtimer, why would I
> need to allow some audio group to access hpet directly?
> More so, changing the group of /dev/hpet seems very strange to me.
>
> Can someone please clarify?
>
> Regards,
> Philipp
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
>
The only way to clarify is boot once with rc.local doing that, then again
without.
It's a character device, not raw, so this may not be needed. But on the
other hand, it _is_ a device, and if there needs to be I/O, there needs to
be r/w access, there needs to be permission.
--00504502eacd54ee5b0477fb15c2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
2009/11/10 <hollu=
nder@gmx.at>
On Mon, 9 Nov 2009 17:43:12 +0100
<hollunder@gmx.at> wrote:

> On Mon, 9 Nov 2009 16:47:07 +0100
> <hollunder@gmx.at> wrote=
:
>
> > On Mon, 09 Nov 2009 16:40:41 +0100
> > Ralf Mardorf <ra=
lf.mardorf@alice-dsl.net> wrote:
> >
> > > Emanuel Rumpf wrote:
> > > > Opening the hr-timer with rosegarden freezes my whole s=
ystem
> > > > here, what could cause that ?
> > > >
> > >
> > > I guess Open Octave is based on Rosegarden. While Qtractor i=
s fine
> > > with HR timer on my system, Open Octave freezes my system to=
o. I
> > > only was able to push reset, resp. I didn't try magic ke=
ys.
> >
> > Hmmm, I only find system-timer in either application.
> > I recently found a line in dmesg that hpet wasn't enabled and=
I
> > could try the boot option hpet=3Dforce.
> > After doing this I have a /dev/hpet entry but still, only system,=
no
> > rt or hpet in either app.
> >
> > Also no freezes tough ;)
>
> Ralf helped me a bit further off-list.
> It seems I needed to modprobe snd-hrtimer
> Now oom pretty much freezes as well when I tell it to use that,
> qtractor doesn't complain, at least not immediately, couldn't =
try
> further yet.
>
> Kernel is 2.6.31.4-rt14
>
> Haven't tried this yet since I'm not sure it makes sense:
> chgrp audio /dev/hpet
>
> So even when hpet is available, hrtimer is the one to use?

Sorry for replying to myself again, but I'm still not sure about this
point:

chgrp audio /dev/hpet
... will make hpet usable for the group audio. =A0<--?

HR Timer as sequencer source will use HPET.

Since hrtimer uses hpet if available and apps use hrtimer, why would I
need to allow some audio group to access hpet directly?
More so, changing the group of /dev/hpet seems very strange to me.

Can someone please clarify?

Regards,
Philipp
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lis=
ts.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-de=
v
The only way to clarify is boot once with rc.lo=
cal doing that, then again without.It's a cha=
racter device, not raw, so this may not be needed. But on the other hand, i=
t _is_ a device, and if there needs to be I/O, there needs to be r/w access=
, there needs to be permission.
--00504502eacd54ee5b0477fb15c2--

hollunder@gmx.at wrote:
> wrote:
> > It seems I needed to modprobe snd-hrtimer
> > Now oom pretty much freezes as well when I tell it to use that,
Does oom or the entire system freeze?
> > Haven't tried this yet since I'm not sure it makes sense:
> > chgrp audio /dev/hpet
> >
> > So even when hpet is available, hrtimer is the one to use?
>
> chgrp audio /dev/hpet
> ... will make hpet usable for the group audio.

On Tue, 10 Nov 2009 10:03:34 +0100
Clemens Ladisch wrote:
> hollunder@gmx.at wrote:
> > wrote:
> > > It seems I needed to modprobe snd-hrtimer
> > > Now oom pretty much freezes as well when I tell it to use that,
>
> Does oom or the entire system freeze?
In my case the whole system got almost in-responsive, mouse movement
took place once in a second or so, I guess it totally hogged the CPU. I
managed to revert the setting and everything returned to normal.
> > > Haven't tried this yet since I'm not sure it makes sense:
> > > chgrp audio /dev/hpet
> > >
> > > So even when hpet is available, hrtimer is the one to use?
> >
> > chgrp audio /dev/hpet
> > ... will make hpet usable for the group audio.
> /dev/hpet is a userspace interface for application that want to
> directly access the HPET device. No applications (except Jack) want
> to do that; they use the standard high-resolution timer functions
> which internally use the HPET (or the LAPIC timer), but this is done
> in the kernel and is independent of the /dev/hpet interface.
>
>
> HTH
> Clemens
Ok, thanks.
It seems jack doesn't use it by default either, only when it's run with
the option '-c h'. Only then it says:
This system has no accessible HPET device (Permission denied)
I'm wondering if this is necessary for best possible midi timing or
irrelevant.
Thanks,
Philipp
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Thanks Clemens,
you wrote in an unrelated thread:
dmesg | grep -i hpet
I wasn't clever enough to use -i (ignore case) when I checked whether
hpet=force worked.
$ 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, 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)
My interpretation of this is that my motherboard is simply too old and
simply doesn't have a hpet timer.
Thanks for the help everyone,
guess I'm out of this until I manage to get a new machine.
Best regards,
Philipp
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

hollunder@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.
See /proc/iomem at address fed00000.
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?
> 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
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

On Tue, 10 Nov 2009 12:48:42 +0100
Clemens Ladisch wrote:
> hollunder@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@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Philipp,
The alsa-lib source package comes with some test programs. One is called ti=
mer.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=3D1 card=3D0 device=3D3 # 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=3D1, which is my PCI card).
class, sclass, device, etc are defined in the ALSA lib API doc.
class=3D1 is I think GLOBAL
sclass=3D-1 is slave class =3D NONE I think (not in front of the API doc). =
device=3D3 seems to confirm what Clemens said about kernel reserved timers.
(when you list the timers with ./timer list, the GLOBAL ones will show up w=
ith a card=3D-1. Yet, to test them as I indicated above, you will need to i=
nvoke ./timer with card=3DX with X =3D 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 i=
s used by default.
On the other hand, when I set rosegarden to use the HR timer, I get a compl=
ete 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@gmx.at wrote:
> From: hollunder@gmx.at
> Subject: Re: [LAD] Timers, hpet, hrtimer -> kind of solved (for too old m=
otherboards)
> To: linux-audio-dev@lists.linuxaudio.org
> Date: Tuesday, November 10, 2009, 8:40 AM
> On Tue, 10 Nov 2009 12:48:42 +0100
> Clemens Ladisch
> wrote:
> =
> > hollunder@gmx.at
> wrote:
> > > $=A0 dmesg | grep -i hpet
> > > Kernel command line:
> > >
> root=3D/dev/disk/by-uuid/3e47466f-5ca1-499b-85fc-152074f36364
> ro
> > > hpet=3Dforce pci 0000:00:11.0: Failed to force
> enable HPET
> > > =
> > > /dev/hpet was still created,
> > =
> > Then you have it.=A0 The message is probably
> because it doesn't need
> > to be forced.
> =
> I added hpet=3Dforce because I found a line in dmesg that
> said
> something along the lines of: hpet isn't available, try
> hpet=3Dforce
> =
> > 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.=A0 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.=A0 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@lists.linuxaudio.org
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
> =
=
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev