27 May
2010
27 May
'10
11:12 p.m.
I have hrtimer support compiled into my kernel, but when I watch 'top'
while music is playing I can see that 'timer' uses CPU cycles but
'hrtimer' never does. How can I find out if ALSA is using hrtimer?
- Grant
28 May
28 May
8:16 a.m.
Grant wrote:
I have hrtimer support compiled into my kernel, but
when I watch 'top'
while music is playing I can see that 'timer' uses CPU cycles but
'hrtimer' never does. How can I find out if ALSA is using hrtimer?
ALSA uses the sound card interrupt for timing. The hrtimer is used only
for MIDI playback and for sound cards without interrupts, such as the
SuperH, i.MX, PC Speaker, and dummy devices.
Regards,
Clemens
30 May
30 May
8:02 p.m.
I have hrtimer
support compiled into my kernel, but when I watch 'top'
while music is playing I can see that 'timer' uses CPU cycles but
'hrtimer' never does. How can I find out if ALSA is using hrtimer?
ALSA uses the sound card interrupt for timing. The hrtimer is used only
for MIDI playback and for sound cards without interrupts, such as the
SuperH, i.MX, PC Speaker, and dummy devices. 
10:39 p.m.
On Sun, May 30, 2010 at 11:02 AM, Grant <emailgrant(a)gmail.com> wrote:
I too would like to better understand these statements and the
benefits, if any, provided by loading snd-hrtimer. For example, if
snd-pcm wasn't dependent on snd_timer, why this dependency from
lsmod?::
Then what is the purpose of the --clocksource flag, and what are the
advantages/disadvantages of the different settings:
"c(ycle) | h(pet) | s(ystem)"??
In a different thread you mention, regarding jackd's use of snd-seq:
ALSA uses the
sound card interrupt for timing. The hrtimer is used only
for MIDI playback and for sound cards without interrupts, such as the
SuperH, i.MX, PC Speaker, and dummy devices.
Are you sure? CONFIG_SND_HRTIMER says:
"ALSA uses the hrtimer as a precise timing source. The ALSA sequencer
code also can use this timing source."
Would ALSA use the sound card interrupt for timing with my USB DAC? snd_timer 19840 5
snd_seq,snd_hrtimer,snd_pcm
What kinds of timing info is snd_pcm deriving from snd_timer?? What
are the benefits of using HRtimer versus system timer with ALSA?
Which results in best performance (latency and drummer-accurate MIDI
timing).
Which uses least system resources?
On Fri, May 28, 2010 at 12:11 PM, Paul Davis <paul(a)linuxaudiosystems.com> wrote:
Does setting
"--clocksource" only affect MIDI, or also Audio?
(
http://old.nabble.com/Re:-Quality-of-sound-on-RHEL-6.0-beta-and-Fedora-13-p… )
neither. the timing behaviour of the two -X options (seq and
raw) are not very good. some might be sufficiently uncharitable as to call them
unusable".
Would using snd-hrtimer with snd-seq change this assessment? I haven't
done any precise measurements myself, but I didn't hear anything sound
terribly "off" w/r/t my usage of ALSA midi through qjackctl/jackd (
"/usr/bin/jackd -dalsa -dhw:M66 -r44100 -p256 -n2 -Xseq -zs -H -M").
Certainly not "unusable" just using MIDI alone.
Is this issue related to timing of MIDI versus audio, or MIDI timing
itself causing the music to sound different than the musician
intended?
Thanks for all the helpful advice,
Niels
http://nielsmayer.com
PS: To get snd-hrtimer at boot in Fedora:
http://old.nabble.com/-etc-modprobe.d-dist-alsa.conf-patch-to-boot-with-hig…
31 May
31 May
2:08 a.m.
> "ALSA uses the hrtimer as a precise timing
source. The ALSA sequencer
> code also can use this timing source."
BTW, now that I've enabled hr timer, I notice that qtractor 's
View->Options->MIDI->Playback has an entry for
"Queue timer (resolution):
[ (default), system timer (1000 Hz), HR timer (1000000000 hz), PCM
Playback 0-0-0. (slave), PCM Playback 0-0-1 (slave), ... ]"
What happens if I use "HR timer" instead of "(default)" or a
specific
PCM slave, when recording/playing back audio clips ?
Does "PCM playback (slave)" mean the audio sample-clock is sync'd to
the midi clock, or vice-versa? And if snd-hrtimer is available,
wouldn't both audio and midi be using the same clock? (per Grant's
comment ''CONFIG_SND_HRTIMER says: "ALSA uses the hrtimer as a precise
timing source. The ALSA sequencer code also can use this timing
source."'' )
W/r/t qtractor, does (default) "do the right thing" or should I be
choosing a specific option based on use?
I guess I'll find out...
Niels
http://nielsmayer.com
3:19 p.m.
On Sun, May 30, 2010 at 4:39 PM, Niels Mayer <nielsmayer(a)gmail.com> wrote:
On Fri, May 28, 2010 at 12:11 PM, Paul Davis <paul(a)linuxaudiosystems.com>
wrote:
JACK makes quite a few calls to get a wallclock time value. Its original
implementation always used the cycle counter to minimize the overhead of
getting this value, since gettimeofday() is technically a system call and
its better to avoid such things in most of the places that JACK needs to
know the wallclock time. However, as has been mentioned, it turns out that
using the cycle counter on many machines is deeply problematic, and so by
default JACK uses gettimeofday(). The HR timer offers similar properties as
the cycle counter in the sense that no system call is required to read it.
The choice between these 3 options has nothing really to do with "timing" at
all (although on a machine with a weak cycle counter implementation, using
the cycle counter will cause "timing problems").
> Does setting "--clocksource" only
affect MIDI, or also Audio?
> (
http://old.nabble.com/Re:-Quality-of-sound-on-RHEL-6.0-beta-and-Fedora-13-p…)
neither.
Then what is the purpose of the --clocksource flag, and what are the
advantages/disadvantages of the different settings:
"c(ycle) | h(pet) | s(ystem)"??
In a different thread you mention, regarding
jackd's use of snd-seq:
No, they are just badly designed and implemented from this perspective. They
both have substantial jitter built into their design.
I haven't
the timing behaviour of the two -X options (seq
and raw) are not very
good. some might be sufficiently uncharitable as to call them
unusable".
Would using snd-hrtimer with snd-seq change this assessment? done any precise measurements myself, but I didn't
hear anything sound
terribly "off" w/r/t my usage of ALSA midi through qjackctl/jackd (
"/usr/bin/jackd -dalsa -dhw:M66 -r44100 -p256 -n2 -Xseq -zs -H -M").
Certainly not "unusable" just using MIDI alone.
The issue is not using ALSA MIDI. Its routing from JACK to ALSA MIDI. If
this is not designed and implemented correctly, it can end up with large
amounts of jitter (variable delays in how long it takes to actually deliver
MIDI data to its destination). a2jmidid (at least relatively recent
versions) is correctly designed and implemented in this respect.
--p
8:56 p.m.
Many thanks for the explanations. Of course, now I have even more questions :-)
The issue is not using ALSA MIDI. Its routing from
JACK to ALSA MIDI. If this is not designed and
implemented correctly, it can end up with
large amounts of jitter (variable delays in how long
it takes to actually deliver MIDI data to its destination).
a2jmidid (at least relatively recent > versions) is
correctly designed and implemented in this respect.
Seeking clarification: does this mean the jitter issues affect only
using Jack MIDI ? If I'm just using qjackctl to patch between
different ALSA midi sources, and am not using jack midi at all, then I
won't suffer from the aforementioned jitter issues?
My typical use cases involve patching (via qjackctl) ALSA midi to ALSA
midi such as:
* external midi keyboard --> sequencer (e.g. qtractor or rosegarden)
* sequencer --> external midi synth/sampler
* sequencer or external midi keyboard --> ALSA synth (e.g. yoshimi or qsynth)
In the future, I want to try getting my external MIDI gear to generate
midi clock and attempt to sync jack midi and transport to my external
gear. Is this where I'll run into problems, as I will need to bridge
ALSA midi to Jack midi in order to access the jack transport? What's
the most reliable way of slaving Jackd to an external MIDI clock? (as
opposed to using http://www.teuton.org/~gabriel/jack_midi_clock/
to slave external devices to jack's midi clock).
What are the advantages of using Jack Midi over ALSA midi? Perhaps due
to its newness, I only have one synth that uses jack-midi::
http://ll-plugins.nongnu.org/azr3/ -- Is Jack Midi and a2jmidid the
direction we should be moving towards in the future, and currently
isn't well represented by tools and software because it's newer than
ALSA?
Thanks!
-- Niels.
PS: what happens with ALSA and Jack timing when running a "tickless
kernel": http://kerneltrap.org/node/6750
"This feature is implemented by driving 'low
res timer wheel' processing via
special per-CPU high-res timers, which timers are
reprogrammed to the next-low-res-timer-expires interval.
This tickless-kernel design is SMP-safe in a natural way and has been
developed on SMP systems from the beginning.
5 Jun
5 Jun
9:10 p.m.
On Mon, May 31, 2010 at 09:19:06AM -0400, Paul Davis wrote:
On Sun, May 30, 2010 at 4:39 PM, Niels Mayer
<nielsmayer(a)gmail.com> wrote:
Really? It's probably been a couple years since I used a2jmidid, but I recall it
having horrible jitter and latency (when using AZR3, which I used to use a lot) compared
to the -Xseq option in jackd.
-ken
On Fri, May 28, 2010 at 12:11 PM, Paul Davis <paul(a)linuxaudiosystems.com>
wrote:
JACK makes quite a few calls to get a wallclock time value. Its original
implementation always used the cycle counter to minimize the overhead of
getting this value, since gettimeofday() is technically a system call and
its better to avoid such things in most of the places that JACK needs to
know the wallclock time. However, as has been mentioned, it turns out that
using the cycle counter on many machines is deeply problematic, and so by
default JACK uses gettimeofday(). The HR timer offers similar properties as
the cycle counter in the sense that no system call is required to read it.
The choice between these 3 options has nothing really to do with "timing" at
all (although on a machine with a weak cycle counter implementation, using
the cycle counter will cause "timing problems").
> Does setting "--clocksource" only
affect MIDI, or also Audio?
> (
http://old.nabble.com/Re:-Quality-of-sound-on-RHEL-6.0-beta-and-Fedora-13-p…)
neither.
Then what is the purpose of the --clocksource flag, and what are the
advantages/disadvantages of the different settings:
"c(ycle) | h(pet) | s(ystem)"??
In a different thread you mention, regarding
jackd's use of snd-seq:
No, they are just badly designed and implemented from this perspective. They
both have substantial jitter built into their design.
I haven't
the timing behaviour of the two -X options (seq
and raw) are not very
good. some might be sufficiently uncharitable as to call them
unusable".
Would using snd-hrtimer with snd-seq change this assessment? done any precise measurements myself, but I
didn't hear anything sound
terribly "off" w/r/t my usage of ALSA midi through qjackctl/jackd (
"/usr/bin/jackd -dalsa -dhw:M66 -r44100 -p256 -n2 -Xseq -zs -H -M").
Certainly not "unusable" just using MIDI alone.
The issue is not using ALSA MIDI. Its routing from JACK to ALSA MIDI. If
this is not designed and implemented correctly, it can end up with large
amounts of jitter (variable delays in how long it takes to actually deliver
MIDI data to its destination). a2jmidid (at least relatively recent
versions) is correctly designed and implemented in this respect.
11:19 p.m.
On Sat, Jun 5, 2010 at 2:07 PM, Ken Restivo <ken(a)restivo.org> wrote:
"at least relatively recent versions"
i rewrote the core of a2jmidid sometime earlier this year (or possibly
toward the end of last year). ironically, both of the 1-way clients
(a2j and j2a) were correctly designed and implemented, but a2jmidid
had been written in a different style. no more.
The issue is
not using ALSA MIDI. Its routing from JACK to ALSA MIDI. If
this is not designed and implemented correctly, it can end up with large
amounts of jitter (variable delays in how long it takes to actually deliver
MIDI data to its destination). a2jmidid (at least relatively recent
versions) is correctly designed and implemented in this respect.
Really? It's probably been a couple years since I used a2jmidid, but I recall it
having horrible jitter and latency (when using AZR3, which I used to use a lot) compared
to the -Xseq option in jackd.
-ken
28 May
28 May
4:07 p.m.
On Thursday, May 27, 2010, Grant wrote:
I have hrtimer support compiled into my kernel, but
when I watch 'top'
while music is playing I can see that 'timer' uses CPU cycles but
'hrtimer' never does. How can I find out if ALSA is using hrtimer?
- Grant
In addition to Clemens' message, ALSA MIDI sequencer can use several timer
sources. To see which ALSA timers are available, use a command like this:
$ cat /proc/asound/timers
When a program is using the ALSA MIDI sequencer, you can query the timers
assigned to each queue using another command:
$ cat /proc/asound/seq/timer
Alternatively, the utility "drumstick-sysinfo" [1] shows this information
using a friendly format.
Regards,
Pedro
[1] http://sf.net/projects/drumstick
8:13 p.m.
Pedro Lopez-Cabanillas <pedro.lopez.cabanillas(a)gmail.com>om>:
Alternatively, the utility
"drumstick-sysinfo" [1] shows this information
using a friendly format.
Thanks for the very helpful info!
( Just remember to turn off jackd before running:
https://bugzilla.redhat.com/show_bug.cgi?id=597354 )
When running Jackd, is the correct way to ensure your MIDI is getting
the highest accuracy to use the --clocksource flag set to HPET?
-c, --clocksource ( c(ycle) | h(pet) | s(ystem) )
Select a specific wall clock (Cycle Counter, HPET timer, System timer).
Does setting "--clocksource" only affect MIDI, or also Audio?
(
http://old.nabble.com/Re:-Quality-of-sound-on-RHEL-6.0-beta-and-Fedora-13-p…
)
Niels
http://nielsmayer.com
9:11 p.m.
On Fri, May 28, 2010 at 2:13 PM, Niels Mayer <nielsmayer(a)gmail.com> wrote:
Does setting "--clocksource" only affect MIDI, or also Audio?
(
http://old.nabble.com/Re:-Quality-of-sound-on-RHEL-6.0-beta-and-Fedora-13-p…
)
neither.
11:12 p.m.
I added your suggestion to
https://bugzilla.redhat.com/show_bug.cgi?id=597354#c5 which resolves
the coredump in drumstick-sysinfo
///////// ///////// ///////// /////////
Upstream author Pedro Lopez-Cabanillas suggested doing
'sudo modprobe snd-hrtimer'
prior to running Jackd.
Now drumstick-sysinfo doesn't crash. Furthermore, it looks like ALSA is using
the HRTimer:
gnulem-15-~/Documents> cat /proc/asound/seq/timer
Timer for queue 0 : HR timer
Period time : 0.001000000
Skew : 65536 / 65536
gnulem-16-~/Documents> cat /proc/asound/timers
G0: system timer : 1000.000us (10000000 ticks)
G3: HR timer : 0.001us (1000000000 ticks)
Client sequencer queue 0 : running
P0-0-0: PCM playback 0-0-0 : SLAVE
P0-0-1: PCM capture 0-0-1 : SLAVE
P1-0-0: PCM playback 1-0-0 : SLAVE
P1-0-1: PCM capture 1-0-1 : SLAVE
P1-0-2: PCM playback 1-0-2 : SLAVE
P1-0-3: PCM capture 1-0-3 : SLAVE
P1-1-0: PCM playback 1-1-0 : SLAVE
P2-0-0: PCM playback 2-0-0 : SLAVE
P2-0-1: PCM capture 2-0-1 : SLAVE
P4-0-0: PCM playback 4-0-0 : SLAVE
Client application 2396 : stopped
Client application 9950 : stopped
P4-0-1: PCM capture 4-0-1 : SLAVE
///////// ///////// ///////// /////////
Niels
http://nielsmayer.com
29 May
29 May
12:03 a.m.
Hi,
On Friday, May 28, 2010, Niels Mayer wrote:
I added your suggestion to
https://bugzilla.redhat.com/show_bug.cgi?id=597354#c5 which resolves
the coredump in drumstick-sysinfo
///////// ///////// ///////// /////////
Upstream author Pedro Lopez-Cabanillas suggested doing
'sudo modprobe snd-hrtimer'
prior to running Jackd.
Now drumstick-sysinfo doesn't crash. Furthermore, it looks like ALSA is
using the HRTimer:
The proper fix for the crash in drumstick-sysinfo will be included in the
upcoming Drumstick-0.3.2, when published. The fix shall only avoid the abort
signal and the crash, showing to the user a less alarming error message
instead.
The root cause is the ALSA module snd-hrtimer not loaded, when the hardware
providing the HPET timer is available, and it is used by Jack. Loading the
ALSA module fixes the crash and allows the ALSA sequencer applications to
access this high precission timer.
In my opinion, if you run some ALSA sequencer applications with a modern
Linux/ALSA and your motherboard provides the HPET, the module snd-hrtimer
should be loaded. It is the alternative to the RTC timer present in older
machines.
Regards,
Pedro
5085
days inactive
5094
days old
linux-audio-user@lists.linuxaudio.org
14 comments
6 participants
participants (6)
-
Clemens Ladisch -
Grant -
Ken Restivo -
Niels Mayer -
Paul Davis -
Pedro Lopez-Cabanillas