The previous commit introduces logic in module-switch-on-port-available
that may change a card's active profile when its availability changes to
PA_AVAILABLE_NO. To choose the new active profile, it needs a consistent
view of the new availability of all profiles, so this commit changes the
order which the ALSA driver updates all profiles' availability to ensure
the active profile is last.
This is not generic enough to cover cases were we may want to take an
action on availability changes of profiles other than the active one
that also need a consistent view of all profiles' availability. But we
don't have any callbacks implementing such action at the moment.
When a port becomes unavailble its profile may also become unavailable.
If that profile is the card's active profile, we need to switch the
card's active profile to a different one.
If we don't do that a card may get stuck on a profile without available
ports, but its sink and source will still exist, preventing
module-rescue-streams to move the streams to a different card with
available ports.
The relation between port availability and profile availability is
defined by the driver, and for the ALSA driver a profile is considered
available if there is at least one (available || unknown) port for each
direction implemented by the profile. Because of that we can only check
the profile's availability and priority when looking for the best
profile and don't need to look at port's priorities.
https://phabricator.endlessm.com/T24904
It is helpful to improve reproducibility build [1] since
PA_SRCDIR/PA_BUILDDIR contains build path,
--disable-running-from-build-tree could drop these macros at
precompilation.
[1] https://reproducible-builds.org/
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
HDMI ports are normally present on cards connected to an internal bus,
and module-switch-on-connect should switch to them when a HDMI monitor
is plugged.
This is specially relevant on setups where the HDMI port of a machine is
connected to a different audio card then the analog outputs, which is
the case for machines with AMD graphics cards.
When reviewing another change in rsa_encrypt(), Felipe Sateler pointed
out some deficiencies in error handling. This patch adds error handling
for all openssl calls in rsa_encrypt().
This patch doesn't propagate the error all the way up to the
pa_rtsp_client owner, because there's no mechanism for doing that. I
could implement such mechanism myself, but I think it's better I don't
make such complex changes to the RAOP code, because I don't have any
RAOP hardware to test the changes. The result is that module-raop-sink
will just sit around without doing anything. I think this is still
better than having no error handling at all.
Sample format(e.g. 16 bit, 24 bit) was not considered even if the
avoid-resampling option is set or the passthrough mode is used.
This patch checks both sample format and rate of a stream to
determine whether to avoid resampling in case of the option is set.
In other word, it is possble to use the stream's original sample
format and rate without resampling as long as these are supported
by the device.
pa_sink_input_update_rate() and pa_source_output_update_rate() are
renamed to pa_sink_input_update_resampler() and pa_source_output
_update_resampler() respectively.
functions are added as below.
pa_sink_set_sample_format(), pa_sink_set_sample_rate(),
pa_source_set_sample_format(), pa_source_set_sample_rate()
Signed-off-by: Sangchul Lee <sc11.lee@samsung.com>
mpv and vlc play "normal" 5.1 AC3 and DTS files as if they had a
"5.1 (Side)" layout. Which is fine and consistent with ITU
recommendations if the user has a proper 7.1 system. But if the user
actually has a 5.1 system, PulseAudio will try to remap, poorly, between
the "5.1 (Side)" and "5.1" layouts, sending either an average between
front and rear channels, or an attenuated version of that average,
depending on the remixing-use-all-sink-channels setting.
This is not desired, the "Side" channels should be sent to "Rear", it is
only an unfortunate nomenclature confusion.
This patch does not fix 5.1 <-> 7.1 remixing.
Signed-off-by: Alexander E. Patrakov <patrakov@gmail.com>
Headphones should have higher priority than lineout. Many people have
speakers always connected to lineout, and when plugging in headphones,
the audio should move to the headphones, which requires headphones
to have higher priority than lineout.
Previously this was handled by marking lineout unavailable when plugging
in headphones, but we don't do that any more.
This reverts commit 66f97c35bd. The commit
message was:
alsa-mixer: Disable line-out if headphone jack is plugged
Line-out gets muted when headphones are plugged in on HDA cards, encode
this in the line-out path so pulse can match that state.
I don't think the mentioned auto-muting happens any more by default,
and some users want to use lineout while having headphones plugged in.
Fixes: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/583
The bool was inverted for some reason - maybe because the next line
prints enable-remixing that needs to be inverted from disable_remixing,
and somehow this logic was accidentally copied to the avoid-resampling
handling.
Fixes: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/568
This adds some basic infrastructure to test passthrough support. Right
now, it just creates a passthrough stream and makes sure negotiation
works. We'll add in more tests as we go along.
This sync the meson version detection to match what we do in the
autotools build, which is to use git-version-gen, which in turn looks
for <topdir>/.tarball-version, or generates the version based on a git
tag or environment variable.
webrtc.cc:202:19: warning: comparison of integer expressions of different signedness:
'int' and 'std::vector<webrtc::CartesianPoint<float> >::size_type' {aka 'long unsigned int'}
Signed-off-by: Arnaud Rebillout <arnaud.rebillout@collabora.com>
Regarding the module:
This is unlike the autotools where liboss-util is built as a library,
here we build everything in the oss module, as apparently there's no
other consumer for liboss-util.
Regarding padsp:
Setting the install mode for padsp requires meson 0.47, so instead we
set padsp.in as executable in the git repository (which is what glib
does for gdbus-codegen btw).
Signed-off-by: Arnaud Rebillout <arnaud.rebillout@collabora.com>
Please notice that the bluez5 version seems wrong in the dependency
declaration: `>= 4.x`, while we're talking about version 5.
The ofono part will need to be made optional when we start to work on
the meson_options file.
I follow the current configure.ac to define 'HAVE_BLUEZ', but it looks
like this part would benefit from a bit of rework. Setting HAVE_BLUEZ
when we have dbus+sbc sounds weird, there's probably a better name for
this variable.
Signed-off-by: Arnaud Rebillout <arnaud.rebillout@collabora.com>
This is unlike the autotools where we check that a header exist, here we
use pkgconfig because upstream ships a pkgconfig. I don't know from
which version though...
Signed-off-by: Arnaud Rebillout <arnaud.rebillout@collabora.com>
This flag will make the loader fail if symbols are not resolved. It
seems to be our best bet to uncover every missing module dependencies.
For more details, I recommend to read:
<http://www.kaizou.org/2015/01/linux-libraries/>
Signed-off-by: Arnaud Rebillout <arnaud.rebillout@collabora.com>
