[pulseaudio-discuss] equalizer continued

[Jason Newton]

I put a public git repo up at
http://gitorious.org/pulseaudio-equalizer/pulseaudio-equalizer
Here's some timing info

measured cpu usage w/ htop and as pa as a whole, unfortunately forgot to
do it for the first run.
window_size=7999
.014-0.29 seconds @ 800 mhz
.004-.009 seconds @ 2.2ghz
window_size=15999
.007-.015 seconds to process @ 800 mhz 20-30%
.005-.01 seconds to process @ 2.2 ghz 7% cpu utilization

Audio was dropping out like hell but dropouts only consisted of about
10% of playing time.

This is per sample prepare and sample processing iterations of my fully
debug compiled build unoptimized to hell
(CFLAGS="-O0 -ggdb -mtune=native -fno-strict-aliasing")
CPU isn't the problem exactly the problem at least.  I'm pretty sure its
choking at the granularity of sample processing,
ie every x samples where x is some constant.

I'm considering that the callback doesn't like to spend even that amount
of cpu time too.  And to avoid this, perhaps splitting
off a thread for processing so that the pop callback only peeks on the
rendered memblockq and waits if necessary and never
actually does any processing other than organizing data for the
processing thread to consume.  I believe it'd lower the average
time spent in pop given that less work would be performed inside the
callback. OTOH I'm not sure this will really make a
difference in the actual choking/granularity problem, if it is indeed
the case.


On 07/21/2009 03:35 PM, Tanu Kaskinen wrote:
> I tried the newest patch you posted to the mailing list. I didn't get
> any mempool full messages, maybe you got that fixed?
>
> On my machine playback is mostly very choppy, which seems to be because
> of high CPU use. If I run pulseaudio and pipe the output to /dev/null
> I'm able to get some stable periods. At those times CPU use hovers at
> 50%. I have AMD Sempron LE-1250, which is a cheap 2.2 GHz processor
> (cheapest what I was able to find as new last winter). Automatic CPU
> frequency scaling causes the processor to run mostly at 1.0 GHz. The
> glitches are caused by underruns: the client stream has nothing buffered
> when we call pa_sink_render_into. I suspect that the OS just doesn't
> schedule the client process fast enough. I think my system is quite bad
> with regards to scheduling latency, I have Debian unstable.
>
> I have attached some log output from stream creation to stream shutdown,
> in case you're interested.
>
> I did a couple of changes to the code (I hope the line numbers haven't
> changed; I don't have the original currently available):
>
> I added the number of samples we get from pa_sink_render_into to a log
> message. Lines 364-366 are now the following:
>
>         if (buffered_samples >= samples_requested) {
>             pa_sink_render_into(u->sink, &u->conv_buffer);
>             pa_log("asked for %ld input samples, got %ld samples",
> desired_samples, u->conv_buffer.length / fs);
>
> (If you see four lines, the two last lines should be on one line.)
>
> Line 411 seemed to contain a bug, I changed it to
>
>             size_t l = PA_MIN(tchunk.length, nbytes - copied);
>
> Additionally, lines 401 and 402 seem to just cancel out each other,
> since the memblock pointer is copied from tchunk to chunk:
>
>         pa_memblock_ref(chunk->memblock);
>         pa_memblock_unref(tchunk.memblock);
>
> In conclusion, it's not fast enough currently. I don't know what could
> be done about that. I believe copying could be reduced somewhat, but I
> doubt that's the biggest problem.
>
>