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/