pulseaudio/src/modules/module-remap-sink.c

511 lines
16 KiB
C
Raw Normal View History

/***
This file is part of PulseAudio.
Copyright 2004-2009 Lennart Poettering
PulseAudio is free software; you can redistribute it and/or modify
it under the terms of the GNU Lesser General Public License as published
by the Free Software Foundation; either version 2.1 of the License,
or (at your option) any later version.
PulseAudio is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
General Public License for more details.
You should have received a copy of the GNU Lesser General Public License
along with PulseAudio; if not, see <http://www.gnu.org/licenses/>.
***/
#ifdef HAVE_CONFIG_H
#include <config.h>
#endif
#include <pulse/xmalloc.h>
#include <pulsecore/namereg.h>
#include <pulsecore/sink.h>
#include <pulsecore/module.h>
#include <pulsecore/core-util.h>
#include <pulsecore/modargs.h>
#include <pulsecore/log.h>
#include <pulsecore/rtpoll.h>
#include "module-remap-sink-symdef.h"
PA_MODULE_AUTHOR("Lennart Poettering");
PA_MODULE_DESCRIPTION("Virtual channel remapping sink");
PA_MODULE_VERSION(PACKAGE_VERSION);
PA_MODULE_LOAD_ONCE(false);
PA_MODULE_USAGE(
"sink_name=<name for the sink> "
"sink_properties=<properties for the sink> "
"master=<name of sink to remap> "
"master_channel_map=<channel map> "
"format=<sample format> "
"rate=<sample rate> "
"channels=<number of channels> "
2008-06-19 19:23:14 +02:00
"channel_map=<channel map> "
"resample_method=<resampler> "
2008-06-19 19:23:14 +02:00
"remix=<remix channels?>");
struct userdata {
pa_module *module;
pa_sink *sink;
pa_sink_input *sink_input;
bool auto_desc;
};
static const char* const valid_modargs[] = {
"sink_name",
"sink_properties",
"master",
"master_channel_map",
"format",
"rate",
"channels",
"channel_map",
"resample_method",
2008-06-19 19:23:14 +02:00
"remix",
NULL
};
/* Called from I/O thread context */
static int sink_process_msg(pa_msgobject *o, int code, void *data, int64_t offset, pa_memchunk *chunk) {
struct userdata *u = PA_SINK(o)->userdata;
switch (code) {
case PA_SINK_MESSAGE_GET_LATENCY:
/* The sink is _put() before the sink input is, so let's
* make sure we don't access it yet */
if (!PA_SINK_IS_LINKED(u->sink->thread_info.state) ||
!PA_SINK_INPUT_IS_LINKED(u->sink_input->thread_info.state)) {
source/sink: Allow pa_{source, sink}_get_latency_within_thread() to return negative values The reported latency of source or sink is based on measured initial conditions. If the conditions contain an error, the estimated latency values may become negative. This does not indicate that the latency is indeed negative but can be considered merely an offset error. The current get_latency_in_thread() calls and the implementations of the PA_{SINK,SOURCE}_MESSAGE_GET_LATENCY messages truncate negative latencies because they do not make sense from a physical point of view. In fact, the values are truncated twice, once in the message handler and a second time in the pa_{source,sink}_get_latency_within_thread() call itself. This leads to two problems for the latency controller within module-loopback: - Truncating leads to discontinuities in the latency reports which then trigger unwanted end to end latency corrections. - If a large negative port latency offsets is set, the reported latency is always 0, making it impossible to control the end to end latency at all. This patch is a pre-condition for solving these problems. It adds a new flag to pa_{sink,source}_get_latency_within_thread() to allow negative return values. Truncating is also removed in all implementations of the PA_{SINK,SOURCE}_MESSAGE_GET_LATENCY message handlers. The allow_negative flag is set to false for all calls of pa_{sink,source}_get_latency_within_thread() except when used within PA_{SINK,SOURCE}_MESSAGE_GET_LATENCY. This means that the original behavior is not altered in most cases. Only if a positive latency offset is set and the message returns a negative value, the reported latency is smaller because the values are not truncated twice. Additionally let PA_SOURCE_MESSAGE_GET_LATENCY return -pa_sink_get_latency_within_thread() for monitor sources because the source gets the data before it is played.
2017-04-17 19:50:10 +02:00
*((int64_t*) data) = 0;
return 0;
}
source/sink: Allow pa_{source, sink}_get_latency_within_thread() to return negative values The reported latency of source or sink is based on measured initial conditions. If the conditions contain an error, the estimated latency values may become negative. This does not indicate that the latency is indeed negative but can be considered merely an offset error. The current get_latency_in_thread() calls and the implementations of the PA_{SINK,SOURCE}_MESSAGE_GET_LATENCY messages truncate negative latencies because they do not make sense from a physical point of view. In fact, the values are truncated twice, once in the message handler and a second time in the pa_{source,sink}_get_latency_within_thread() call itself. This leads to two problems for the latency controller within module-loopback: - Truncating leads to discontinuities in the latency reports which then trigger unwanted end to end latency corrections. - If a large negative port latency offsets is set, the reported latency is always 0, making it impossible to control the end to end latency at all. This patch is a pre-condition for solving these problems. It adds a new flag to pa_{sink,source}_get_latency_within_thread() to allow negative return values. Truncating is also removed in all implementations of the PA_{SINK,SOURCE}_MESSAGE_GET_LATENCY message handlers. The allow_negative flag is set to false for all calls of pa_{sink,source}_get_latency_within_thread() except when used within PA_{SINK,SOURCE}_MESSAGE_GET_LATENCY. This means that the original behavior is not altered in most cases. Only if a positive latency offset is set and the message returns a negative value, the reported latency is smaller because the values are not truncated twice. Additionally let PA_SOURCE_MESSAGE_GET_LATENCY return -pa_sink_get_latency_within_thread() for monitor sources because the source gets the data before it is played.
2017-04-17 19:50:10 +02:00
*((int64_t*) data) =
/* Get the latency of the master sink */
source/sink: Allow pa_{source, sink}_get_latency_within_thread() to return negative values The reported latency of source or sink is based on measured initial conditions. If the conditions contain an error, the estimated latency values may become negative. This does not indicate that the latency is indeed negative but can be considered merely an offset error. The current get_latency_in_thread() calls and the implementations of the PA_{SINK,SOURCE}_MESSAGE_GET_LATENCY messages truncate negative latencies because they do not make sense from a physical point of view. In fact, the values are truncated twice, once in the message handler and a second time in the pa_{source,sink}_get_latency_within_thread() call itself. This leads to two problems for the latency controller within module-loopback: - Truncating leads to discontinuities in the latency reports which then trigger unwanted end to end latency corrections. - If a large negative port latency offsets is set, the reported latency is always 0, making it impossible to control the end to end latency at all. This patch is a pre-condition for solving these problems. It adds a new flag to pa_{sink,source}_get_latency_within_thread() to allow negative return values. Truncating is also removed in all implementations of the PA_{SINK,SOURCE}_MESSAGE_GET_LATENCY message handlers. The allow_negative flag is set to false for all calls of pa_{sink,source}_get_latency_within_thread() except when used within PA_{SINK,SOURCE}_MESSAGE_GET_LATENCY. This means that the original behavior is not altered in most cases. Only if a positive latency offset is set and the message returns a negative value, the reported latency is smaller because the values are not truncated twice. Additionally let PA_SOURCE_MESSAGE_GET_LATENCY return -pa_sink_get_latency_within_thread() for monitor sources because the source gets the data before it is played.
2017-04-17 19:50:10 +02:00
pa_sink_get_latency_within_thread(u->sink_input->sink, true) +
/* Add the latency internal to our sink input on top */
pa_bytes_to_usec(pa_memblockq_get_length(u->sink_input->thread_info.render_memblockq), &u->sink_input->sink->sample_spec);
return 0;
virtual sources and sinks: Don't double attach a sink input or source output on filter load When a filter is loaded and module-switch-on-connect is present, switch-on-connect will make the filter the default sink or source and move streams from the old default to the filter. This is done from the sink/source put hook, therefore streams are moved to the filter before the module init function of the filter calls sink_input_put() or source_output_put(). The move succeeds because the asyncmsq already points to the queue of the master sink or source. When the master sink or source is attached to the sink input or source output, the attach callback will call pa_{sink,source}_attach_within_thread(). These functions assume that all streams are detached. Because streams were already moved to the filter by switch-on-connect, this assumption leads to an assertion in pa_{sink_input,source_output}_attach(). This patch fixes the problem by reverting the order of the pa_{sink,source}_put() calls and the pa_{sink_input,source_output}_put calls and creating the sink input or source output corked. The initial rewind that is done for the master sink is moved to the sink message handler. The order of the unlink calls is swapped as well to prevent that the filter appears to be moving during module unload. The patch also seems to improve user experience, the move of a stream to the filter sink is now done without any audible interruption on my system. The patch is only tested for module-echo-cancel. Bug-Link: https://bugs.freedesktop.org/show_bug.cgi?id=100065
2017-05-18 07:46:46 +02:00
case PA_SINK_MESSAGE_SET_STATE: {
pa_sink_state_t new_state = (pa_sink_state_t) PA_PTR_TO_UINT(data);
/* When set to running or idle for the first time, request a rewind
* of the master sink to make sure we are heard immediately */
if ((new_state == PA_SINK_IDLE || new_state == PA_SINK_RUNNING) && u->sink->thread_info.state == PA_SINK_INIT) {
pa_log_debug("Requesting rewind due to state change.");
pa_sink_input_request_rewind(u->sink_input, 0, false, true, true);
}
break;
}
}
return pa_sink_process_msg(o, code, data, offset, chunk);
}
/* Called from main context */
static int sink_set_state(pa_sink *s, pa_sink_state_t state) {
struct userdata *u;
pa_sink_assert_ref(s);
pa_assert_se(u = s->userdata);
if (!PA_SINK_IS_LINKED(state) ||
!PA_SINK_INPUT_IS_LINKED(pa_sink_input_get_state(u->sink_input)))
return 0;
pa_sink_input_cork(u->sink_input, state == PA_SINK_SUSPENDED);
return 0;
}
/* Called from I/O thread context */
static void sink_request_rewind(pa_sink *s) {
struct userdata *u;
pa_sink_assert_ref(s);
pa_assert_se(u = s->userdata);
if (!PA_SINK_IS_LINKED(u->sink->thread_info.state) ||
!PA_SINK_INPUT_IS_LINKED(u->sink_input->thread_info.state))
return;
pa_sink_input_request_rewind(u->sink_input, s->thread_info.rewind_nbytes, true, false, false);
}
/* Called from I/O thread context */
static void sink_update_requested_latency(pa_sink *s) {
struct userdata *u;
pa_sink_assert_ref(s);
pa_assert_se(u = s->userdata);
if (!PA_SINK_IS_LINKED(u->sink->thread_info.state) ||
!PA_SINK_INPUT_IS_LINKED(u->sink_input->thread_info.state))
return;
/* Just hand this one over to the master sink */
pa_sink_input_set_requested_latency_within_thread(
u->sink_input,
pa_sink_get_requested_latency_within_thread(s));
}
/* Called from I/O thread context */
static int sink_input_pop_cb(pa_sink_input *i, size_t nbytes, pa_memchunk *chunk) {
struct userdata *u;
pa_sink_input_assert_ref(i);
pa_assert(chunk);
pa_assert_se(u = i->userdata);
virtual sources and sinks: Don't double attach a sink input or source output on filter load When a filter is loaded and module-switch-on-connect is present, switch-on-connect will make the filter the default sink or source and move streams from the old default to the filter. This is done from the sink/source put hook, therefore streams are moved to the filter before the module init function of the filter calls sink_input_put() or source_output_put(). The move succeeds because the asyncmsq already points to the queue of the master sink or source. When the master sink or source is attached to the sink input or source output, the attach callback will call pa_{sink,source}_attach_within_thread(). These functions assume that all streams are detached. Because streams were already moved to the filter by switch-on-connect, this assumption leads to an assertion in pa_{sink_input,source_output}_attach(). This patch fixes the problem by reverting the order of the pa_{sink,source}_put() calls and the pa_{sink_input,source_output}_put calls and creating the sink input or source output corked. The initial rewind that is done for the master sink is moved to the sink message handler. The order of the unlink calls is swapped as well to prevent that the filter appears to be moving during module unload. The patch also seems to improve user experience, the move of a stream to the filter sink is now done without any audible interruption on my system. The patch is only tested for module-echo-cancel. Bug-Link: https://bugs.freedesktop.org/show_bug.cgi?id=100065
2017-05-18 07:46:46 +02:00
if (!PA_SINK_IS_LINKED(u->sink->thread_info.state))
return -1;
/* Hmm, process any rewind request that might be queued up */
pa_sink_process_rewind(u->sink, 0);
pa_sink_render(u->sink, nbytes, chunk);
return 0;
}
/* Called from I/O thread context */
static void sink_input_process_rewind_cb(pa_sink_input *i, size_t nbytes) {
size_t amount = 0;
struct userdata *u;
pa_sink_input_assert_ref(i);
pa_assert_se(u = i->userdata);
virtual sources and sinks: Don't double attach a sink input or source output on filter load When a filter is loaded and module-switch-on-connect is present, switch-on-connect will make the filter the default sink or source and move streams from the old default to the filter. This is done from the sink/source put hook, therefore streams are moved to the filter before the module init function of the filter calls sink_input_put() or source_output_put(). The move succeeds because the asyncmsq already points to the queue of the master sink or source. When the master sink or source is attached to the sink input or source output, the attach callback will call pa_{sink,source}_attach_within_thread(). These functions assume that all streams are detached. Because streams were already moved to the filter by switch-on-connect, this assumption leads to an assertion in pa_{sink_input,source_output}_attach(). This patch fixes the problem by reverting the order of the pa_{sink,source}_put() calls and the pa_{sink_input,source_output}_put calls and creating the sink input or source output corked. The initial rewind that is done for the master sink is moved to the sink message handler. The order of the unlink calls is swapped as well to prevent that the filter appears to be moving during module unload. The patch also seems to improve user experience, the move of a stream to the filter sink is now done without any audible interruption on my system. The patch is only tested for module-echo-cancel. Bug-Link: https://bugs.freedesktop.org/show_bug.cgi?id=100065
2017-05-18 07:46:46 +02:00
/* If the sink is not yet linked, there is nothing to rewind */
if (!PA_SINK_IS_LINKED(u->sink->thread_info.state))
return;
if (u->sink->thread_info.rewind_nbytes > 0) {
amount = PA_MIN(u->sink->thread_info.rewind_nbytes, nbytes);
u->sink->thread_info.rewind_nbytes = 0;
}
pa_sink_process_rewind(u->sink, amount);
}
/* Called from I/O thread context */
static void sink_input_update_max_rewind_cb(pa_sink_input *i, size_t nbytes) {
struct userdata *u;
pa_sink_input_assert_ref(i);
pa_assert_se(u = i->userdata);
2012-08-19 14:49:27 +03:00
/* FIXME: Too small max_rewind:
* https://bugs.freedesktop.org/show_bug.cgi?id=53709 */
pa_sink_set_max_rewind_within_thread(u->sink, nbytes);
}
/* Called from I/O thread context */
static void sink_input_update_max_request_cb(pa_sink_input *i, size_t nbytes) {
struct userdata *u;
pa_sink_input_assert_ref(i);
pa_assert_se(u = i->userdata);
pa_sink_set_max_request_within_thread(u->sink, nbytes);
}
/* Called from I/O thread context */
static void sink_input_update_sink_latency_range_cb(pa_sink_input *i) {
struct userdata *u;
pa_sink_input_assert_ref(i);
pa_assert_se(u = i->userdata);
pa_sink_set_latency_range_within_thread(u->sink, i->sink->thread_info.min_latency, i->sink->thread_info.max_latency);
}
/* Called from I/O thread context */
static void sink_input_update_sink_fixed_latency_cb(pa_sink_input *i) {
struct userdata *u;
pa_sink_input_assert_ref(i);
pa_assert_se(u = i->userdata);
pa_sink_set_fixed_latency_within_thread(u->sink, i->sink->thread_info.fixed_latency);
}
/* Called from I/O thread context */
static void sink_input_detach_cb(pa_sink_input *i) {
struct userdata *u;
pa_sink_input_assert_ref(i);
pa_assert_se(u = i->userdata);
virtual sources and sinks: Don't double attach a sink input or source output on filter load When a filter is loaded and module-switch-on-connect is present, switch-on-connect will make the filter the default sink or source and move streams from the old default to the filter. This is done from the sink/source put hook, therefore streams are moved to the filter before the module init function of the filter calls sink_input_put() or source_output_put(). The move succeeds because the asyncmsq already points to the queue of the master sink or source. When the master sink or source is attached to the sink input or source output, the attach callback will call pa_{sink,source}_attach_within_thread(). These functions assume that all streams are detached. Because streams were already moved to the filter by switch-on-connect, this assumption leads to an assertion in pa_{sink_input,source_output}_attach(). This patch fixes the problem by reverting the order of the pa_{sink,source}_put() calls and the pa_{sink_input,source_output}_put calls and creating the sink input or source output corked. The initial rewind that is done for the master sink is moved to the sink message handler. The order of the unlink calls is swapped as well to prevent that the filter appears to be moving during module unload. The patch also seems to improve user experience, the move of a stream to the filter sink is now done without any audible interruption on my system. The patch is only tested for module-echo-cancel. Bug-Link: https://bugs.freedesktop.org/show_bug.cgi?id=100065
2017-05-18 07:46:46 +02:00
if (PA_SINK_IS_LINKED(u->sink->thread_info.state))
pa_sink_detach_within_thread(u->sink);
pa_sink_set_rtpoll(u->sink, NULL);
}
/* Called from I/O thread context */
static void sink_input_attach_cb(pa_sink_input *i) {
struct userdata *u;
pa_sink_input_assert_ref(i);
pa_assert_se(u = i->userdata);
pa_sink_set_rtpoll(u->sink, i->sink->thread_info.rtpoll);
pa_sink_set_latency_range_within_thread(u->sink, i->sink->thread_info.min_latency, i->sink->thread_info.max_latency);
pa_sink_set_fixed_latency_within_thread(u->sink, i->sink->thread_info.fixed_latency);
pa_sink_set_max_request_within_thread(u->sink, pa_sink_input_get_max_request(i));
2012-08-19 14:49:27 +03:00
/* FIXME: Too small max_rewind:
* https://bugs.freedesktop.org/show_bug.cgi?id=53709 */
pa_sink_set_max_rewind_within_thread(u->sink, pa_sink_input_get_max_rewind(i));
virtual sources and sinks: Don't double attach a sink input or source output on filter load When a filter is loaded and module-switch-on-connect is present, switch-on-connect will make the filter the default sink or source and move streams from the old default to the filter. This is done from the sink/source put hook, therefore streams are moved to the filter before the module init function of the filter calls sink_input_put() or source_output_put(). The move succeeds because the asyncmsq already points to the queue of the master sink or source. When the master sink or source is attached to the sink input or source output, the attach callback will call pa_{sink,source}_attach_within_thread(). These functions assume that all streams are detached. Because streams were already moved to the filter by switch-on-connect, this assumption leads to an assertion in pa_{sink_input,source_output}_attach(). This patch fixes the problem by reverting the order of the pa_{sink,source}_put() calls and the pa_{sink_input,source_output}_put calls and creating the sink input or source output corked. The initial rewind that is done for the master sink is moved to the sink message handler. The order of the unlink calls is swapped as well to prevent that the filter appears to be moving during module unload. The patch also seems to improve user experience, the move of a stream to the filter sink is now done without any audible interruption on my system. The patch is only tested for module-echo-cancel. Bug-Link: https://bugs.freedesktop.org/show_bug.cgi?id=100065
2017-05-18 07:46:46 +02:00
if (PA_SINK_IS_LINKED(u->sink->thread_info.state))
pa_sink_attach_within_thread(u->sink);
}
/* Called from main context */
static void sink_input_kill_cb(pa_sink_input *i) {
struct userdata *u;
pa_sink_input_assert_ref(i);
pa_assert_se(u = i->userdata);
virtual sources and sinks: Don't double attach a sink input or source output on filter load When a filter is loaded and module-switch-on-connect is present, switch-on-connect will make the filter the default sink or source and move streams from the old default to the filter. This is done from the sink/source put hook, therefore streams are moved to the filter before the module init function of the filter calls sink_input_put() or source_output_put(). The move succeeds because the asyncmsq already points to the queue of the master sink or source. When the master sink or source is attached to the sink input or source output, the attach callback will call pa_{sink,source}_attach_within_thread(). These functions assume that all streams are detached. Because streams were already moved to the filter by switch-on-connect, this assumption leads to an assertion in pa_{sink_input,source_output}_attach(). This patch fixes the problem by reverting the order of the pa_{sink,source}_put() calls and the pa_{sink_input,source_output}_put calls and creating the sink input or source output corked. The initial rewind that is done for the master sink is moved to the sink message handler. The order of the unlink calls is swapped as well to prevent that the filter appears to be moving during module unload. The patch also seems to improve user experience, the move of a stream to the filter sink is now done without any audible interruption on my system. The patch is only tested for module-echo-cancel. Bug-Link: https://bugs.freedesktop.org/show_bug.cgi?id=100065
2017-05-18 07:46:46 +02:00
/* The order here matters! We first kill the sink so that streams
* can properly be moved away while the sink input is still connected
* to the master. */
pa_sink_input_cork(u->sink_input, true);
pa_sink_unlink(u->sink);
virtual sources and sinks: Don't double attach a sink input or source output on filter load When a filter is loaded and module-switch-on-connect is present, switch-on-connect will make the filter the default sink or source and move streams from the old default to the filter. This is done from the sink/source put hook, therefore streams are moved to the filter before the module init function of the filter calls sink_input_put() or source_output_put(). The move succeeds because the asyncmsq already points to the queue of the master sink or source. When the master sink or source is attached to the sink input or source output, the attach callback will call pa_{sink,source}_attach_within_thread(). These functions assume that all streams are detached. Because streams were already moved to the filter by switch-on-connect, this assumption leads to an assertion in pa_{sink_input,source_output}_attach(). This patch fixes the problem by reverting the order of the pa_{sink,source}_put() calls and the pa_{sink_input,source_output}_put calls and creating the sink input or source output corked. The initial rewind that is done for the master sink is moved to the sink message handler. The order of the unlink calls is swapped as well to prevent that the filter appears to be moving during module unload. The patch also seems to improve user experience, the move of a stream to the filter sink is now done without any audible interruption on my system. The patch is only tested for module-echo-cancel. Bug-Link: https://bugs.freedesktop.org/show_bug.cgi?id=100065
2017-05-18 07:46:46 +02:00
pa_sink_input_unlink(u->sink_input);
pa_sink_input_unref(u->sink_input);
u->sink_input = NULL;
pa_sink_unref(u->sink);
u->sink = NULL;
pa_module_unload_request(u->module, true);
}
/* Called from main context */
static void sink_input_moving_cb(pa_sink_input *i, pa_sink *dest) {
struct userdata *u;
pa_sink_input_assert_ref(i);
pa_assert_se(u = i->userdata);
if (dest) {
pa_sink_set_asyncmsgq(u->sink, dest->asyncmsgq);
pa_sink_update_flags(u->sink, PA_SINK_LATENCY|PA_SINK_DYNAMIC_LATENCY, dest->flags);
} else
pa_sink_set_asyncmsgq(u->sink, NULL);
if (u->auto_desc && dest) {
const char *k;
pa_proplist *pl;
pl = pa_proplist_new();
k = pa_proplist_gets(dest->proplist, PA_PROP_DEVICE_DESCRIPTION);
pa_proplist_setf(pl, PA_PROP_DEVICE_DESCRIPTION, "Remapped %s", k ? k : dest->name);
pa_sink_update_proplist(u->sink, PA_UPDATE_REPLACE, pl);
pa_proplist_free(pl);
}
}
int pa__init(pa_module*m) {
struct userdata *u;
pa_sample_spec ss;
pa_resample_method_t resample_method = PA_RESAMPLER_INVALID;
pa_channel_map sink_map, stream_map;
pa_modargs *ma;
pa_sink *master;
pa_sink_input_new_data sink_input_data;
pa_sink_new_data sink_data;
bool remix = true;
pa_assert(m);
if (!(ma = pa_modargs_new(m->argument, valid_modargs))) {
pa_log("Failed to parse module arguments.");
goto fail;
}
2009-01-15 20:07:13 +01:00
if (!(master = pa_namereg_get(m->core, pa_modargs_get_value(ma, "master", NULL), PA_NAMEREG_SINK))) {
pa_log("Master sink not found");
goto fail;
}
ss = master->sample_spec;
sink_map = master->channel_map;
if (pa_modargs_get_sample_spec_and_channel_map(ma, &ss, &sink_map, PA_CHANNEL_MAP_DEFAULT) < 0) {
pa_log("Invalid sample format specification or channel map");
goto fail;
}
stream_map = sink_map;
if (pa_modargs_get_channel_map(ma, "master_channel_map", &stream_map) < 0) {
2008-06-19 19:23:14 +02:00
pa_log("Invalid master channel map");
goto fail;
}
if (stream_map.channels != ss.channels) {
pa_log("Number of channels doesn't match");
goto fail;
}
if (pa_channel_map_equal(&stream_map, &master->channel_map))
pa_log_warn("No remapping configured, proceeding nonetheless!");
2008-06-19 19:23:14 +02:00
if (pa_modargs_get_value_boolean(ma, "remix", &remix) < 0) {
pa_log("Invalid boolean remix parameter");
goto fail;
}
if (pa_modargs_get_resample_method(ma, &resample_method) < 0) {
pa_log("Invalid resampling method");
goto fail;
}
u = pa_xnew0(struct userdata, 1);
u->module = m;
m->userdata = u;
/* Create sink */
pa_sink_new_data_init(&sink_data);
sink_data.driver = __FILE__;
sink_data.module = m;
if (!(sink_data.name = pa_xstrdup(pa_modargs_get_value(ma, "sink_name", NULL))))
sink_data.name = pa_sprintf_malloc("%s.remapped", master->name);
pa_sink_new_data_set_sample_spec(&sink_data, &ss);
pa_sink_new_data_set_channel_map(&sink_data, &sink_map);
pa_proplist_sets(sink_data.proplist, PA_PROP_DEVICE_MASTER_DEVICE, master->name);
pa_proplist_sets(sink_data.proplist, PA_PROP_DEVICE_CLASS, "filter");
if (pa_modargs_get_proplist(ma, "sink_properties", sink_data.proplist, PA_UPDATE_REPLACE) < 0) {
pa_log("Invalid properties");
pa_sink_new_data_done(&sink_data);
goto fail;
}
if ((u->auto_desc = !pa_proplist_contains(sink_data.proplist, PA_PROP_DEVICE_DESCRIPTION))) {
const char *k;
k = pa_proplist_gets(master->proplist, PA_PROP_DEVICE_DESCRIPTION);
pa_proplist_setf(sink_data.proplist, PA_PROP_DEVICE_DESCRIPTION, "Remapped %s", k ? k : master->name);
}
u->sink = pa_sink_new(m->core, &sink_data, master->flags & (PA_SINK_LATENCY|PA_SINK_DYNAMIC_LATENCY));
pa_sink_new_data_done(&sink_data);
if (!u->sink) {
pa_log("Failed to create sink.");
goto fail;
}
u->sink->parent.process_msg = sink_process_msg;
u->sink->set_state = sink_set_state;
u->sink->update_requested_latency = sink_update_requested_latency;
u->sink->request_rewind = sink_request_rewind;
u->sink->userdata = u;
pa_sink_set_asyncmsgq(u->sink, master->asyncmsgq);
/* Create sink input */
pa_sink_input_new_data_init(&sink_input_data);
sink_input_data.driver = __FILE__;
sink_input_data.module = m;
pa_sink_input_new_data_set_sink(&sink_input_data, master, false);
sink_input_data.origin_sink = u->sink;
pa_proplist_sets(sink_input_data.proplist, PA_PROP_MEDIA_NAME, "Remapped Stream");
pa_proplist_sets(sink_input_data.proplist, PA_PROP_MEDIA_ROLE, "filter");
pa_sink_input_new_data_set_sample_spec(&sink_input_data, &ss);
pa_sink_input_new_data_set_channel_map(&sink_input_data, &stream_map);
virtual sources and sinks: Don't double attach a sink input or source output on filter load When a filter is loaded and module-switch-on-connect is present, switch-on-connect will make the filter the default sink or source and move streams from the old default to the filter. This is done from the sink/source put hook, therefore streams are moved to the filter before the module init function of the filter calls sink_input_put() or source_output_put(). The move succeeds because the asyncmsq already points to the queue of the master sink or source. When the master sink or source is attached to the sink input or source output, the attach callback will call pa_{sink,source}_attach_within_thread(). These functions assume that all streams are detached. Because streams were already moved to the filter by switch-on-connect, this assumption leads to an assertion in pa_{sink_input,source_output}_attach(). This patch fixes the problem by reverting the order of the pa_{sink,source}_put() calls and the pa_{sink_input,source_output}_put calls and creating the sink input or source output corked. The initial rewind that is done for the master sink is moved to the sink message handler. The order of the unlink calls is swapped as well to prevent that the filter appears to be moving during module unload. The patch also seems to improve user experience, the move of a stream to the filter sink is now done without any audible interruption on my system. The patch is only tested for module-echo-cancel. Bug-Link: https://bugs.freedesktop.org/show_bug.cgi?id=100065
2017-05-18 07:46:46 +02:00
sink_input_data.flags = (remix ? 0 : PA_SINK_INPUT_NO_REMIX) | PA_SINK_INPUT_START_CORKED;
sink_input_data.resample_method = resample_method;
pa_sink_input_new(&u->sink_input, m->core, &sink_input_data);
pa_sink_input_new_data_done(&sink_input_data);
if (!u->sink_input)
goto fail;
u->sink_input->pop = sink_input_pop_cb;
u->sink_input->process_rewind = sink_input_process_rewind_cb;
u->sink_input->update_max_rewind = sink_input_update_max_rewind_cb;
u->sink_input->update_max_request = sink_input_update_max_request_cb;
u->sink_input->update_sink_latency_range = sink_input_update_sink_latency_range_cb;
u->sink_input->update_sink_fixed_latency = sink_input_update_sink_fixed_latency_cb;
u->sink_input->attach = sink_input_attach_cb;
u->sink_input->detach = sink_input_detach_cb;
u->sink_input->kill = sink_input_kill_cb;
u->sink_input->moving = sink_input_moving_cb;
u->sink_input->userdata = u;
u->sink->input_to_master = u->sink_input;
virtual sources and sinks: Don't double attach a sink input or source output on filter load When a filter is loaded and module-switch-on-connect is present, switch-on-connect will make the filter the default sink or source and move streams from the old default to the filter. This is done from the sink/source put hook, therefore streams are moved to the filter before the module init function of the filter calls sink_input_put() or source_output_put(). The move succeeds because the asyncmsq already points to the queue of the master sink or source. When the master sink or source is attached to the sink input or source output, the attach callback will call pa_{sink,source}_attach_within_thread(). These functions assume that all streams are detached. Because streams were already moved to the filter by switch-on-connect, this assumption leads to an assertion in pa_{sink_input,source_output}_attach(). This patch fixes the problem by reverting the order of the pa_{sink,source}_put() calls and the pa_{sink_input,source_output}_put calls and creating the sink input or source output corked. The initial rewind that is done for the master sink is moved to the sink message handler. The order of the unlink calls is swapped as well to prevent that the filter appears to be moving during module unload. The patch also seems to improve user experience, the move of a stream to the filter sink is now done without any audible interruption on my system. The patch is only tested for module-echo-cancel. Bug-Link: https://bugs.freedesktop.org/show_bug.cgi?id=100065
2017-05-18 07:46:46 +02:00
/* The order here is important. The input must be put first,
* otherwise streams might attach to the sink before the sink
* input is attached to the master. */
pa_sink_input_put(u->sink_input);
virtual sources and sinks: Don't double attach a sink input or source output on filter load When a filter is loaded and module-switch-on-connect is present, switch-on-connect will make the filter the default sink or source and move streams from the old default to the filter. This is done from the sink/source put hook, therefore streams are moved to the filter before the module init function of the filter calls sink_input_put() or source_output_put(). The move succeeds because the asyncmsq already points to the queue of the master sink or source. When the master sink or source is attached to the sink input or source output, the attach callback will call pa_{sink,source}_attach_within_thread(). These functions assume that all streams are detached. Because streams were already moved to the filter by switch-on-connect, this assumption leads to an assertion in pa_{sink_input,source_output}_attach(). This patch fixes the problem by reverting the order of the pa_{sink,source}_put() calls and the pa_{sink_input,source_output}_put calls and creating the sink input or source output corked. The initial rewind that is done for the master sink is moved to the sink message handler. The order of the unlink calls is swapped as well to prevent that the filter appears to be moving during module unload. The patch also seems to improve user experience, the move of a stream to the filter sink is now done without any audible interruption on my system. The patch is only tested for module-echo-cancel. Bug-Link: https://bugs.freedesktop.org/show_bug.cgi?id=100065
2017-05-18 07:46:46 +02:00
pa_sink_put(u->sink);
pa_sink_input_cork(u->sink_input, false);
pa_modargs_free(ma);
return 0;
fail:
if (ma)
pa_modargs_free(ma);
pa__done(m);
return -1;
}
int pa__get_n_used(pa_module *m) {
struct userdata *u;
pa_assert(m);
pa_assert_se(u = m->userdata);
return pa_sink_linked_by(u->sink);
}
void pa__done(pa_module*m) {
struct userdata *u;
pa_assert(m);
if (!(u = m->userdata))
return;
/* See comments in sink_input_kill_cb() above regarding
* destruction order! */
if (u->sink_input)
virtual sources and sinks: Don't double attach a sink input or source output on filter load When a filter is loaded and module-switch-on-connect is present, switch-on-connect will make the filter the default sink or source and move streams from the old default to the filter. This is done from the sink/source put hook, therefore streams are moved to the filter before the module init function of the filter calls sink_input_put() or source_output_put(). The move succeeds because the asyncmsq already points to the queue of the master sink or source. When the master sink or source is attached to the sink input or source output, the attach callback will call pa_{sink,source}_attach_within_thread(). These functions assume that all streams are detached. Because streams were already moved to the filter by switch-on-connect, this assumption leads to an assertion in pa_{sink_input,source_output}_attach(). This patch fixes the problem by reverting the order of the pa_{sink,source}_put() calls and the pa_{sink_input,source_output}_put calls and creating the sink input or source output corked. The initial rewind that is done for the master sink is moved to the sink message handler. The order of the unlink calls is swapped as well to prevent that the filter appears to be moving during module unload. The patch also seems to improve user experience, the move of a stream to the filter sink is now done without any audible interruption on my system. The patch is only tested for module-echo-cancel. Bug-Link: https://bugs.freedesktop.org/show_bug.cgi?id=100065
2017-05-18 07:46:46 +02:00
pa_sink_input_cork(u->sink_input, true);
if (u->sink)
pa_sink_unlink(u->sink);
virtual sources and sinks: Don't double attach a sink input or source output on filter load When a filter is loaded and module-switch-on-connect is present, switch-on-connect will make the filter the default sink or source and move streams from the old default to the filter. This is done from the sink/source put hook, therefore streams are moved to the filter before the module init function of the filter calls sink_input_put() or source_output_put(). The move succeeds because the asyncmsq already points to the queue of the master sink or source. When the master sink or source is attached to the sink input or source output, the attach callback will call pa_{sink,source}_attach_within_thread(). These functions assume that all streams are detached. Because streams were already moved to the filter by switch-on-connect, this assumption leads to an assertion in pa_{sink_input,source_output}_attach(). This patch fixes the problem by reverting the order of the pa_{sink,source}_put() calls and the pa_{sink_input,source_output}_put calls and creating the sink input or source output corked. The initial rewind that is done for the master sink is moved to the sink message handler. The order of the unlink calls is swapped as well to prevent that the filter appears to be moving during module unload. The patch also seems to improve user experience, the move of a stream to the filter sink is now done without any audible interruption on my system. The patch is only tested for module-echo-cancel. Bug-Link: https://bugs.freedesktop.org/show_bug.cgi?id=100065
2017-05-18 07:46:46 +02:00
if (u->sink_input) {
pa_sink_input_unlink(u->sink_input);
pa_sink_input_unref(u->sink_input);
virtual sources and sinks: Don't double attach a sink input or source output on filter load When a filter is loaded and module-switch-on-connect is present, switch-on-connect will make the filter the default sink or source and move streams from the old default to the filter. This is done from the sink/source put hook, therefore streams are moved to the filter before the module init function of the filter calls sink_input_put() or source_output_put(). The move succeeds because the asyncmsq already points to the queue of the master sink or source. When the master sink or source is attached to the sink input or source output, the attach callback will call pa_{sink,source}_attach_within_thread(). These functions assume that all streams are detached. Because streams were already moved to the filter by switch-on-connect, this assumption leads to an assertion in pa_{sink_input,source_output}_attach(). This patch fixes the problem by reverting the order of the pa_{sink,source}_put() calls and the pa_{sink_input,source_output}_put calls and creating the sink input or source output corked. The initial rewind that is done for the master sink is moved to the sink message handler. The order of the unlink calls is swapped as well to prevent that the filter appears to be moving during module unload. The patch also seems to improve user experience, the move of a stream to the filter sink is now done without any audible interruption on my system. The patch is only tested for module-echo-cancel. Bug-Link: https://bugs.freedesktop.org/show_bug.cgi?id=100065
2017-05-18 07:46:46 +02:00
}
if (u->sink)
pa_sink_unref(u->sink);
pa_xfree(u);
}