Troy Benjegerdes wrote:
It should have essentially zero overhead when properly configured, and
when its not doing anything fancy. I don't think these performance
problems are fundamental.
Don't think, benchmark :) There are a ton of non-obvious reasons one
approach might seem just fine but really suck. (cache alignments, tlb
misses, ctx switch overhead)
One step ahead of you. Thats how I found out about the floating point
resampling...
The reason I think that the performance overhead will be negligible is
that it should be using shared memory to pass the data around, and it
should never actually copy / touch the audio data inside of pulseaudio
unless it hits a hardware / alsa limitation. We can crank up the buffer
size (and latency) if things like context switches cause trouble... At
any rate, we can't measure anything until we get rid of the floating
point resampling...
For power and performance reasons on a cell phone, I think anything a
sound server does would be much better done in the kernel-level ALSA
drivers. The only downside I can see to this approach whether the
in-kernel bluetooth audio drivers are any good.
Kernel-level software resampling should be just as expensive as
userspace resampling... Pulseaudio does seem to do some soft-realtime
stuff and adds a bit of device transparency.
Last I tried bluetooth-audio on my laptop I had to run a userspace
daemon.
I have no idea what would happen with Alsa if you tried to transfer a
call between the speaker and the bluetooth set. I think pulseaudio can
handle this sort of thing correctly.
All my whining aside, seamless speaker->bluetooth handoff seems to be a
'must-have' feature. Although I would like to hear a good reason why the
kernel shouldn't be in charge of that.
Well, it's kind of a user space thing, since they're two different
(unrelated) devices. Also, pulseaudio can hand off audio over the
network, and supports some sophisticated audio processing stuff that
probably shouldn't live in the kernel...
On the other hand, for all I know, ALSA or some simple hack may be able
to handle the bluetooth thing...
Speaking of which.. do we have any way to measure the power consumption
of playing a reference .ogg file without special hardware? Are the
built-in battery charge management counters good enough?
Good question. :) Also, pulseaudio may be preventing the sound card and
cpu from falling asleep, even when no sounds are being played. From
what I can tell, it's been configured to never go idle.
