[pulseaudio-discuss] [PATCH RFCv3 00/51] optimizations

[Peter Meerwald]

Hi,

> > preliminary benchmarking on Intel i5-2400S, 64-bit, Linux 3.13:
> >
> > running 'paplay --latency-msec=10 stereo_48KHz.wav', output on internal
> > soundcard (Intel HDA), measuring the maximum CPU% in top for the pulseaudio
> > and paplay
> >
> > code             flags          PA       paplay
> > master 6d1fd4d1  -O2            < 14.0%  < 3.7%
> > master 6d1fd4d1  -O2 -DNDEBUG   < 13.3%  < 3.3%
> > proposed v3      -O2             < 8.3%  < 1.3%
> > proposed v3      -O2 -DNDEBUG    < 7.6%  < 1.3%
> 
> Cool stuff!
> 
> Seems we can get the low-latency story somewhat better, and perhaps even 
> more so if we can communicate directly with the I/O threads through 
> srbchannels, but that's a different project...

> But to focus on 6.0 release; which of these patches have large enough 
> performance impact vs risk of regression to try to squeeze them into 6.0 
> rc1, and which ones can just be deferred to the -next branch?

critical patches (in my opinion) are
16: pstream: Use small minibuffer to combine reads()
17: iochannel: Fix channel enable  
20: pstream: Peek into next item on send queue 
21: pstream: don't call defer_enable() on SHMRELEASE
25: mainloop: Clear wakeup pipe only when necessary
48: alsa-sink: Assume left_to_play can be computed

the rest is just cleanup :)

I think patches up to 20 are good to go, with the exception of 17 (I'm not 
sure if I understand mainloop's io_event logic enough)

review welcome!

> Also, is v4 going to be 90 patches...? ;-)

likely yes, if no patches get commited :)

I plan to do:
* fix warnings when compiled with NDEBUG
* somehow remember linear volume and not recompute for every chunk
* refactor/de-duplicate code in alsa-sink/source

regards, p.

-- 

Peter Meerwald
+43-664-2444418 (mobile)