[PlanetCCRMA] Overruns using arecord on the 2.6.9-2.3.rdt kernel on FC3...

Eric Weaver weav@sigma.net
Mon Jan 16 12:12:01 2006


> Message: 2 Date: Wed, 11 Jan 2006 23:42:35 -0800 From: Tracey Hytry
> <shakti@bayarea.net> To: planetccrma@ccrma.Stanford.EDU Subject: Re:
> [PlanetCCRMA] Overruns using arecord on the 2.6.9-2.3.rdt kernel on
> FC3... Organization: Aurinia
> 
> When you are using the 2.6.9-2.3 rdt kernel could you check the
> following: Do a "cat /proc/asound/version" Then do a "rpm -qi
> alsa-driver" and "rpm -qi alsa-lib" Could you also check
> /proc/asound/version on the 2.6.12 rdt you are trying to use?

It's 1.0.11rc2; I built it from the tarballs myself.  This is the case 
in both 2.6.9 and 2.6.12.

I have switched to using my hacked-up version of arecord which has a 
coroutine/thread doing the disk writing from a huge circular buffer. 
This has solved the problem.

[I tried submitting this hack back to the project but it was rejected]

Maybe I could do something about disk write scheduling in a kernel 
setting somewhere?


> 
> I also have some problems with a few drivers on the FC3 kernels.
> This is just a guess on my part, but I think there are a few drivers
> that need to be updated to fit the preemption models.  I think this
> will get sorted out in a little while, though it doesn't hurt to
> bring any driver problems into public view.

I'm working with the folks at AudioScience to refine this.  They're 
amazingly responsive for a hardware vendor on this rather bleeding-edge 
software type issue.

> 
> If a driver will not load you might want to try doing
> "/etc/rc.d/init.d/alsasound stop" and then
> "/etc/rc.d/init.d/alsasound start" and check the end of
> /var/log/messages for errors and if it looks like a driver/kernel
> problem bring it to our attention.
> 
> As an aside, the kernel is still changing quite rapidly and I tink we
> may see a few broken drivers here and there for a while(at least for
> us folks who are using "edge" kernels to get decent audio from our
> systems).

Yeah, I kind-of had to mix and match kernels and driver versions to find 
something that works.  Right now the system is in production with 
2.6.9-2.3.rdt and 1.0.11rc2.  It ain't broke so I don't think I'll try 
to fix it at this point.

There is an issue with arecord making the clock run slow, probably due 
to deferred interrupts, but I have ntp.conf tweaked up enough to keep it 
in sync within 1/4 second which meets our needs.


Thanks!
Eric