Bug#691081: Pulse audio is unable to play samples encoded at non-44.1khz bit rates

[Ron]

Hi Sjoerd,

On Sun, Nov 04, 2012 at 12:48:01PM +0100, Sjoerd Simons wrote:
> reassign 691081 speex 
> thanks
> 
> Judging by the LP bugreport this seems to be an issue in speex rather then in
> pulseaudio.

I'm actually going to punt this one back to you guys, because at least part
of the problem may really be in the pulse defaults -- but someone who is more
familiar with the pulse defaults for the Debian packages than I am will need
to assess that ...

The LP bug report is good for a giggle, but not really very enlightening or
on the mark in most dimensions.  And pretty much nothing there is applicable
to the system the reporter here is running either, the ubuntu ARM builds
won't run at all on that machine anyway.


There would seem to be two 'obvious' possibilities here, and a fair chance
that both are actually contributing to the problem.  One is that he's being
hit by #689049, which is a real bug in the speex resampler, and which I'll
be uploading a fix for in the next couple of hours.  But from the report
given, I don't quite buy that is his *whole* problem, since it doesn't
fully explain _all_ of what he reported without making some fairly wishful
assumptions about several missing details of things that did work for him.

What makes me think you might need to take a better look at the pulse
defaults is that he's reporting it only happens with *some* applications.
And my first guess there is that you're using the float resampler API by
default on all platforms - which you probably shouldn't be doing.

On arm, armel, armhf, mips, and mipsel, the resampler runs internally in
fixed-point - and the optimal selection for the pulse default will be to
use the fixed-point option there too.  All other Debian arches use float,
and that should be the pulse default on those.


The speex resampler provides both float and int sample APIs regardless of
the internal format being used, but it's possible that using the float
interface on systems with slow floating point is pushing some things over
the edge from being nearly resource starved to being actually so.


So ...  I'm reassigning this ticket back to pulse with the relevant question
being whether or not you need to tweak its defaults on a per-arch basis too.

If the answer to that is you're already doing so, and doing so correctly,
then I guess you can just close this one with a statement to that effect,
and if the OP isn't actually being bitten by only #689049, then the probable
answer is just that their applications suck (too many system resources), and
the fix will be to optimise things better on those arches so they don't, or
to use better apps there.

Since he says he could produce a file that played fine outside of those
particular applications, that would seem to indicate that it isn't the
resampler bug from #689049, and is simply a case of resource starvation.
We're already building speex with the optimal set of options as determined
by profiling from arch porters (and certainly for the reporter's platform)
so the only obvious degree of freedom remaining other than profiling and
writing new code where needed, is if pulse isn't actually using the best
options for calling the speex resampler on each arch by default.  On some
really slow arches you may need to reduce the chosen complexity as well
as make the right choice of float or fixed to get acceptable results.


The actual bug in speex I'll get the fix uploaded for shortly, but this
one really does look more like a problem with the pulse defaults or the
applications calling it, or possibly even a real bug in pulse with how
it handles starvation conditions.

Does pulse use float internally itself on arches where that can be very
slow and where it should be using fixed-point math instead so as not to
contribute to the starvation?

Either way, someone familiar with pulse is probably going to have to
have a more detailed look at what the choke points really are on this
particular arch.  There isn't a magic knob we can just flip in speex
to fix that for it more than we already are ...


  Sorry,
  Ron