This adds API to let external sources specify what formats a sink
supports. Sinks must opt-in to allow this, and can perform some
validation if required.
Note in protocol-dbus.c specifically, method_signatures needs to be freed
before method_handlers, because otherwise h->method_name is freed while it is
still in use as a key in the method_signatures hashmap.
This patch displays thread name in the log, that would be more descriptive.
It improves Xingchao (xingchao.wang@intel.com)'s patch which shows thread id.
Signed-off-by: Lu Guanqun <guanqun.lu@intel.com>
This patch introduces some extra protocol information, so protocol
version is bumped. This functionality is primarily needed to solve
a long standing issue in alsa-plugins, which should ignore underruns
if and only if it is obsolete, i e, if more data has been written to
the pipe in the meantime (which will automatically end the underrun).
BugLink: http://bugs.launchpad.net/bugs/805940
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Some sink flags are really just a product of what callbacks
are set on the device. We still enforce a degree of sanity
that the flags match the callbacks set, but we also set the
flags automatically in our callback setter functions to
help ensure that a) people use them and b) flags & callbacks
are kept in sync.
This is not currently useful but future commits will make further
changes concerning automatic setting of flags and event delivery
that makes this structure necessary.
For source and sinks, we allow both the index and name to be invalid
while introspecting (the default source/sink will be used). This
modifies the assert appropriately. Thanks to Drew Ogle
<dantealiegri@gmail.com> for reporting and providing a patch.
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).
This was added to ensure symmetry between playback and recording streams
code, but in reality this makes little sense practically speaking and thus
it is removed.
This piggy backs onto the previous changes for protocol 22 and
thus does not bump the version. This and the previous commits should be
seen as mostly atomic. Apologies for any bisecting issues this causes
(although I would expect these to be minimal)
The "rm" basm constraint doesn't work with my version of gcc (4.5.2),
not even in a simple example. Since we usually only have 5 registers
available on i386, force it to be memory on that architecture.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
We were calculating new latency based on the latency set on the old
sink/source, rather than the actual latency requested by the client.
Over a series of moves, this will lead the latency being ~halved each
time, resulting in an eventual rewind flood from a latency that cannot
be handled.
The proplist used may never be freed if an error condition was found with
CHECK_VALIDITY macro and the formats idxset was never freed regardless
of error state.
This change fixes adds a new maco CHECK_VALIDITY_GOTO() which allows
for cleanup to be done before returning.
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).
