module-allow-passthrough has a (necessary) hack to replicate the default
sink selection and format negotiation from sink-input.c. One thing that
got missed in this replication is the possibility that the sink input is
not compatible with the default sink. When this happen, we now exit
gracefully.
Reconfiguration callback should also be set in case of avoiding resampling
option. This patch set the callback for every case because the callback
has already conditions to leave if it is not needed.
Also unnecessary codes of setting alternate sample rate to 0 are removed.
Signed-off-by: Sangchul Lee <sc11.lee@samsung.com>
This was originally planned to be done by paprefs when it starts, but
since the schema is now fully controlled by pulseaudio, it makes sense
to run the conversion from pulseaudio instead.
g_settings_get_child() returns a new GSettings object that needs to be
freed when it's not used any more. This patch collects all the childern
to a GPtrArray and frees them at the end of main(). They can't be freed
earlier, because that would prevent the "changed" signals from being
delivered.
The removed g_signal_connect() call didn't make sense. The callback
expects to be called when individual module groups are changed, not when
the top level object is changed. Also, module_group_callback() expects
user_data to be non-NULL, but here it was set to NULL.
According to the documentation of g_settings_list_children(), the listed
children may be removed at any time, so g_settings_get_child() may
return NULL. This is probably very unlikely to happen in practice, but
it's good to check anyway.
It is confusing if there's a thing named "module" which defines up to 10
modules to load. Calling the thing a "module group" instead should make
it easier to understand.
Originally the idea was to provide the "modules" schema with paprefs,
but since module-gsettings refers to the "modules" schema in its code,
that would make module-gsettings depend on paprefs, which is not good.
Now all schemas are provided by module-gsettings, so the paprefs
dependency is avoided. Unfortunately this means that if paprefs is
modified to load some new modules, the schema in pulseaudio needs to be
updated as well.
GConf is deprecated, and distributions are removing it. paprefs depends
on GConf, so in order to avoid paprefs getting removed as well, paprefs
has to be changed to use something else than GConf. GSettings is the
easiest alternative to migrate to, although it has the same problems
that GConf had: no support for system mode or networking.
This patch takes the non-GConf specific code from module-gconf and puts
it in stdin-util.[ch], which is then reused by module-gsettings.
module-gsettings is designed to be very similar to module-gconf.
Migration is expected to happen as follows: Distributions update
PulseAudio and paprefs at the same time, or first PulseAudio and then
paprefs. paprefs depends on module-gsettings, and module-gsettings
conflicts with module-gconf. Therefore module-gconf gets automatically
removed during the paprefs update. After the update an old PulseAudio is
likely to be running with module-gconf loaded. If the user tries to use
paprefs during this period, whatever the user does in paprefs won't have
any effect until PulseAudio is restarted (probably by a reboot or
relogin). This is not ideal, but will have to do.
When module-gsettings is loaded, it runs gsettings-data-convert
(implemented in a later patch). That will copy the settings from GConf
to GSettings. If gsettings-data-convert is not available (it's part of
GConf, so it may have already been uninstalled), then any previous
paprefs settings are lost.
The alsa sink calls pa_sink_suspend() from the set_port() callback.
pa_sink_suspend() can only be called from the main thread, but the
set_port() callback was often called from the IO thread. That caused an
assertion to be hit in pa_sink_suspend() when switching ports.
Another issue was that pa_sink_suspend() called the set_port() callback,
and if the callback calls pa_sink_suspend() again recursively, nothing
good can be expected from that, so the thread mismatch was not the only
problem.
This patch moves the mixer syncing logic out of pa_sink/source_suspend()
to be handled internally by the alsa sink/source. This removes the
recursive pa_sink_suspend() call. This also removes the need to have the
mixer_dirty flag in pa_sink/source, so the flag and the
pa_sink/source_set_mixer_dirty() functions can be removed.
This patch also changes the threading rules of set_port(). Previously it
was called sometimes from the main thread and sometimes from the IO
thread. Now it's always called from the main thread. When deferred
volumes are used, the alsa sink and source still have to update the
mixer from the IO thread when switching ports, but the thread
synchronization is now handled internally by the alsa sink and source.
The SET_PORT messages are not needed any more and can be removed.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=104761
The suspend cause isn't yet used by any of the callbacks. The alsa sink
and source will use it to sync the mixer when the SESSION suspend cause
is removed. Currently the syncing is done in pa_sink/source_suspend(),
and I want to change that, because pa_sink/source_suspend() shouldn't
have any alsa specific code.
There are no behaviour changes, the code from almost all the SET_STATE
handlers is moved with minimal changes to the newly introduced
set_state_in_io_thread() callback. The only exception is module-tunnel,
which has to call pa_sink_render() after pa_sink.thread_info.state has
been updated. The set_state_in_io_thread() callback is called before
updating that variable, so moving the SET_STATE handler code to the
callback isn't possible.
The purpose of this change is to make it easier to get state change
handling right in modules. Hooking to the SET_STATE messages in modules
required care in calling pa_sink/source_process_msg() at the right time
(or not calling it at all, as was the case on resume failures), and
there were a few bugs (fixed before this patch). Now the core takes care
of ordering things correctly.
Another motivation for this change is that there was some talk about
adding a suspend_cause variable to pa_sink/source.thread_info. The
variable would be updated in the core SET_STATE handler, but that would
not work with the old design, because in case of resume failures modules
didn't call the core message handler.
The previous code made the SET_STATE message fail if trigger() failed.
However, trigger() was called after pa_sink/source_process_msg(), which
meant that the main thread that sent the SET_STATE thought that resuming
failed, but nothing was undone in the IO thread, so in the IO thread
things seemed as if the sink/source was successfully resumed. (I don't
use OSS myself, so I don't know what kind of practical problems this
could cause).
Unless some complex undo logic is implemented, I believe it's best to
ignore all failures in trigger(). Most error cases were already ignored,
and the only one that wasn't ignored doesn't seem too serious.
I also moved trigger() to happen before pa_sink/source_process_msg(),
which made it necessary to add new state parameters to trigger(). The
reason for this move is that I want to move the SET_STATE handler code
into a separate callback, and if things are done both before and after
pa_sink/source_process_msg(), that makes things more complicated.
The previous code checked the return value of
pa_sink/source_process_msg() before calling trigger(), but that was
unnecessary, since pa_sink/source_process_msg() never fails when
processing the SET_STATE messages.
When resuming a sink or source, pa_sink/source_process_msg() should be
called only if resuming is successful. pa_sink/source_process_msg()
updates thread_info.state and notifies streams about the new state, but
if resuming fails, there's no state change.
pa_sink_get_state() is supposed to be used from the main thread. In this
case it doesn't really matter, because the SET_STATE handler is executed
while the main thread is waiting, but since the state is available also
in thread_info, let's use that. All other modules use thread_info.state
too, so at least this change improves consistency.
Also, we can use the PA_SINK_IS_OPENED macro to simplify the code a bit.
build_pollfd() isn't likely to fail, but if it does, pa_sink/source_put()
will crash on an assertion failure. I haven't seen such crash happening,
this is just something that I noticed while studying the state change
code.
The suspend cause isn't yet used by any of the callbacks. The alsa sink
and source will use it to sync the mixer when the SESSION suspend cause
is removed. Currently the syncing is done in pa_sink/source_suspend(),
and I want to change that, because pa_sink/source_suspend() shouldn't
have any alsa specific code.
This removes the need to hardcode the ELD device index in the path
configuration. The hardcoded values don't work with the Intel HDMI LPE
driver.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=100488
We have so far assumed that HDMI always uses device indexes 3, 7, 8, 9,
10, 11, 12 and 13. These values are hardcoded in the path configuration.
The Intel HDMI LPE driver, however, uses different device numbering
scheme. Since the indexes aren't always the same, we need to query the
hw device index from ALSA.
Later patches will use the queried index for HDMI jack detection and ELD
information reading.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=100488
When module-filter-apply tries to find a matching source-output for
a given sink-input and a stream within the same group exists on the
monitor source of the filter, module-filter apply falsely assumes
that the source belongs to another instance of the filter and tries
to access source->output_from_master->source, which leads to a
segmentation fault.
This patch fixes the issue by ignoring the stream if the source is
the monitor source of the filter.
It was reported that PulseAudio causes error messages in syslog from
dbus-daemon:
Jan 14 04:51:32 gentoo dbus-daemon[2492]: [system] Rejected send message, 2 matched rules; type="error", sender=":1.15" (uid=1000 pid=2864 comm="/usr/bin/pulseaudio --start --log-target=syslog ") interface="(unset)" member="(unset)" error name="org.bluez.MediaEndpoint1.Error.NotImplemented" requested_reply="0" destination=":1.1" (uid=0 pid=2670 comm="/usr/libexec/bluetooth/bluetoothd ")
The default policy on the system bus is to not let any method call
replies through if they have not been requested, and apparently
bluetoothd doesn't want replies to the Release() call.
This also changes the reply type from error to normal reply. The "not
implemented" error didn't make sense to me. We don't do any cleanup in
the Release() handler, probably because there's nothing to do. If there
is some cleanup that we should do, then it's a serious bug not to do it.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=104646
Allow usage of an already existing fifo (named pipe) within the
pipe-sink module. Also, the used fifo is going to be removed upon
module unload only if the fifo is created by the same module.
This is based on a patch by Rolo <rolo@wildfish.com> that replaced the
old ID with the new one. I deemed it better to leave the old ID in use
(I can't verify if the old ID was correct or not).
The original commit message:
Every time I reinstall or update Ubuntu I have to make this change
to get it to recognise my Native Instruments Traktor Audio 6
external soundcard.
Each time I remember the change by hunting down this forum post in
German,
https://forum.ubuntuusers.de/topic/traktor-audio-6-erkannt-aber-nicht-anwaehlbar/3/#post-8759808
(I don't speak German).
I'm not sure if the ID is just incorrect or if perhaps the hardware
identifies itself differently on slightly different models, so
perhaps we need to duplicate the line - I'm well outside of my
comfort zone here and I know barely anything about how hardware
works on Linux but figured if it helps me it would help others so I
should put it forward.
Thanks!
The Intel HDMI LPE driver works in a peculiar way when the HDMI cable is
not plugged in: any written audio is immediately discarded and underrun
is reported. That resulted in an infinite loop, because PulseAudio tried
to keep the buffer filled, which was futile since the written audio was
immediately consumed/discarded.
This patch adds special handling for the LPE driver: if the active port
of the sink is unavailable, the sink suspends itself. A new suspend
cause is added: PA_SUSPEND_UNAVAILABLE.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=100488
This removes the symdef header generation m4 magic in favour of a
simpler macro method, allowing us to skip one unnecessary build step
while moving to meson, and removing an 11 year old todo!
In proces(), the do_move() function calls pa_{sink_input,source_output}_set_property().
This triggers a call to {sink_input,source_output}_proplist_cb() which called process()
a second time.
This patch avoids the duplicate and nested call to process() by checking if
PA_PROP_FILTER_APPLY_MOVING is set in {sink_input,source_output}_proplist_cb().
This patch adds a sink_input_properties argument to module-ladspa-sink,
which can be helpful for customizing the appearance of the sink input in
various volume control applications, or to differentiate between
multiple instances of the module.
module-switch-on-connect would switch to any new sink, even if the sink
was a filter or a null-sink.
This patch adds a command line option ignore_virtual to the module, which
lets module-switch-on-connect ignore virtual sinks and sources. The flag
is true by default because the purpose of the module is to switch to new
hardware when it becomes available.
module-device-manager doesn't change the routing of those streams that
have been explicitly routed by the user, which is good. Similarly, it
should leave those streams alone whose routing was decided by the
application that created the stream. This patch implements that.
BugLink: https://github.com/wwmm/pulseeffects/issues/99
When a stream is created, and the stream creator specifies which device
should be used, that can affect automatic routing policies.
Specifically, module-device-manager shouldn't apply its priority list
routing when a stream has been routed by the application that created
the stream.
A stream that was initially routed by the application may be moved for
some valid reason (e.g. user requesting a move, or the original device
disappearing). When the stream is moved away from its initial device,
the "device requested by application" flag isn't relevant any more, so
it's set to false and never reset to true again.
The change in module-device-manager's routing logic will be done in the
following patch.
The filter sources should have the same max_rewind as the master source,
but these modules didn't update max_rewind when the master max_rewind
changed.
Previously max_rewind was always set to the full hw buffer size, but
the actual maximum rewind amount is limited to the part of the hw buffer
that is in use.
The rewind request that was done when lowering the sink latency had to
be moved to happen before updating max_rewind.
The practical benefit of this change: When using a filter source on a
monitor source, the filter source latency is increased by max_rewind.
Without this change the max_rewind of an alsa sink is often
unnecessarily high, which leads to unnecessarily high latency with
filter sources.
Monitor sources themselves don't suffer from the latency issue, because
they use the current sink latency instead of max_rewind for the extra
buffer that they keep to deal with rewinds.
