7 Nov
2009
7 Nov
'09
7:32 a.m.
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.
7 Nov
7 Nov
8:04 a.m.
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
8:34 a.m.
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 <ralf.mardorf(a)alice-dsl.net> wrote:
From: Ralf Mardorf <ralf.mardorf(a)alice-dsl.net>
Subject: Re: [LAD] timers
To: "Emanuel Rumpf" <xbran(a)web.de>
Cc: linux-audio-dev(a)lists.linuxaudio.org
Date: Saturday, November 7, 2009, 7:04 AM
Emanuel Rumpf wrote:
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(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
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 ?
8:39 a.m.
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 ## <<< not used
snd_timer 17408 3 snd_hrtimer,snd_seq,snd_pcm
J.
--- On Sat, 11/7/09, James Warden <warjamy(a)yahoo.com> wrote:
From: James Warden <warjamy(a)yahoo.com>
Subject: Re: [LAD] timers
To: "Emanuel Rumpf" <xbran(a)web.de>de>, "Ralf Mardorf"
<ralf.mardorf(a)alice-dsl.net>
Cc: linux-audio-dev(a)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 <ralf.mardorf(a)alice-dsl.net>
wrote:
From: Ralf Mardorf
<ralf.mardorf(a)alice-dsl.net>
Subject: Re: [LAD] timers
To: "Emanuel Rumpf" <xbran(a)web.de>
Cc: linux-audio-dev(a)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(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
9:37 a.m.
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 ## <<< not used
snd_timer 17408 3 snd_hrtimer,snd_seq,snd_pcm
J.
--- On Sat, 11/7/09, James Warden <warjamy(a)yahoo.com> wrote:
--
Secret of Tux:
http://images.wallaceandgromit.com/user_uploads/forum_thumbnails/5/75/355.j…
"Gromit bit me" says HMV dog:
http://img.dailymail.co.uk/i/pix/2007/03_03/GomitHMVPA_468x319.jpg
From: James Warden <warjamy(a)yahoo.com>
Subject: Re: [LAD] timers
To: "Emanuel Rumpf" <xbran(a)web.de>de>, "Ralf Mardorf"
<ralf.mardorf(a)alice-dsl.net>
Cc: linux-audio-dev(a)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 <ralf.mardorf(a)alice-dsl.net>
wrote:
From: Ralf Mardorf
<ralf.mardorf(a)alice-dsl.net>
Subject: Re: [LAD] timers
To: "Emanuel Rumpf" <xbran(a)web.de>
Cc: linux-audio-dev(a)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(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
9:43 a.m.
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:
--
Secret of Tux:
http://images.wallaceandgromit.com/user_uploads/forum_thumbnails/5/75/355.j…
"Gromit bit me" says HMV dog:
http://img.dailymail.co.uk/i/pix/2007/03_03/GomitHMVPA_468x319.jpg
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 ## <<< not used
snd_timer 17408 3 snd_hrtimer,snd_seq,snd_pcm
J.
--- On Sat, 11/7/09, James Warden <warjamy(a)yahoo.com> wrote:
From: James Warden <warjamy(a)yahoo.com>
Subject: Re: [LAD] timers
To: "Emanuel Rumpf" <xbran(a)web.de>de>, "Ralf Mardorf"
<ralf.mardorf(a)alice-dsl.net>
Cc: linux-audio-dev(a)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 <ralf.mardorf(a)alice-dsl.net>
wrote:
From: Ralf Mardorf
<ralf.mardorf(a)alice-dsl.net>
Subject: Re: [LAD] timers
To: "Emanuel Rumpf" <xbran(a)web.de>
Cc: linux-audio-dev(a)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(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
8 Nov
8 Nov
6:07 a.m.
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(a)thur.de http://adi.thur.de PGP/GPG: key via keyserver
10:46 a.m.
2009/11/8 Adrian Knoth <adi(a)drcomp.erfurt.thur.de>
On Sat, Nov 07, 2009 at 02:42:56PM +0100, Ralf Mardorf
wrote:
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!
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
10:51 a.m.
2009/11/8 Ray Rashif <schivmeister(a)gmail.com>
2009/11/8 Adrian Knoth
<adi(a)drcomp.erfurt.thur.de>
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.
On Sat, Nov 07, 2009 at 02:42:56PM +0100, Ralf
Mardorf wrote:
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!
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
10:52 a.m.
hey guys,
I suggest we leave it here.
Ralph got some info about timers, and that's what counts. Why crap over what really
matters ?
J.
--- On Sun, 11/8/09, Ray Rashif <schivmeister(a)gmail.com> wrote:
From: Ray Rashif <schivmeister(a)gmail.com>
Subject: Re: [LAD] timers
To: linux-audio-dev(a)lists.linuxaudio.org
Date: Sunday, November 8, 2009, 9:46 AM
2009/11/8 Adrian Knoth <adi(a)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 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!
-----Inline Attachment Follows-----
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
6:11 p.m.
On Sun, Nov 8, 2009 at 2:46 PM, Ray Rashif <schivmeister(a)gmail.com> wrote:
2009/11/8 Adrian Knoth
<adi(a)drcomp.erfurt.thur.de>
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
9 Nov
9 Nov
9:02 a.m.
Thanx to everybody :). JACK can use hpet and hrtimer is available in
Qtractors options :).
7 Nov
7 Nov
9:45 a.m.
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.
--- On Sat, 11/7/09, Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> wrote:
From: Ralf Mardorf <ralf.mardorf(a)alice-dsl.net>
Subject: Re: [LAD] timers
To: "James Warden" <warjamy(a)yahoo.com>
Cc: "Emanuel Rumpf" <xbran(a)web.de>de>, linux-audio-dev(a)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
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:
-- Secret of Tux:
http://images.wallaceandgromit.com/user_uploads/forum_thumbnails/5/75/355.j…
"Gromit bit me" says HMV dog:
http://img.dailymail.co.uk/i/pix/2007/03_03/GomitHMVPA_468x319.jpg
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 ## <<< not used
snd_timer
17408 3
snd_hrtimer,snd_seq,snd_pcm
J.
--- On Sat, 11/7/09, James Warden <warjamy(a)yahoo.com>
wrote:
> From: James Warden <warjamy(a)yahoo.com>
> Subject: Re: [LAD] timers
> To: "Emanuel Rumpf" <xbran(a)web.de>de>,
"Ralf Mardorf"
<ralf.mardorf(a)alice-dsl.net>
> Cc: linux-audio-dev(a)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 <ralf.mardorf(a)alice-dsl.net>
> wrote:
>
>
>> From: Ralf Mardorf <ralf.mardorf(a)alice-dsl.net>
>> Subject: Re: [LAD] timers
>> To: "Emanuel Rumpf" <xbran(a)web.de>
>> Cc: linux-audio-dev(a)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(a)lists.linuxaudio.org
>> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
>>
>>
>
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
9:52 a.m.
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
9:55 a.m.
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 <ralf.mardorf(a)alice-dsl.net> wrote:
From: Ralf Mardorf <ralf.mardorf(a)alice-dsl.net>
Subject: Re: [LAD] timers
To:
Cc: linux-audio-dev(a)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(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
9:57 a.m.
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 <ralf.mardorf(a)alice-dsl.net> wrote:
--
Secret of Tux:
http://images.wallaceandgromit.com/user_uploads/forum_thumbnails/5/75/355.j…
"Gromit bit me" says HMV dog:
http://img.dailymail.co.uk/i/pix/2007/03_03/GomitHMVPA_468x319.jpg
From: Ralf Mardorf
<ralf.mardorf(a)alice-dsl.net>
Subject: Re: [LAD] timers
To:
Cc: linux-audio-dev(a)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(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
2:41 p.m.
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 <ralf.mardorf(a)alice-dsl.net> wrote:
From: Ralf Mardorf <ralf.mardorf(a)alice-dsl.net>
Subject: Re: [LAD] timers
To: "James Warden" <warjamy(a)yahoo.com>
Cc: linux-audio-dev(a)lists.linuxaudio.org
Date: Saturday, November 7, 2009, 8:57 AM
Thank you very much James and Ray
:).
Ralf
James Warden wrote:
-- Secret of Tux:
http://images.wallaceandgromit.com/user_uploads/forum_thumbnails/5/75/355.j…
"Gromit bit me" says HMV dog:
http://img.dailymail.co.uk/i/pix/2007/03_03/GomitHMVPA_468x319.jpg
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 <ralf.mardorf(a)alice-dsl.net>
wrote:
> From: Ralf Mardorf <ralf.mardorf(a)alice-dsl.net>
> Subject: Re: [LAD] timers
> To: Cc: linux-audio-dev(a)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(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
3:51 p.m.
2009/11/7 James Warden <warjamy(a)yahoo.com>om>:
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.
4:44 p.m.
On Sat, Nov 7, 2009 at 2:51 PM, Emanuel Rumpf <xbran(a)web.de> 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 api ?
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=10000 (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.
5:41 p.m.
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
6:22 p.m.
Ralph,
As I said, this startup script is something I wrote a long time ago. The max-user-freq is
for apps like video players, some polling frequency for improving 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 startup script
(except for the /dev/hpet group permission) and see what the newer kernel sets as default.
J.
--- On Sat, 11/7/09, Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> wrote:
From: Ralf Mardorf <ralf.mardorf(a)alice-dsl.net>
Subject: Re: [LAD] timers
To: "Paul Davis" <paul(a)linuxaudiosystems.com>om>, "Emanuel Rumpf"
<xbran(a)web.de>de>, "James Warden" <warjamy(a)yahoo.com>
Cc: linux-audio-dev(a)lists.linuxaudio.org
Date: Saturday, November 7, 2009, 4:40 PM
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
9:53 a.m.
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.
9:56 a.m.
yeps, forgot to copy this part of the config here, thanks :)
J.
--- On Sat, 11/7/09, Ray Rashif <schivmeister(a)gmail.com> wrote:
From: Ray Rashif <schivmeister(a)gmail.com>
Subject: Re: [LAD] timers
To: "Linux Audio Developers" <linux-audio-dev(a)lists.linuxaudio.org>
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(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
9 Nov
9 Nov
11:40 a.m.
New subject: Just an information for the coders of Rosegarden and Open Octave
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.
11:47 a.m.
New subject: Just an information for the coders of Rosegarden and Open Octave
On Mon, 09 Nov 2009 16:40:41 +0100
Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> wrote:
Emanuel Rumpf wrote:
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 ;)
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.
12:43 p.m.
New subject: Just an information for the coders of Rosegarden and Open Octave
On Mon, 9 Nov 2009 16:47:07 +0100
<hollunder(a)gmx.at> wrote:
On Mon, 09 Nov 2009 16:40:41 +0100
Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> wrote:
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?
Emanuel Rumpf wrote:
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 ;) 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.
8:27 p.m.
New subject: Timers, hpet, hrtimer
On Mon, 9 Nov 2009 17:43:12 +0100
<hollunder(a)gmx.at> wrote:
On Mon, 9 Nov 2009 16:47:07 +0100
<hollunder(a)gmx.at> wrote:
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
On Mon, 09 Nov 2009 16:40:41 +0100
Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> wrote:
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? Emanuel Rumpf wrote:
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 ;) 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.
10:29 p.m.
New subject: Timers, hpet, hrtimer
2009/11/10 <hollunder(a)gmx.at>
On Mon, 9 Nov 2009 17:43:12 +0100
<hollunder(a)gmx.at> wrote:
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.
On Mon, 9 Nov 2009 16:47:07 +0100
<hollunder(a)gmx.at> wrote:
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(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
On Mon, 09 Nov 2009 16:40:41 +0100
Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> wrote:
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? 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 ;) 
10 Nov
10 Nov
5:03 a.m.
New subject: Timers, hpet, hrtimer
hollunder(a)gmx.at wrote:
/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
<hollunder(a)gmx.at> 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. <--?
5:47 a.m.
New subject: Timers, hpet, hrtimer
On Tue, 10 Nov 2009 10:03:34 +0100
Clemens Ladisch <clemens(a)ladisch.de> wrote:
/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
hollunder(a)gmx.at wrote:
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.
<hollunder(a)gmx.at> 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. <--?
6:10 a.m.
New subject: Timers, hpet, hrtimer -> kind of solved (for too old motherboards)
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
7:48 a.m.
New subject: Timers, hpet, hrtimer -> kind of solved (for too old motherboards)
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.
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
9:40 a.m.
New subject: Timers, hpet, hrtimer -> kind of solved (for too old motherboards)
On Tue, 10 Nov 2009 12:48:42 +0100
Clemens Ladisch <clemens(a)ladisch.de> wrote:
Thanks a lot Clemens, but I'm still not sure what the issue is or how
to solve it.
Regards,
Philipp
hollunder(a)gmx.at wrote:
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
$ 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.
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
10:14 a.m.
New subject: Timers, hpet, hrtimer -> kind of solved (for too old motherboards)
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:
because it doesn't need
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 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
12 Nov
12 Nov
9:57 a.m.
New subject: Timers, hpet, hrtimer -> kind of solved (for too old motherboards)
Clemens Ladisch wrote:
"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.
I would like to make a test song using HR timer, but unfortunately I'm
not able to close a project and open it again, even after doing a reset.
Hem?
From a mail I wrote yesterday to another list:
"the good news is, that using HR timer will cause less jitter than the
usage of any other timer.
The bad news are
- Open Octave will freeze the system when selecting HR timer
- Qtractor is fine with HR timer, BUT only when I start a project. Once
I closed it and try to load it again (even after doing a reset) I get
this error:
"This system has no accessible HPET device (Device or resource busy)"" [1]
"2.6.31.5-rt18 x86_64 and run jackd -Rch -dalsa -dhw:0 -r96000 -p512 -n2
-Xseq. JACK is jackdmp 1.9.3. The self build kernel might be buggy." [1]
" ||HR tmr|System|PCM pl|PCM ca
------++------+------+------+------
500.0|| 504.9| 505.6| 503.4| 503.2
1000.0||1005.4|1005.8|1005.3|1006.4
1500.0||1503.6|1506.4|1507.4|1507.3
2000.0||2003.8|2007.2|2007.9|2009.5
2500.0||2504.1|2504.3|2503.6|2503.2
3000.0||3006.0|3006.2|3005.9|3007.6
3500.0||3502.7|3505.4|3506.5|3509.5
4000.0||4003.1|4003.2|4008.8|4009.9
msec +/- 0.1 msec
maxDif|| 6.0| 7.2| 8.8| 9.9
minDif|| -2.7| -3.2| -3.4| -3.2
--------------+------+------+------
Jitter|| 3.3| 4.0| 5.4| 6.7
msec +/- 0.2 msec" [1]
[1] http://lists.64studio.com/pipermail/64studio-users/2009-November/003885.html
10:06 a.m.
New subject: Timers, hpet, hrtimer -> kind of solved (for too old motherboards)
Ralf Mardorf wrote:
Clemens Ladisch wrote:
Oops :)
pardon I need to correct this.
"I used
Qtractor 0.4.3.1418. For all timers I used kernel
2.6.29-1-multimedia-amd64 x86_64 and run jackd -Rdalsa -dhw:0 -r96000
-p512 -n2 -Xseq, but for HR timer only I used" ...
"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.
I would like to make a test song using HR timer, but unfortunately I'm
not able to close a project and open it again, even after doing a reset.
Hem?
From a mail I wrote yesterday to another list:
"the good news is, that using HR timer will cause less jitter than the
usage of any other timer.
The bad news are
- Open Octave will freeze the system when selecting HR timer
- Qtractor is fine with HR timer, BUT only when I start a project. Once
I closed it and try to load it again (even after doing a reset) I get
this error:
"This system has no accessible HPET device (Device or resource busy)""
[1]
"2.6.31.5-rt18 x86_64 and run jackd -Rch -dalsa
-dhw:0 -r96000 -p512 -n2
-Xseq. JACK is jackdmp 1.9.3. The self build kernel might be buggy." [1]
" ||HR tmr|System|PCM pl|PCM ca
------++------+------+------+------
500.0|| 504.9| 505.6| 503.4| 503.2
1000.0||1005.4|1005.8|1005.3|1006.4
1500.0||1503.6|1506.4|1507.4|1507.3
2000.0||2003.8|2007.2|2007.9|2009.5
2500.0||2504.1|2504.3|2503.6|2503.2
3000.0||3006.0|3006.2|3005.9|3007.6
3500.0||3502.7|3505.4|3506.5|3509.5
4000.0||4003.1|4003.2|4008.8|4009.9
msec +/- 0.1 msec
maxDif|| 6.0| 7.2| 8.8| 9.9
minDif|| -2.7| -3.2| -3.4| -3.2
--------------+------+------+------
Jitter|| 3.3| 4.0| 5.4| 6.7
msec +/- 0.2 msec" [1]
[1] http://lists.64studio.com/pipermail/64studio-users/2009-November/003885.html
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)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.j…
"Gromit bit me" says HMV dog:
http://img.dailymail.co.uk/i/pix/2007/03_03/GomitHMVPA_468x319.jpg
10 Nov
10 Nov
1:53 p.m.
New subject: Timers, hpet, hrtimer
Since hrtimer uses hpet if available and apps use
hrtimer, why would I
need to allow some audio group to access hpet directly?
Because it offers memory-mappable access to the actual timer hardware,
significantly lowering overhead and latency for reading the value.
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.
This is typically because the device is busy - fully reserved already.
The reason for this is typically because the device driver in kernel is
broken. And still not fixed?
HPET timer has one global time counter, which is the one JACK is
interested in, and in addition three programmable sub-timers. The
problem is that mapping the HPET device also reserves one of these
sub-timers per mapping. Usually kernel is using one and two are left
free, this usually allows JACK daemon and one client to be started
before running out of those timers.
Brokenness is that JACK is not interested on those sub-timers and the
driver should allocate those only via corresponding ioctl() and give
unlimited read access to the global timer value without failing early...
Someone promised to fix the driver, but I haven't verified recently if
it has been fixed. If not, maybe I have to add that to my TODO-list...
BR,
- Jussi
2:10 p.m.
New subject: Timers, hpet, hrtimer
On Tue, Nov 10, 2009 at 07:53:19PM +0200, Jussi Laako wrote:
Brokenness is that JACK is not interested on those
sub-timers and the
driver should allocate those only via corresponding ioctl() and give
unlimited read access to the global timer value without failing early...
If hpet services are available via the kernel (I assume in the
form of fine-grained sleep, usleep, timetouts, etc.) why should
Jack (or any app) use the HW timer directly ?
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
2:16 p.m.
New subject: Timers, hpet, hrtimer
On Tue, Nov 10, 2009 at 1:06 PM, <fons(a)kokkinizita.net> wrote:
On Tue, Nov 10, 2009 at 07:53:19PM +0200, Jussi Laako
wrote:
because we don't want to have to make a system call to get a high res
timer value.
JACK was written with the assumption that doing this is essentially free.
Brokenness is that JACK is not interested on
those sub-timers and the
driver should allocate those only via corresponding ioctl() and give
unlimited read access to the global timer value without failing early...
If hpet services are available via the kernel (I assume in the
form of fine-grained sleep, usleep, timetouts, etc.) why should
Jack (or any app) use the HW timer directly ?
2:37 p.m.
New subject: Timers, hpet, hrtimer
On Tue, Nov 10, 2009 at 01:16:52PM -0500, Paul Davis wrote:
On Tue, Nov 10, 2009 at 1:06 PM,
<fons(a)kokkinizita.net> wrote:
So you're just reading it, not waiting on it ? That indeed
should be 'free'.
What I don't see is how e.g. MIDI generators can use it
in this way to get accurate event timing. Either they are
spinning (evil), or they'd need a system call anyway, and
it that case they should use kernel services instead.
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
On Tue, Nov 10, 2009 at 07:53:19PM +0200, Jussi
Laako wrote:
because we don't want to have to make a system call to get a high res
timer value.
JACK was written with the assumption that doing this is essentially free. Brokenness is that JACK is not interested on
those sub-timers and the
driver should allocate those only via corresponding ioctl() and give
unlimited read access to the global timer value without failing early...
If hpet services are available via the kernel (I assume in the
form of fine-grained sleep, usleep, timetouts, etc.) why should
Jack (or any app) use the HW timer directly ?
3:34 p.m.
New subject: Timers, hpet, hrtimer
fons(a)kokkinizita.net wrote:
So you're just reading it, not waiting on it ?
That indeed
should be 'free'.
Yes, we just need to read it. JACK used to use TSC for that, and HPET
support was introduced as similar low-cost alternative to deal with
variable clock frequencies (important on mobile things) and unsynced
TSC. Use of syscalls is kind of fallback.
Audio hardware (interrupts) act as a waitable time source.
5:01 p.m.
New subject: Timers, hpet, hrtimer
On Tue, Nov 10, 2009 at 09:34:28PM +0200, Jussi Laako wrote:
fons(a)kokkinizita.net wrote:
All perfectly logical. But what then is stopping the driver devs
from providing just read access to the main counter ? Who could
object to read-only access to a device register (if reading it
has no side effects) ?
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
So you're just reading it, not waiting on it
? That indeed
should be 'free'.
Yes, we just need to read it. JACK used to use TSC for that, and HPET
support was introduced as similar low-cost alternative to deal with
variable clock frequencies (important on mobile things) and unsynced
TSC. Use of syscalls is kind of fallback.
Audio hardware (interrupts) act as a waitable time source.
5:31 p.m.
New subject: Timers, hpet, hrtimer
On Tue, Nov 10, 2009 at 3:58 PM, <fons(a)kokkinizita.net> wrote:
All perfectly logical. But what then is stopping the
driver devs
from providing just read access to the main counter ? Who could
object to read-only access to a device register (if reading it
has no side effects) ?
probably nothing but time and will, if its like many other similar situations.
they probably don't think its very important. send in the jussi! :)
3:45 p.m.
New subject: Timers, hpet, hrtimer
On Tue, Nov 10, 2009 at 1:33 PM, <fons(a)kokkinizita.net> wrote:
What I don't see is how e.g. MIDI generators can
use it
in this way to get accurate event timing. Either they are
spinning (evil), or they'd need a system call anyway, and
it that case they should use kernel services instead.
you're confusing two different ways of interacting with the HPET.
as jussi described, the HPET consists of both a free-running timer,
and schedulable timers that cause interrupts. the comments earlier in
thread regarding MIDI scheduling rely on the second part of the HPET,
not the first, and yes, user space would interact with them via normal
system calls like usleep().
9 Nov
9 Nov
11:47 a.m.
New subject: Just an information for the coders of Rosegarden and Open Octave
On Mon, Nov 9, 2009 at 3:40 PM, Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> wrote:
Emanuel Rumpf wrote:
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
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.
5447
days inactive
5452
days old
linux-audio-dev@lists.linuxaudio.org
44 comments
11 participants
participants (11)
-
adi＠drcomp.erfurt.thur.de -
Chris Cannam -
Clemens Ladisch -
Emanuel Rumpf -
fons＠kokkinizita.net -
hollunder＠gmx.at -
James Warden -
Jussi Laako -
Paul Davis -
Ralf Mardorf -
Ray Rashif