Re: alsa timer slippage

Re: alsa timer slippage

[Jan Depner]

If I'm not mistaken the timing for your audio is coming from your sound
card not your system clock.  The gettimeofday is from the system clock. 
They probably won't match.  Of course, I could be totally in the dark
;-)

Jan


On Sun, 2003-12-14 at 08:07, Chris Cannam wrote:
> 
> While trying to track down the source of some poor timing in 
> sequencing, I've noticed that my ALSA sequencer queue timer has a 
> tendency to fall suddenly behind.
> 
> I have a little test program (available on request) that just starts a 
> queue and every second or so compares the queue timer against real 
> time as returned by gettimeofday().  It doesn't mind if the two don't 
> quite match, but it does complain if the difference between the two 
> timers changes dramatically between two sample points.  When I run 
> it, it never lasts for more than about a minute before the ALSA queue 
> timer suddenly slips by anything from 10 to 60 milliseconds.
> 
> This is a non-low-latency kernel so I'm not surprised that there may 
> be some occasional timing issues, but 60ms is a lot on an unloaded 
> machine, and I am vaguely surprised that the timer doesn't notice 
> it's fallen behind and recover -- instead all events on the queue 
> continue to be delivered late forever.  This obviously makes for some 
> disconcerting audible effects.
> 
> The system is SuSE 9.0 on a dual 2GHz Athlon using SuSE's stock SMP 
> kernel.  I have tried both ALSA 0.9.6 (from SuSE) and 1.0.0rc2 
> drivers and libraries.  I haven't managed to reproduce it using a 
> PlanetCCRMA SMP kernel on the same machine, nor on my uniprocessor 
> laptop.  I've surveyed a few other people on rosegarden-devel and 
> nobody's corroborated my findings, so I guess it might be related to 
> using a dual-processor machine.
> 
> Any thoughts on this, anyone?  I'm finding it a little depressing that 
> I can't play even a minute of 4/4 beats from an ALSA test program 
> without the timing slipping audibly at least once.  I'm ready to 
> delve cluelessly into the timer code to take a look, but (glancing at 
> alsa-kernel/core/timer.c) I'm not at all sure how far I'd get...
> 
> 
> Chris
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/alsa-devel




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

alsa timer slippage

[Chris Cannam]

While trying to track down the source of some poor timing in 
sequencing, I've noticed that my ALSA sequencer queue timer has a 
tendency to fall suddenly behind.

I have a little test program (available on request) that just starts a 
queue and every second or so compares the queue timer against real 
time as returned by gettimeofday().  It doesn't mind if the two don't 
quite match, but it does complain if the difference between the two 
timers changes dramatically between two sample points.  When I run 
it, it never lasts for more than about a minute before the ALSA queue 
timer suddenly slips by anything from 10 to 60 milliseconds.

This is a non-low-latency kernel so I'm not surprised that there may 
be some occasional timing issues, but 60ms is a lot on an unloaded 
machine, and I am vaguely surprised that the timer doesn't notice 
it's fallen behind and recover -- instead all events on the queue 
continue to be delivered late forever.  This obviously makes for some 
disconcerting audible effects.

The system is SuSE 9.0 on a dual 2GHz Athlon using SuSE's stock SMP 
kernel.  I have tried both ALSA 0.9.6 (from SuSE) and 1.0.0rc2 
drivers and libraries.  I haven't managed to reproduce it using a 
PlanetCCRMA SMP kernel on the same machine, nor on my uniprocessor 
laptop.  I've surveyed a few other people on rosegarden-devel and 
nobody's corroborated my findings, so I guess it might be related to 
using a dual-processor machine.

Any thoughts on this, anyone?  I'm finding it a little depressing that 
I can't play even a minute of 4/4 beats from an ALSA test program 
without the timing slipping audibly at least once.  I'm ready to 
delve cluelessly into the timer code to take a look, but (glancing at 
alsa-kernel/core/timer.c) I'm not at all sure how far I'd get...


Chris



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

Re: alsa timer slippage

[Måns Rullgård]

Jan Depner <eviltwin69@cableone.net> writes:

> On Sun, 2003-12-14 at 08:07, Chris Cannam wrote:
>> 
>> While trying to track down the source of some poor timing in 
>> sequencing, I've noticed that my ALSA sequencer queue timer has a 
>> tendency to fall suddenly behind.
>> 
>> I have a little test program (available on request) that just starts a 
>> queue and every second or so compares the queue timer against real 
>> time as returned by gettimeofday().  It doesn't mind if the two don't 
>> quite match, but it does complain if the difference between the two 
>> timers changes dramatically between two sample points.  When I run 
>> it, it never lasts for more than about a minute before the ALSA queue 
>> timer suddenly slips by anything from 10 to 60 milliseconds.
>
> If I'm not mistaken the timing for your audio is coming from your sound
> card not your system clock.  The gettimeofday is from the system clock. 
> They probably won't match.

That's true.  However, you typically see a gradual drift, not a sudden
jump.

-- 
Måns Rullgård
mru@kth.se



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

Re: alsa timer slippage

[Chris Cannam]

On Sunday 14 Dec 2003 2:02 pm, Jan Depner wrote:
> If I'm not mistaken the timing for your audio is coming from your
> sound card not your system clock.

Is that so?  Obvious though it is, that simply hadn't occurred to me.

I mentally ruled out a hardware problem quite early on because I 
wasn't seeing this problem when using a low-latency kernel on the 
same hardware -- but maybe I just hadn't done enough testing with the 
low-latency kernel.  I'll give it another shot.

The other points that brings to mind are, what if you have more than 
one soundcard or no soundcard at all (only say USB devices)? and what 
if the soundcard's just a chip on the motherboard, as mine is -- 
wouldn't it get its own timing from the system clock?  It's plausible 
that this crappy i810 could have a crappy timer, though this example 
would be unusually crappy.


Chris



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

Re: alsa timer slippage

[Jan Depner]

Multiple soundcards usually have to use word clock or some proprietary
method of syncing the cards.  Usually one card will be the master and
the others slaves.  I know you can put up to 4 ST Audio DSP24 cards in
one system and set one up as master.  I believe the same is true for the
M-Audio Delta 1010.

As for having a bad timer on a system, I've worked a lot with realtime
systems and sometimes you just get a lemon.

Jan


On Sun, 2003-12-14 at 08:34, Chris Cannam wrote:
> On Sunday 14 Dec 2003 2:02 pm, Jan Depner wrote:
> > If I'm not mistaken the timing for your audio is coming from your
> > sound card not your system clock.
> 
> Is that so?  Obvious though it is, that simply hadn't occurred to me.
> 
> I mentally ruled out a hardware problem quite early on because I 
> wasn't seeing this problem when using a low-latency kernel on the 
> same hardware -- but maybe I just hadn't done enough testing with the 
> low-latency kernel.  I'll give it another shot.
> 
> The other points that brings to mind are, what if you have more than 
> one soundcard or no soundcard at all (only say USB devices)? and what 
> if the soundcard's just a chip on the motherboard, as mine is -- 
> wouldn't it get its own timing from the system clock?  It's plausible 
> that this crappy i810 could have a crappy timer, though this example 
> would be unusually crappy.
> 
> 
> Chris
> 




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

Re: alsa timer slippage

[Chris Cannam]

On Sunday 14 Dec 2003 2:34 pm, Chris Cannam wrote:
> On Sunday 14 Dec 2003 2:02 pm, Jan Depner wrote:
> > If I'm not mistaken the timing for your audio is coming from your
> > sound card not your system clock.
>
> [...]
> I mentally ruled out a hardware problem quite early on because I
> wasn't seeing this problem when using a low-latency kernel on the
> same hardware -- but maybe I just hadn't done enough testing with
> the low-latency kernel.  I'll give it another shot.

No, definitely no such problem visible when using the CCRMA kernel.


Chris



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

listing devices.

[Patrick Shirkey]

I'm looking but I can't find a way to get the list of all available 
devices including virtual devices defined in the .asoundrc

Is there any function that provides this?

If not has there been any thought put into how it can be accomplished?

-- 
Patrick Shirkey - Boost Hardware Ltd.
Http://www.boosthardware.com
Http://www.djcj.org - The Linux Audio Users guide
========================================


  Apparently upon the beginning of the barrage, the donkey broke 
discipline and panicked, toppling the cart. At that point, the rockets 
disconnected from the timer, leaving them strewn around the street. 
Tethered to the now toppled cart, the donkey was unable to escape before 
the arrival of U.S. troops.

United Press International
Rockets on donkeys hit major Baghdad sites

By P. MITCHELL PROTHERO
Published 11/21/2003 11:13 AM



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

Re: listing devices.

[Patrick Shirkey]

Patrick Shirkey wrote:
> I'm looking but I can't find a way to get the list of all available 
> devices including virtual devices defined in the .asoundrc
> 
> Is there any function that provides this?
> 
> If not has there been any thought put into how it can be accomplished?
> 

Sorry missed the thread on "query devices in a non blcking way" from a 
few days ago. I'll pick it up there.
	




-- 
Patrick Shirkey - Boost Hardware Ltd.
Http://www.boosthardware.com
Http://www.djcj.org - The Linux Audio Users guide
========================================


  Apparently upon the beginning of the barrage, the donkey broke 
discipline and panicked, toppling the cart. At that point, the rockets 
disconnected from the timer, leaving them strewn around the street. 
Tethered to the now toppled cart, the donkey was unable to escape before 
the arrival of U.S. troops.

United Press International
Rockets on donkeys hit major Baghdad sites

By P. MITCHELL PROTHERO
Published 11/21/2003 11:13 AM



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

Re: alsa timer slippage

[Chris Cannam]

On Sunday 14 Dec 2003 2:34 pm, Chris Cannam wrote:
> On Sunday 14 Dec 2003 2:02 pm, Jan Depner wrote:
> > If I'm not mistaken the timing for your audio is coming from your
> > sound card not your system clock.
>
> [...] what if you have more
> than one soundcard or no soundcard at all

And of course I can trivially test that by disabling my soundcard in 
modules.conf.  So I did, and now I have no cards (at least, that's 
what /proc/asound/cards says) and yet the queue timer test program 
still runs and the queue timer still goes screwy.

So it's not a problem with the soundcard, unless ALSA is magically 
sync'ing from a soundcard I haven't told it about.


Chris



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

Re: alsa timer slippage

[Fernando Pablo Lopez-Lezcano]

On Sun, 2003-12-14 at 06:48, Chris Cannam wrote:
> On Sunday 14 Dec 2003 2:34 pm, Chris Cannam wrote:
> > On Sunday 14 Dec 2003 2:02 pm, Jan Depner wrote:
> > > If I'm not mistaken the timing for your audio is coming from your
> > > sound card not your system clock.
> >
> > [...]
> > I mentally ruled out a hardware problem quite early on because I
> > wasn't seeing this problem when using a low-latency kernel on the
> > same hardware -- but maybe I just hadn't done enough testing with
> > the low-latency kernel.  I'll give it another shot.
> 
> No, definitely no such problem visible when using the CCRMA kernel.

Or maybe it is just 10 times smaller. The Planet CCRMA kernel is
compiled with HZ=1000 (instead of the normal HZ=100). 

-- Fernando




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

Re: alsa timer slippage

[Pedro Lopez-Cabanillas]

Chris Cannam wrote:
> While trying to track down the source of some poor timing in
> sequencing, I've noticed that my ALSA sequencer queue timer has a
> tendency to fall suddenly behind.
>
> I have a little test program (available on request) that just starts a
> queue and every second or so compares the queue timer against real
> time as returned by gettimeofday().  It doesn't mind if the two don't
> quite match, but it does complain if the difference between the two
> timers changes dramatically between two sample points.  When I run
> it, it never lasts for more than about a minute before the ALSA queue
> timer suddenly slips by anything from 10 to 60 milliseconds.

Please, send me your test program.

> This is a non-low-latency kernel so I'm not surprised that there may
> be some occasional timing issues, but 60ms is a lot on an unloaded
> machine, and I am vaguely surprised that the timer doesn't notice
> it's fallen behind and recover -- instead all events on the queue
> continue to be delivered late forever.  This obviously makes for some
> disconcerting audible effects.
>
> The system is SuSE 9.0 on a dual 2GHz Athlon using SuSE's stock SMP
> kernel.  I have tried both ALSA 0.9.6 (from SuSE) and 1.0.0rc2
> drivers and libraries.  I haven't managed to reproduce it using a
> PlanetCCRMA SMP kernel on the same machine, nor on my uniprocessor
> laptop.  I've surveyed a few other people on rosegarden-devel and
> nobody's corroborated my findings, so I guess it might be related to
> using a dual-processor machine.
>
> Any thoughts on this, anyone?  I'm finding it a little depressing that
> I can't play even a minute of 4/4 beats from an ALSA test program
> without the timing slipping audibly at least once.  I'm ready to
> delve cluelessly into the timer code to take a look, but (glancing at
> alsa-kernel/core/timer.c) I'm not at all sure how far I'd get...

The ALSA MIDI sequencer can use several timer sources. By default, it uses the 
Linux system timer functions, see:
http://hegel.ittc.ukans.edu/topics/linux/man-pages/man9/init_timer.9.html

Other timer sources are PCM devices and the RTC timer. The module snd-rtctimer 
provides this functionality. To compile it for a 2.4.x kernel, you need to 
patch your rtc driver (and rebuild), see alsa-driver/utils/patches

You can set a system-wide alternate timer in your /etc/modules.conf, for 
instance: 
	options snd-seq seq_default_timer_device=1
	alias snd-timer-1 snd-rtctimer

Or your program can select an alternate timer source for a single queue. See:
http://www.mail-archive.com/alsa-user@lists.sourceforge.net/msg09048.html

Regards,
Pedro

-- 
ALSA Library Bindings for Pascal
http://alsapas.alturl.com



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

Re: alsa timer slippage

[Chris Cannam]

On Monday 15 Dec 2003 1:30 am, Pedro Lopez-Cabanillas wrote:
> The ALSA MIDI sequencer can use several timer sources. By default,
> it uses the Linux system timer functions [...]
> Other timer sources are PCM devices and the RTC timer.

Ah... so that puts Jan's comment into perspective.  I could have been 
using the soundcard to sync from, but I wasn't.  And indeed, 
switching the timer for this queue to the first PCM device gives me 
vastly better results.

This seems to suggest that the default system-based timer is doing 
something a bit naive, like assuming it was called back on time 
without actually checking.


Chris



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

Re: alsa timer slippage

[Chris Cannam]

On Monday 15 Dec 2003 9:16 am, Chris Cannam wrote:
> This seems to suggest that the default system-based timer is doing
> something a bit naive, like assuming it was called back on time
> without actually checking.

Hmm yes, even this crappy little patch to alsa-kernel/core/timer.c 
(gross adjustment to each system timer tick according to how late the 
previous one was) improves things for me.  With this the timer still 
slips, but never quite enough to be audible in a MIDI-only stream.  
The PCM clock is still much much better though.

@@ -940,9 +940,16 @@
        return 1000000000L / HZ;
 }

+static long lateness;
+
 static void snd_timer_s_function(unsigned long data)
 {
+       struct timer_list *tlist;
        snd_timer_t *timer = (snd_timer_t *)data;
+
+       tlist = (struct timer_list *) timer->private_data;
+       lateness = (long)jiffies - (long)tlist->expires;
+
        snd_timer_interrupt(timer, timer->sticks);
 }

@@ -951,7 +958,7 @@
        struct timer_list *tlist;

        tlist = (struct timer_list *) timer->private_data;
-       tlist->expires = jiffies + timer->sticks;
+       tlist->expires = jiffies + timer->sticks - lateness;
        add_timer(tlist);
        return 0;
 }


Chris



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

Re: alsa timer slippage

[Jaroslav Kysela]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1525 bytes --]

On Mon, 15 Dec 2003, Chris Cannam wrote:

> On Monday 15 Dec 2003 9:16 am, Chris Cannam wrote:
> > This seems to suggest that the default system-based timer is doing
> > something a bit naive, like assuming it was called back on time
> > without actually checking.
> 
> Hmm yes, even this crappy little patch to alsa-kernel/core/timer.c 
> (gross adjustment to each system timer tick according to how late the 
> previous one was) improves things for me.  With this the timer still 
> slips, but never quite enough to be audible in a MIDI-only stream.  
> The PCM clock is still much much better though.
> 
> @@ -940,9 +940,16 @@
>         return 1000000000L / HZ;
>  }
> 
> +static long lateness;
> +
>  static void snd_timer_s_function(unsigned long data)
>  {
> +       struct timer_list *tlist;
>         snd_timer_t *timer = (snd_timer_t *)data;
> +
> +       tlist = (struct timer_list *) timer->private_data;
> +       lateness = (long)jiffies - (long)tlist->expires;
> +
>         snd_timer_interrupt(timer, timer->sticks);
>  }
> 
> @@ -951,7 +958,7 @@
>         struct timer_list *tlist;
> 
>         tlist = (struct timer_list *) timer->private_data;
> -       tlist->expires = jiffies + timer->sticks;
> +       tlist->expires = jiffies + timer->sticks - lateness;
>         add_timer(tlist);
>         return 0;
>  }

Thanks for insigh to the problem. Can you try the attached patch?
(It's also in CVS.)

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs

[-- Attachment #2: Type: TEXT/plain, Size: 3335 bytes --]

Index: timer.c
===================================================================
RCS file: /cvsroot/alsa/alsa-kernel/core/timer.c,v
retrieving revision 1.52
retrieving revision 1.55
diff -u -r1.52 -r1.55
--- timer.c	23 Oct 2003 14:34:52 -0000	1.52
+++ timer.c	17 Dec 2003 15:14:33 -0000	1.55
@@ -935,6 +935,14 @@
  *  System timer
  */
 
+struct snd_timer_system_private {
+	struct timer_list tlist;
+	struct timer * timer;
+	unsigned long last_expires;
+	unsigned long last_jiffies;
+	unsigned long correction;
+};
+
 unsigned int snd_timer_system_resolution(void)
 {
 	return 1000000000L / HZ;
@@ -943,26 +951,44 @@
 static void snd_timer_s_function(unsigned long data)
 {
 	snd_timer_t *timer = (snd_timer_t *)data;
-	snd_timer_interrupt(timer, timer->sticks);
+	struct snd_timer_system_private *priv = timer->private_data;
+	unsigned long jiff = jiffies;
+	if (time_after(jiff, priv->last_expires))
+		priv->correction = (long)jiff - (long)priv->last_expires;
+	snd_timer_interrupt(timer, (long)jiff - (long)priv->last_jiffies);
 }
 
 static int snd_timer_s_start(snd_timer_t * timer)
 {
-	struct timer_list *tlist;
+	struct snd_timer_system_private *priv;
+	unsigned long njiff;
 
-	tlist = (struct timer_list *) timer->private_data;
-	tlist->expires = jiffies + timer->sticks;
-	add_timer(tlist);
+	priv = (struct snd_timer_system_private *) timer->private_data;
+	njiff = (priv->last_jiffies = jiffies);
+	if (priv->correction > timer->sticks - 1) {
+		priv->correction -= timer->sticks - 1;
+		njiff++;
+	} else {
+		njiff += timer->sticks - priv->correction;
+		priv->correction -= timer->sticks;
+	}
+	priv->last_expires = priv->tlist.expires = njiff;
+	add_timer(&priv->tlist);
 	return 0;
 }
 
 static int snd_timer_s_stop(snd_timer_t * timer)
 {
-	struct timer_list *tlist;
+	struct snd_timer_system_private *priv;
+	unsigned long jiff;
 
-	tlist = (struct timer_list *) timer->private_data;
-	del_timer(tlist);
-	timer->sticks = tlist->expires - jiffies;
+	priv = (struct snd_timer_system_private *) timer->private_data;
+	del_timer(&priv->tlist);
+	jiff = jiffies;
+	if (time_before(jiff, priv->last_expires))
+		timer->sticks = priv->last_expires - jiff;
+	else
+		timer->sticks = 1;
 	return 0;
 }
 
@@ -984,22 +1010,22 @@
 static int snd_timer_register_system(void)
 {
 	snd_timer_t *timer;
-	struct timer_list *tlist;
+	struct snd_timer_system_private *priv;
 	int err;
 
 	if ((err = snd_timer_global_new("system", SNDRV_TIMER_GLOBAL_SYSTEM, &timer)) < 0)
 		return err;
 	strcpy(timer->name, "system timer");
 	timer->hw = snd_timer_system;
-	tlist = (struct timer_list *) snd_kcalloc(sizeof(struct timer_list), GFP_KERNEL);
-	if (tlist == NULL) {
+	priv = (struct snd_timer_system_private *) snd_kcalloc(sizeof(struct snd_timer_system_private), GFP_KERNEL);
+	if (priv == NULL) {
 		snd_timer_free(timer);
 		return -ENOMEM;
 	}
-	init_timer(tlist);
-	tlist->function = snd_timer_s_function;
-	tlist->data = (unsigned long) timer;
-	timer->private_data = tlist;
+	init_timer(&priv->tlist);
+	priv->tlist.function = snd_timer_s_function;
+	priv->tlist.data = (unsigned long) timer;
+	timer->private_data = priv;
 	timer->private_free = snd_timer_free_system;
 	return snd_timer_global_register(timer);
 }

Re: alsa timer slippage

[Chris Cannam]

On Wednesday 17 Dec 2003 3:13 pm, Jaroslav Kysela wrote:
> Thanks for insigh to the problem. Can you try the attached patch?

Yes, that's a success.  Thank you.  It's still not absolutely perfect, 
but it's significantly better than the original version.  I've seen 
one slippage (of about 40ms, under load) in about twelve minutes of 
testing -- enough to know there's still a problem in there somewhere, 
but perhaps acceptable for a non-low-latency kernel and the like.


Chris



-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click