2 May
2007
2 May
'07
7:06 p.m.
hello everyone
One thing that draws my attention is MIDI playing. So far, by using
Timidity and ALSA, I tried to play several MIDI files and it is hard for
me to notice any lag. I only noticed delayed notes when system is under
busy load (I run CPU bound program with nice level above -9).
Things I'd like to discuss are (I am sorry if they sound dumps
because I still study all these stuffs):
1. Is it me just who is not professional enough to notice any difference
when using various kernel HZ setting (smooth playing on HZ=x, not so smooth
when HZ=y and so on)? Or, does the delay fall in non-human-perceptible
range thus normal human being can not see the difference?
2. Is it correct that recent ALSA sequencer use RTC as source timer thus
kernel HZ is no longer relevant in the sequencer's point of view?
3. Related to the system load I mentioned above, I think I was seeing
scheduling latency and not really a timing latency. If that's correct,
could you kindly suggest what I must do to show that MIDI timing does
have any relation with HZ?
4. I am also thinking about MIDI recording as a way to show HZ effect.
Since I don't have any MIDI devices (but I plan to buy one if it's
really neccessary), I'd like to explore the correctness of this idea
first. Do you think it is really a proper experiment in HZ test context?
Thank you in advance for your help and attention and I am looking
forward to read your feedback. Sorry if it has been discussed before,
but I fail to completely research it until today.
regards,
Mulyadi
2 May
2 May
9:40 p.m.
Mulyadi Santosa schrieb:
hello everyone
One thing that draws my attention is MIDI playing. So far, by using
Timidity and ALSA, I tried to play several MIDI files and it is hard for
me to notice any lag. I only noticed delayed notes when system is under
busy load (I run CPU bound program with nice level above -9).
Things I'd like to discuss are (I am sorry if they sound dumps
because I still study all these stuffs):
1. Is it me just who is not professional enough to notice any difference
when using various kernel HZ setting (smooth playing on HZ=x, not so smooth
when HZ=y and so on)? Or, does the delay fall in non-human-perceptible
range thus normal human being can not see the difference?
2. Is it correct that recent ALSA sequencer use RTC as source timer thus
kernel HZ is no longer relevant in the sequencer's point of view?
3. Related to the system load I mentioned above, I think I was seeing
scheduling latency and not really a timing latency. If that's correct,
could you kindly suggest what I must do to show that MIDI timing does
have any relation with HZ?
4. I am also thinking about MIDI recording as a way to show HZ effect.
Since I don't have any MIDI devices (but I plan to buy one if it's
really neccessary), I'd like to explore the correctness of this idea
first. Do you think it is really a proper experiment in HZ test context?
Thank you in advance for your help and attention and I am looking
forward to read your feedback. Sorry if it has been discussed before,
but I fail to completely research it until today.
regards,
Mulyadi
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev
Hi
I have
dev.rtc.max-user-freq = 8192
in my sysctl.conf.
Before seq24 timing seemed to be changing between laid back and forward.
Haven't tested since setting.
Do
cat /proc/sys/dev/rtc/max-user-freq
to see your setting now.
echo 8192 > /proc/sys/dev/rtc/max-user-freq
changes setting.
Uli
4 May
4 May
4:37 a.m.
Hi
Sorry for late reply..
I have
dev.rtc.max-user-freq = 8192
in my sysctl.conf.
Before seq24 timing seemed to be changing between laid back and forward.
Haven't tested since setting.
Do
cat /proc/sys/dev/rtc/max-user-freq
to see your setting now.
echo 8192 > /proc/sys/dev/rtc/max-user-freq
changes setting.
Thank you, even this small hint gave me a valuable direction. It makes
me believe there are many applications that do rely on non-kernel-timer
source.. in this case RTC.
May I ask, could seq24 reports somekind of note playing delay? or xruns?
regards,
Mulyadi
8:18 a.m.
On Friday 04 May 2007, Mulyadi Santosa wrote:
Hi
Sorry for late reply..
seq24 does _not_ use RTC for timing. It uses an approach based on sleep() (in
some way or the other), so setting the rtc-max-frequency does nothing for
seq24 performance. To improve seq24 performance over the vanilla kernel you
need a kernel with the system timer frequency set back to something like
1000Hz (vanilla has 200Hz, which is too unprecise for MIDI timing based on
sleeping short amounts of time)..
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
I have
dev.rtc.max-user-freq = 8192
in my sysctl.conf.
Before seq24 timing seemed to be changing between laid back and forward.
Haven't tested since setting.
Do
cat /proc/sys/dev/rtc/max-user-freq
to see your setting now.
echo 8192 > /proc/sys/dev/rtc/max-user-freq
changes setting.
Thank you, even this small hint gave me a valuable direction. It makes
me believe there are many applications that do rely on non-kernel-timer
source.. in this case RTC.
May I ask, could seq24 reports somekind of note playing delay? or xruns? 
5 May
5 May
7:33 a.m.
Le Fri, 4 May 2007 12:18:25 +0200,
Florian Schmidt <mista.tapas(a)gmx.net> a écrit :
On Friday 04 May 2007, Mulyadi Santosa wrote:
I get recently in troubles with my rt kernel. On
http://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO, they write at "Since rt
patch 2.6.18-rt6 you will probably have to activate ACPI option to activate
high resolution timer. Since the TSC timer on PC platforms, as used in the
previous versions, are now marked as unsuitable for hrt mode due to many lacks
of functionalities and reliabilties, you will need i.E. pm_timer as provided by
ACPI to use as clock source."
When doing this, my box just hang from time to time. The problem I have is
double.
1) My box just hang when it hang and I don't get this problem with a vanilla,
desktop preemption and the same ACPI setting. With the same rt kernel but
without ACPI support, it doesn't hang. Older rt kernel as 2.6.18-rt6 are also
hanging when ACPI is enabled, so it is in fact an old kernel issue between ACPI
and my motherboard. The problem is I don't know how to reproduce it and get some
debug information. I even done a kernel bug report, but without other
possibility as to wait some time (from a few hours to a few days) in order to
reproduce it, and without any useful error messages, I doubt at this issue will
never been resolved.
2) More relevant to this list: I am not sure if I understand well this matter.
They write "i.E pm_timer". Is it an alternative way to get the same
functionality but without ACPI?
Ciao,
Dominique
Hi
Sorry for late reply..
seq24 does _not_ use RTC for timing. It uses an approach based on sleep() (in
some way or the other), so setting the rtc-max-frequency does nothing for
seq24 performance. To improve seq24 performance over the vanilla kernel you
need a kernel with the system timer frequency set back to something like
1000Hz (vanilla has 200Hz, which is too unprecise for MIDI timing based on
sleeping short amounts of time)..
Flo
I have
dev.rtc.max-user-freq = 8192
in my sysctl.conf.
Before seq24 timing seemed to be changing between laid back and forward.
Haven't tested since setting.
Do
cat /proc/sys/dev/rtc/max-user-freq
to see your setting now.
echo 8192 > /proc/sys/dev/rtc/max-user-freq
changes setting.
Thank you, even this small hint gave me a valuable direction. It makes
me believe there are many applications that do rely on non-kernel-timer
source.. in this case RTC.
May I ask, could seq24 reports somekind of note playing delay? or xruns?
7:55 a.m.
Hi Florian....
seq24 does _not_ use RTC for timing. It uses an
approach based on sleep() (in
some way or the other), so setting the rtc-max-frequency does nothing for
seq24 performance.
Seems correct. I tried to grab latest seq24 and compiled it. While
testing to find out how it works, I grep-ed the source code and none
indicate it has something to do with RTC programming. However, I will
keep looking and studying the code.
FYI, I tested seq24 using this simple setup:
seq24--> ALSA port --> timidity (as ALSA sequencer client)
To improve seq24 performance over the vanilla kernel
you
need a kernel with the system timer frequency set back to something like
1000Hz (vanilla has 200Hz, which is too unprecise for MIDI timing based on
sleeping short amounts of time)..
That's what I got too. A loop (?) take data array and using *sleep(), it
waits until the right time to deliver the midi messages to related
driver (in this case ALSA).
I found an interesting parameter, that is --stats. Seems like it counts
how long it takes to work on a single MIDI message. Anybody knows more
about this parameter?
NB: Once again, thank you Florian..
regards,
Mulyadi
6446
days inactive
6449
days old
linux-audio-dev@lists.linuxaudio.org
5 comments
4 participants
participants (4)
-
audio-mobster -
Dominique Michel -
Florian Schmidt -
Mulyadi Santosa