[linux-audio-user] why this works now ...

[Eric Dantan Rzewnicki]

On Fri, Sep 10, 2004 at 12:42:24AM -0400, Lee Revell wrote:
> On Thu, 2004-09-09 at 23:29, Eric Dantan Rzewnicki wrote:
> Eh, this is how free software works, the concept of wasting people's
> time doesn't mean a lot.  I spent a month banging my head against the
> emu10k1 ALSA driver trying to figure out why the latency was 10 times
> worse than in windows.  Over a period of weeks I posted 5 or 6 crazy
> theories to alsa-devel, all wrong.  Turns out it was just a stupid bug
> where a bunch of instances of SND_PCM_PERIOD_SIZE needed to be changed
> to SND_PCM_PERIOD_BYTES.  I submitted a patch and now the latency is
> better than on Windows.
> Moral of the story: in free software, the only person whose time you can
> waste is your own, and it's only wasted time if you don't learn
> anything.

Thanks for the pep talk. :) I did learn a good bit over the past week.
And I'm in a good place to build a lot of different sound tools for
myself now.

> This is very, very important, and also very good news!  There have not
> been a lot of reports yet from real linux audio users.  So far UP users
> seem to be reporting very good results, while SMP/HT users are still
> seeing weird behavior.
> Can you please try the following so I can report the results to Ingo:
>     Run "echo 0 > /proc/sys/kernel/preempt_max_latency"
>     Do some audio work for while
>     Copy /proc/latency_trace to a file and send it to me via private mail
> Also, once your system seems to be running well, you should disable
> latency tracing with "echo 0 > /proc/sys/kernel/trace_enabled".  The
> latency tracer itself can generates latencies of a few ms when it
> updates /proc/latency_trace; this is not reported in the traces.

Thanks for these notes. I'll get the latency trace to you this weekend.

Thanks,
Eric Rz.