Re: [alsa-devel] MIDI playback not keeping steady time with recent kernels
Arthur Marsh wrote:
Arthur Marsh wrote, on 05/02/11 17:30:
MIDI playback either through xmms or aplaymidi won't keep regular time, sounding weird going faster and slower under any kind of system load except when nothing else is running.
I've tried setting "options snd-timer timer_limit=x" where x is anywhere from 5 down to 0, and seeing either:
$ cat /proc/asound/seq/timer Timer for queue 0 : HR timer Period time : 0.004000250 Skew : 65536 / 65536
or "system timer" in place of "HR timer".
In all cases, under sufficient load (which might be just running aptitude -u), the tempo of the MIDI file play-back slows right down.
The ALSA interfaces of both the system timer and the HR timer do not handle delayed interrupts correctly. Please try the patch below, and if it fixes the HR timer, tell me if you're OK with the published tag Reported-and-tested-by: Arthur Marsh arthur.marsh@internode.on.net.
Regards, Clemens
--- a/sound/core/hrtimer.c +++ b/sound/core/hrtimer.c @@ -45,12 +45,13 @@ static enum hrtimer_restart snd_hrtimer_ { struct snd_hrtimer *stime = container_of(hrt, struct snd_hrtimer, hrt); struct snd_timer *t = stime->timer; + unsigned long oruns;
if (!atomic_read(&stime->running)) return HRTIMER_NORESTART;
- hrtimer_forward_now(hrt, ns_to_ktime(t->sticks * resolution)); - snd_timer_interrupt(stime->timer, t->sticks); + oruns = hrtimer_forward_now(hrt, ns_to_ktime(t->sticks * resolution)); + snd_timer_interrupt(stime->timer, t->sticks * oruns);
if (!atomic_read(&stime->running)) return HRTIMER_NORESTART;
Clemens Ladisch wrote, on 08/02/11 22:23:
Arthur Marsh wrote:
Arthur Marsh wrote, on 05/02/11 17:30:
MIDI playback either through xmms or aplaymidi won't keep regular time, sounding weird going faster and slower under any kind of system load except when nothing else is running.
I've tried setting "options snd-timer timer_limit=x" where x is anywhere from 5 down to 0, and seeing either:
$ cat /proc/asound/seq/timer Timer for queue 0 : HR timer Period time : 0.004000250 Skew : 65536 / 65536
or "system timer" in place of "HR timer".
In all cases, under sufficient load (which might be just running aptitude -u), the tempo of the MIDI file play-back slows right down.
The ALSA interfaces of both the system timer and the HR timer do not handle delayed interrupts correctly. Please try the patch below, and if it fixes the HR timer, tell me if you're OK with the published tag Reported-and-tested-by: Arthur Marsharthur.marsh@internode.on.net.
Regards, Clemens
--- a/sound/core/hrtimer.c +++ b/sound/core/hrtimer.c @@ -45,12 +45,13 @@ static enum hrtimer_restart snd_hrtimer_ { struct snd_hrtimer *stime = container_of(hrt, struct snd_hrtimer, hrt); struct snd_timer *t = stime->timer;
unsigned long oruns;
if (!atomic_read(&stime->running)) return HRTIMER_NORESTART;
- hrtimer_forward_now(hrt, ns_to_ktime(t->sticks * resolution));
- snd_timer_interrupt(stime->timer, t->sticks);
oruns = hrtimer_forward_now(hrt, ns_to_ktime(t->sticks * resolution));
snd_timer_interrupt(stime->timer, t->sticks * oruns);
if (!atomic_read(&stime->running)) return HRTIMER_NORESTART;
OK, I applied this patch.
When the MIDI file was playing:
$ cat /proc/asound/seq/timer Timer for queue 0 : HR timer Period time : 0.004000250 Skew : 65536 / 65536
I still experienced some slow-down and speed-up under heavy load.
Thanks for the patch. I'm happy to do any further testing you can suggest.
Regards,
Arthur.
Arthur Marsh wrote:
OK, I applied this patch.
When the MIDI file was playing: I still experienced some slow-down and speed-up under heavy load.
Is "some" less than previously?
It shouldn't be possible to get a speed-up; this looks as if your computer's clock is not stable. Are you using an NTP daemon?
What kind of heave load is this? Does the same happen if you execute "yes | tail" in a shell?
Regards, Clemens
Clemens Ladisch wrote, on 09/02/11 02:10:
Arthur Marsh wrote:
OK, I applied this patch.
When the MIDI file was playing: I still experienced some slow-down and speed-up under heavy load.
Is "some" less than previously?
The amount of slow-down appears to be less than previously.
It shouldn't be possible to get a speed-up; this looks as if your computer's clock is not stable. Are you using an NTP daemon?
To clarify, the speed-up is back to original tempo, and yes I'm using an NTP daemon. There has been an issue of the pc not keeping accurate time under GNU/Linux even with ntpd running and using an NTP server a few hops away.
What kind of heave load is this? Does the same happen if you execute "yes | tail" in a shell?
The load when I experienced this problem was about 4 or 5, and mainly seemed to be tied to activities that caused swapping (e.g. running aptitude -u when other applications were using all available memory and some swap).
After quitting some applications so that there was no swapping going on (kswapd0 showing 0.0 cpu), the MIDI file played fine, even with "yes|tail" running.
Adding aptitude -u to the mix, which resulted in kswapd0 running at 4 to 10 percent cpu, caused a slow-down.
Regards, Clemens
Thanks again,
Arthur.
participants (2)
-
Arthur Marsh -
Clemens Ladisch