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)
