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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
