> You are right, those older kernels are showing much better response
> times than your kernel. One would think your newer kernel, with
> preemption or low-latency patch, would be an improvement.
>
> I honestly don't know what to tell you. It could be a piece of hardware
> (or, more accurately) its driver ...
I found out why, it's the driver. I'm an idiot for not trying
this before ... I was previously using ALSA's snd-card-ymfpci
driver; I switchted to the OSS ymfpci driver that comes with the
kernel. My latencies used to be 15ms on average, with spikes >
30ms; they're now ~3ms with some occasional spikes up to 10ms.
The graphs and numbers are up at
http://www.algorithm.com.au/hacking/linux-lowlatency/
> the /proc/latencytimes output shows us that no single lock is accounting
> for your bad times. In fact, all your locks aren't that bad, so...
>
> maybe the problem is in the "overruns" -- I don't know what that means
> exactly. maybe someone else on the list can shed some light?
> otheriwse, you can email the author perhaps.
An over-run occurs when the latencytest program, which plays a
continuous sound, doesn't get re-scheduled quickly enough. This
results in a sound dropout because it can't re-fill its buffer.
This is similar to what you would get in XMMS, except that
latencytest simulates professional audio applications which must
run with _very_ small buffers in order to get low latencies.
(Imagine your computer being sync'ed in realtime with lots of
other music equipment and have it drag behind by 30ms -- it
doesn't sound good :).
But I guess my problem's solved ... thanks so much to Andrew,
yourself, MontaVista, Dietel and all the other guys who spend
their hours benchmarking so this can be improved! If you still
want me to run benchmarks, let me know. The 15 kernels I've
compiled since starting testing have gotta be useful for
something.
-- #ozone/algorithm <ozone@algorithm.com.au> - trust.in.love.to.save - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/