[pulseaudio-discuss] 0.9.15 solaris module build failure

[Finn Thain]

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
> 
>