[pulseaudio-discuss] A pulseaudio appliance

Seth Forshee seth.forshee at gmail.com
Mon Oct 8 12:03:08 PDT 2007

On Wed, Oct 03, 2007 at 03:54:54PM -0400, Jon Smirl wrote:
> On 10/3/07, Kevin Fox <Kevin.Fox at pnl.gov> wrote:
> > We've been trying over here to get pulseaudio working on a wma11b and a
> > wyse winterm s90 and have been unsuccessful. Most of these lower power
> > devices only work with one type of audio and makes pulse transcode
> > otherwise. pulse hits 100% and can't transcode quickly enough. :/
> >
> > I've heard it may be a problem with a library pulse depends on not being
> > very efficient. Any ideas when this might be fixed?
> 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

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.

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.

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. 


More information about the pulseaudio-discuss mailing list