On Sun, 19 Apr 2009, Lennart Poettering wrote: > On Fri, 17.04.09 22:58, Finn Thain (fthain at telegraphics.com.au) wrote: > > > Lennart wrote, > > > > > > > > Hmm, yes. As it seems I broke the build for non-dbus builds. > > > > Well, you also broke the solaris module between 0.9.15-test8 and > > 0.9.15. > > > > Have you considered release candidates? > > Uh. sorry. The pre-releases were supposed to act as RCs. However due to > the Fedora freeze I rushed out the final release with out having a final > rc. > > Like it or not, but for me as upstream only the complete build for > Fedora is release relevant. I understand. But it seems to me that you might have rushed out test9 for fedora instead of final. > Support for builds with weirder settings or other operating systems > won't delay my releases unless circumstances allow it and I am in a good > mood. ;-) That's your call, of course. You do realise that this means that those of us working on and using those setups have almost no chance of zero-defect releases, unlike fedora? (This is an issue for fedora if fedora users want easy interoperability with other setups. For my purposes, the example that springs to mind is a fedora guest domain with a pulseaudio setup like mine running in dom0.) > That said, I am of course always happy to merge patches for those setups > as well! > > > Patch follows. It would be nice if API changes could be made without > > breaking things when the effort to avoid that is trivial. > > Hmm, no. The internal APIs are explicitly declared unstable. I will of > course try to be nice and not do unnecessary API changes. But otherwise > I take the liberty to value clean internal APIs over API stability. But I didn't ask for a stable API... > Patch is applied! Thanks! > > One more things: for sinks/sources that do not allow dynamic > reconfiguration of latencies it is a good idea to set > sink->fixed_latency resp. source->fixed_latency to the upper limit of > the latency of the device. i.e. to the size of your hw playback buffer. > > This value is used to size the per-client buffer when the client asks > for a specific overall latency. By default this value is set to 250ms > which is probably wrong for your Solaris driver. > > It is OK if pa_sink_latency() returns values higher or lower than this > value. However setting this correctly improves the accuracy if a client > requests a specific latency it actually gets it. OK, I will look into implementing dynamic latency or fixed latency. Thanks for the heads-up. Finn > Lennart > >
