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. 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 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. 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. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4
