[pulseaudio-discuss] A pulseaudio appliance

[Lennart Poettering]

On Mon, 08.10.07 14:03, Seth Forshee (seth.forshee at gmail.com) wrote:

> > Pulse is probably trying to use floating point to do audio transforms.
> > These low end devices don't have a FPU. Software floating point is way
> > too slow and it eats 100% of your CPU.
> 
> I looked at using PA on an embedded system with no FPU a while back, and
> I found two places where a lot of floating-point calculations were being
> done:
> 
> 1) Resampling.  PA uses libsamplerate, which uses a lot of
>    floating-point math.  There was some discussion about a fixed-point
>    resampling library a while back (I think it came from the Speex
>    project), but I haven't seen anything about it in a while.

The code has been available in the "lennart" branch in SVN for a
while. Just pass --resample-method=speex-float-0 or similar.

> 2) Volume scaling.  PA converts its internal, dB-based volume level into
>    a floating-point linear scale that is applied to each sample of a
>    stream.  The code that does this for a single stream is reasonably
>    sane (although I would argue that the internal volume representation
>    should be the linear version instead of the dB version so that it
>    would only need to be converted when the volume is set), but the code
>    for scaling multiple streams is horrendously inefficient.  I did a
>    quick rewrite of this code that took CPU utilization on a P4 class PC
>    from over 30% to under 10% when playing multiple streams (I don't
>    remember exactly how many, probably 2-3).  I never cleaned up the
>    code enough to bother with submitting a patch though.

Hmm, the current code translates the volume spec first, and only
after that runs the inner loop. Should be OK. It's not liboil
accelerated, but should be good enough.

http://pulseaudio.org/browser/branches/lennart/src/pulsecore/sample-util.c#L344

> It's been at least a year since I looked at this code though, so maybe
> it has been improved since then.  But as long as it's all still based
> on floating point you're going to have a tough time using it on a
> system without an FPU. 

I think most issues for non FPU hw are fixed now. But I wouldn't want
to guarantee that all inner loops are now integer-only in all cases.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4