17.09.2014 15:05, David Henningsson ?????: > > > On 2014-09-16 22:25, Martin Steigerwald wrote: >> Hello! >> >> Any solution for this? >> >> When playing PlaneShift through Pulseaudio while PlaneShift is setup >> to use >> OpenAL as sound renderer I get: >> >> AL lib: pulseaudio.c:331: PulseAudio returned minreq > tlength/2; >> expect break >> up >> >> and well badly stuttering sound. > > I'm not very familiar with OpenAL, and a quick look through the source > (in Ubuntu 14.04) did not show any such warning message. > > So I'm not sure what that warning means, and if the error is in OpenAL > or in PulseAudio. > > In theory, any application should be able deal with big minreqs and > tlengths. In practice I know we've had issues with tlengths increasing > gradually in the past, and I'm not sure all those issues have been root > caused. Well, I have a strong (and possibly too-strong) opinion on this. The problem is that "any application should be able deal with big minreqs" is just not going to happen, and users will blame PulseAudio no matter where the bug actually is. There have been several times that I was able to fix users' problems on USB audio by telling them to reduce default-fragment-size-msec. I don't have an opinion on large tlength. Therefore, a proposal (definitely post-6.0): kill non-tsched mode (of course, after fixing tsched where this is needed). After the rewindability-related fixes to the buffer size choice algorithm and to the safeguard, I think that non-tsched will no longer be needed even on non-rewindable devices. And then, the minreq size will be determined only by the system timer resolution and may well be smaller than one period. As for tlength, if it has been increased due to bad scheduler or unavoidable latency, we can, in the worst case, hide this from legacy applications at the cost of reporting latency inaccurately to them. -- Alexander E. Patrakov
