On Fri, 2001-10-05 at 03:29, Takashi Iwai wrote:
> At 04 Oct 2001 19:21:35 -0700,
> Josh Green wrote:
> > 
> > Aggh.. I just ran a whole bunch of ALSA latencytests with various
> > drivers/kernels, all with fairly bad results :( I even went back to my
> > older kernel (2.4.5 with Andrew Morton's patch) with my AWE 32 card,
> > which I had good results with before, and got like 5 to 8ms spikes. I'm
> > not sure what the heck is going on with my machine now, but its
> > certainly not good.
> 
> I feel that your old results were too good.
> But the new results seem also too bad compared with mine.
> Or any hardware changes?  hdparm, APM, etc..
> 

I've been suspicious of that myself (the part about my old results being
too good). Of course the sound output never had a glitch, whereas now I
hear them sometimes (and the output is fairly fuzzed up, how would I
send the audio stream with ALSA to a file? I've seen it on the list
before, perhaps I would search the archives if geocrawler searched!). Of
course I can't be sure how big the audio buffers were as there were some
issues with oss emulation under ALSA with latencytest.

> > Are there any programs that report what piece of
> > code is causing big spikes? I haven't tested the 2.4.10 kernel yet, and
> > if I did it would be bare without any patches (as I don't know of any up
> > to date with 2.4.10). I did realize that the 2.4.9 kernel with LL patch
> > is worse than the 2.4.5 one I was using. This might be because I
> > compiled it with Mandrake's gcc a la 2.96.
> 
> As far as I've experienced, the VM of 2.4.9 tends to have higher
> latency under heavy disk loads.  On 2.4.10 the VM was changed much and
> became better.
> 
> I discussed with Andrea about this problem, and he will check the
> relevant part.  Hopefully any patch will come to 2.4.11.
> 

Sounds good. I noticed the memory management got worked heavily between
2.4.9 and 2.4.10. I couldn't really just logically do a manual apply of
rejects for the LL patch for 2.4.9. Its nice to hear that its for the
better :)

> 
> 
> > By the way I'm posting my results to http://www.c0nfusion.org/~josh/ if
> > you want to have a look. The only hardware that has changed in my
> > machine since my previous tests (http://www.resonance.org/~josh/) is I
> > added an SB Live!. I think I upgraded to Mandrake 8 between then, so
> > most of the software is probably different.
> 
> Ah, the last test looks really fantastic..
> I wish in near future we get it back!
> 

Alas, the last test is with OSS (my test #4 was with ALSA though, which
has similar #s as far as latency). I wonder about the OSS latencytest
though. It seems like the latency is fairly equivelant. The only
difference being the huge # of overruns with ALSA compared to OSS. I
wonder if the OSS overrun detection is correct. I haven't looked at the
latencytest code recently, but I seem to remember it manually
determining if an overrun was caused or not (by comparing the latency
with the fragment period). I also noticed that the buffer size with OSS
was 1024 rather than 768 bytes. I think this is just one extra fragment
though, so that shouldn't affect it right?

> 
> ciao,
> 
> Takashi

Not sure if you saw my question about whether there is some way to
determine where in the kernel a hold up occurs. How does Andrew Morton
check those things? Seems like a tool to determine what driver, program
or kernel routine is causing latency spikes would be a useful tool.

-- 
    Josh Green
    Smurf Sound Font Editor (http://smurf.sourceforge.net)


_______________________________________________
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Reply via email to