This fixes a later assertion failure in module-stream-restore.
Buglink: https://bugs.launchpad.net/bugs/896602
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Previously, a drain request was acknowledged up to two hw buffers
too late, causing unnecessary delays.
This implements a new chain of events called process_underrun
which triggers exactly when the sink input has finished playing,
so the drain can be acknowledged quicker.
It could later be improved to give better underrun reporting to
clients too.
Tested-by: Dmitri Paduchikh <dpaduchikh@gmail.com>
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
The previous patch removed module-gconf's dependency on the userdata
pointer of the free callback, and that was the only place where the
userdata pointer of pa_free2_cb_t was used, so now there's no need for
pa_free2_cb_t in pa_hashmap_free(). Using pa_free_cb_t instead allows
removing a significant amount of repetitive code.
idea is to allow optimized code path (similar to volume code)
and rework/specialize mixing cases to enable runtime performance improvements
no functionality changes in this patch
Signed-off-by: Peter Meerwald <pmeerw@pmeerw.net>
This makes sure we don't try to plug in a passthrough stream if the
final sink/source sample spec doesn't match what we want. In the future,
we might want to change rate updates to try a full sample spec update
for passthrough streams.
https://bugs.freedesktop.org/show_bug.cgi?id=50951
A rewind may erase data that sink_input counted in playing_for or
underrun_for earlier. Add code adjusting those values after a rewind.
One visible symptom of this bug was problems recovering from an
underrun. When a client calls pa_stream_write() with a large block of
memory, the function can split that into smaller pieces before sending
it to the server. When receiving new data for a stream that had
silence queued due to underrun, the server would do a rewind to
replace the queued-but-not-played silence with the new data. Because
of the bug, this rewind itself would not change underrun_for. It's
possible for multiple rewinds to be done without filling the sink
buffer in between (which is what would eventually reset underrun_for).
In this case, the server rapidly processing the split packets would
rewind the stream for _each_ of them (as underrun_for would stay set),
erasing valid audio as a result.
pa_sink_input_seek() calculates output lenth (slength) and
corresponding input length (ilength). During an underrun, the function
generates slength bytes of silence and adds ilength to the
underrun_for value. However, the ilength value may be shortened to
match resampler limits, and there's no corresponding adjustment to
slength. Thus, the length of the generated silence is longer than
resampler output would have been, and underrun_for should be increased
by more than the limited ilength. This error makes the user-visible
since_underrun field in struct pa_timing_info too small. Fix by using
the original value calculated before limiting in this case.
Misbehaving clients can try to set a filter sink to output to
itself, leading to crashes later on. This patch protects us from that.
Thanks to Roman Beslik for testing and finding an error in the first
version of this patch.
Tested-by: Roman Beslik <rabeslik@gmail.com>
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=44397
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
This allows clients to get a "fake" sample space for compressed formats
that we can support. This should make size/time conversion for things
like calculating buffer attributes simpler.
These utility functions could be handy to clients.
pa_format_info_to_sample_spec_fake() isn't made public, but the return
value is changed to keep in sync with pa_format_info_to_sample_spec().
If a *_UNLINK_POST hook causes a sink-input/source-output's sink/source
to go away, the subsequent attempt to update the sink/source status will
cause an assert. We deal with this by checking the sink/source status
before trying to update it.
Avoid resampling or use integer resampling when supported by the
sinks/sources
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
These are not used for anything at this point, but this
makes it easy to add ad-hoc debug prints that show the
memblockq name and to convert between bytes and usecs.
This makes sure that when we're traversing the device chain for sources
and sinks with shared volume, we handle the case that a sink-input or
source-output of one of these might be unlinked (while unloading a
module, for example).
After the rework to the add pa_sink_input_new_data_set_sink() (and
the source equiv) calling with a NULL sink object will hit an assert.
This caused crashes with the esd protocol and there was the potential
(albeit unlikely) for a crash when creating a sink input without any
sinks available (module-always-sink mitigates this risk but it's still
a potential crasher).
When the sink format changes and we kill the stream, clients need a way
to know (a) what device they should reconnect to, and (b) what the
stream running time was when the stream got killed (pa_stream_get_time()
won't work after the stream has been killed). This adds these two bits
of information in the event callback's proplist parameter.
This event is emitted if the sink-input could not be moved to a new sink
because it doesn't support the format of the sink-input. Clients can
reconnect their stream with a different format if they wish or
gracefully exit.
The assertion message is misleading, since the passthrough connection
can fail for reasons the client has no control over (like other sink
inputs being connected).
Since we currently have two mechanisms to signal a passthrough
connection (non-PCM format or PA_SINK_INPUT_PASSTHROUGH flag), we move
all the related checks into functions and use those everywhere.
This makes things more consistent, and should we decide to get rid of
the flag, we only need to change pa_sink_input_*_is_passthrough()
accordingly.
In most cases it is expected that clients cannot consume compressed
data from monitor sources, so we suspend the monitor source when the
sink goes into passthrough mode.
Eventually, when the extended API includes client notifications for
changed formats, we should emit a notification on the monitor so that
clients can decide what they want to do when this happens (disconnect or
consume the data anyway).
This will eventually be replaced by a hook to let clients know that the
stream has moved so that they can gracefully reconnect and renegotiate a
supported format.
We frequently need to free an idxset containing pa_format_infos, so
define an internal free function that can be used directly with this
(instead of defining it once-per-file).
