Maybe resample-method should be configurable through the sound settings applet?
It's a huge waste to choose anything but the fastest algo when using pc speakers which I think is quite common. When using good headphones or a mid- to highend hifi you'd want to choose a good algo over a fast one obviously.
When playing a given audio track through mplayer it consumes half the cpu compared to rhythmbox. Interestingly also the pulse process consumes half the cpu when using mplayer.
I did some crude measurements with top and a few different values for resample-method. For these values I used "mplayer -ao pulse" from a tty without X running.
src-sinc-best-quality (overkill, I know) uses between 70-100% and sound stutters with gaps of silence.
src-sinc-medium-quality almost as much stutter as above, after a minute of playing it is almost enjoyable. 30% cpu.
src-sinc-fastest uses about 8% cpu.
ffmpeg/trivial/src-linear all use about 2-3%.
Maybe resample-method should be configurable through the sound settings applet?
It's a huge waste to choose anything but the fastest algo when using pc speakers which I think is quite common. When using good headphones or a mid- to highend hifi you'd want to choose a good algo over a fast one obviously.
When playing a given audio track through mplayer it consumes half the cpu compared to rhythmbox. Interestingly also the pulse process consumes half the cpu when using mplayer.
I did some crude measurements with top and a few different values for resample-method. For these values I used "mplayer -ao pulse" from a tty without X running. best-quality (overkill, I know) uses between 70-100% and sound stutters with gaps of silence. medium- quality almost as much stutter as above, after a minute of playing it is almost enjoyable. 30% cpu. trivial/ src-linear all use about 2-3%.
src-sinc-
src-sinc-
src-sinc-fastest uses about 8% cpu.
ffmpeg/