Always start ACTIVE so that negotiation can happen.
When we get a format, calculate and update the latency, cork if needed
and then go to the READY state.
This is more in line with what pulse does and should improve
compatibility.
See #341
Wait until we have linked the stream to a device or stream before
we emit the READY state. This is what pulseaudio expects.
Remove stream_index from disconnecting stream so that we don't
accidentally use it again. It is possible that we already created a
new stream with the same id before the old stream could complete the
disconnect.
When a stream does not specify ADJUST_LATENCY, use some slightly
different metrics to implement the readable_size. We want the app
to fill as much space as possible. Makes mplayer work and paplay
use the right amount of buffering.
The drain operation does not complete with a sync from the server but
with an event from the stream. Set a flag in the operation that it
completes with a sync. Keep all operations without a sync around in
the list.
Unknown channel names are mapped to aux channels.
Add extra AUX channels when we don't know the channel layout.
This makes sure apps always receive valid channel layouts so they
don't abort (pactl).
Repect minreq and fragsize for playback and capture.
Try to configure tlength at 2 seconds, minreq at around 25ms. Should
greatly improve compatibility with audacious and mpv.
Count since_underrun correctly.
Fixes#278
Implement load_module of the null sink
Keep track of sink_input/source_output linked sink/source in a
better way.
Associate the global with our streams and the streams with the
global.
Don't emit the sink_input/source_output before there is a linked device
and before our stream is READY.
Improve server info to make it more look like pulse.
When we disconnect, let the operation emit the TERMINATED state
because some apps expect this state to be emited asynchronously.
Makes GStreamer pulsesink work.
Fixes#210
Don't use always ask for the maximum amount of data in the
write_callback but subtract the queued amount of data from it or else
we will queue too much and cause huge lag.
Fixes#258
