Re: [pulseaudio-discuss] Stepping down as a maintainer

[Felipe Sateler]

Hi Tanu,

On Wed, Aug 10, 2022 at 8:31 AM Tanu Kaskinen  wrote:

> Hello all!
>
> I have decided to start biotechnology studies, and some things in my
> life need to give room for that. PulseAudio work is one of those, so
> starting from 2022-08-22 I wish to drop all responsibilities implied by
> the maintainer status. How completely I will disappear from the project
> remains to be seen (I will lurk in the IRC channel at least), but given
> that lately I have already had very little time for PulseAudio, finding
> time for further contributions seems quite unlikely.
>
> It's been a long journey, and apart from my first summer job, my entire
> career in software has revolved around PulseAudio. Now is the time for
> something competely different. Thank you all for being such a pleasant
> community to work with!
>

Thank you for all the time you have contributed, and all the work you
contributed.

So long, and thanks for all the fish!
-- 

Saludos,
Felipe Sateler

Re: [pulseaudio-discuss] [ANNOUNCE] PulseAudio 14.0

[Felipe Sateler]

Hi!

On Mon, Nov 23, 2020 at 3:55 PM Arun Raghavan  wrote:

> Hi folks,
> Looks like we finally managed to get this one out, just shy of a year past
> the due date (admittedly there are some mitigating circumstances this year!)
>
> tarball:
> https://www.freedesktop.org/software/pulseaudio/releases/pulseaudio-14.0.tar.xz
> sha256
> <https://www.freedesktop.org/software/pulseaudio/releases/pulseaudio-14.0.tar.xzsha256>:
> a834775d9382b055504e5ee7625dc50768daac29329531deb6597bf05e06c261
>

\o/


>
> There's a _lot_ that went into this release, so the highlights below
> really aren't complete, and you want to see the full release notes at
> https://www.freedesktop.org/wiki/Software/PulseAudio/Notes/14.0/
>
>   * Rerouting streams when the default sink/source changes is now in the
> core
>   * Much improved UCM support, which is now used on newer Intel SOF (Sound
> Open Firmware) based devices
>   * Ports now expose their type and "availability group" for UIs to
> discover which ports are mapped to the the same physical jack (for "what
> did you plug in" UIs)
>   * New GStreamer-based RTP backend (off by default)
>

The release notes are confusing:

> The old RTP implementation is still available as a compile time option
(--disable-gstreamer with Autotools or -Dgstreamer=disabled with Meson),
but the GStreamer implementation is used by default. The GStreamer
implementation should be considered experimental for this release

1. This contradicts the above quote.
2. If it's experimental, why is it enabled by default?


-- 

Saludos,
Felipe Sateler
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH] gitlab: Add support for GitLab CI

[Felipe Sateler]

On Wed, Aug 22, 2018 at 11:36 PM Arun Raghavan 
wrote:

> This adds a Dockerfile to generate a Docker image with the required
> dependencies on top of the standard Ubuntu 18.04 image. The Gitlab CI
> then runs the PulseAudio build within this image.
> ---
>  .gitlab-ci.yml | 19 +
>  scripts/Dockerfile | 53 ++
>  2 files changed, 72 insertions(+)
>  create mode 100644 .gitlab-ci.yml
>  create mode 100644 scripts/Dockerfile
>
> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> new file mode 100644
> index 0..e9c983075
> --- /dev/null
> +++ b/.gitlab-ci.yml
> @@ -0,0 +1,19 @@
> +image: registry.freedesktop.org/pulseaudio/pulseaudio/ubuntu:18.04
> +
> +build:
> +  stage: build
> +  script:
> +- export MAKEFLAGS="-j4"
>

This seems to be inappropriate for a CI build. How do you know the
available cores in the runner? I would expect to have at most
MAKEFLAGS=$(nproc)


> +- NOCONFIGURE=1 ./bootstrap.sh
> +- mkdir build
> +- cd build
> +- ../configure --localstatedir=/var
>

I think for CI builds options should be explicitly selected, and have the
build fail if any of the expected options cannot be enabled. This may help
catch some configure.ac/Makefile.am bugs.


> +- make
> +- make check
> +- make check-daemon
> +- make distcheck
>

This effectively runs make and make check again. I think it would be better
to split this to a separate job so it can run in parallel.


> +- make install DESTDIR=`mktemp -d`
> +- make dist
> +  artifacts:
> +paths:
> +  - build/
> diff --git a/scripts/Dockerfile b/scripts/Dockerfile
> new file mode 100644
> index 0..ed7063212
> --- /dev/null
> +++ b/scripts/Dockerfile
> @@ -0,0 +1,53 @@
> +# Start with current Ubuntu LTS
> +FROM ubuntu:18.04
> +
> +# Add a PulseAudio's dependencies
> +RUN apt-get update && apt-get install -y \
> +autoconf \
> +automake \
> +autopoint \
> +bash-completion \
> +check \
> +dbus-x11 \
> +g++ \
> +gcc \
>

build-essential should get you a basic build system in place. Otherwise,
you need to add make to the list (make might stop being a transitive
dependency in the future).


> +gettext \
>

Isn't intltool necessary too?(If not I could drop that from the debian
package)


> +git-core \
> +libasound2-dev \
> +libasyncns-dev \
> +libatomic-ops-dev \
>

This is not necessary because gcc has atomic builtins.


> +libavahi-client-dev \
> +libbluetooth-dev \
> +libcap-dev \
> +libfftw3-dev \
> +libglib2.0-dev \
> +libgtk-3-dev \
> +libice-dev \
> +libjack-dev \
> +liblircclient-dev \
> +libltdl-dev \
> +liborc-0.4-dev \
> +libsbc-dev \
> +libsndfile1-dev \
> +libsoxr-dev \
> +libspeexdsp-dev \
> +libssl-dev \
> +libtdb-dev \
> +libudev-dev \
> +libwebrtc-audio-processing-dev \
> +libwrap0-dev \
> +libx11-xcb-dev \
> +libxcb1-dev \
> +libxml-parser-perl \
> +libxtst-dev \
> +systemd
>

libsystemd-dev is missing.


> +
> +# Add a user and set as default for the build. This is safer, in general,
> and
> +# allows us to avoid having to explicitly allow running as root in the
> +# check-daemon stage.
> +RUN groupadd -g 1000 a_group && \
> +useradd a_user -u 1000 -g a_group -m
>

Ubuntu has adduser that creates both user and group at the same time.


> +USER a_user:a_group
> +
> +# And make sure subsequent commands are run in the user's home directory
> +WORKDIR /home/a_user
> --
> 2.17.1
>

Saludos
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [paprefs] [PATCH] Port to meson

[Felipe Sateler]

On Mon, Jul 9, 2018 at 1:31 PM Jan Tojnar  wrote:

>
> Meson is much nicer than autotools, see
> https://wiki.gnome.org/Initiatives/GnomeGoals/MesonPorting.


> With this patch, you can invoke
>
> meson build -Ddocs=true
> ninja -C build
> sudo ninja -C build install
>
> to compile and install the package.
>

The .desktop file changes would break the autotools build, wouldn't it?. If
a port to meson is desired (I'm not a maintainer, although this gets a +1
from me), then either a workaround should be found, or autotools be dropped
at the same time.

-- 

Saludos,
Felipe Sateler
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH] udev-detect: warn when a sound card is busy

[Felipe Sateler]

On Wed, Jun 27, 2018 at 2:19 PM Tanu Kaskinen  wrote:

> Having a warning in the syslog should make it a bit easier to debug
> situations where some other program is hogging the sound card.
>

+1. Just the other day someone on IRC had this problem and debug logs were
needed.


> ---
>  src/modules/module-udev-detect.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/src/modules/module-udev-detect.c
> b/src/modules/module-udev-detect.c
> index d119f96ae..4598a3d13 100644
> --- a/src/modules/module-udev-detect.c
> +++ b/src/modules/module-udev-detect.c
> @@ -308,7 +308,9 @@ static void verify_access(struct userdata *u, struct
> device *d) {
>   * inotify and can then recheck. */
>
>  busy = is_card_busy(path_get_card_id(d->path));
> -pa_log_debug("%s is busy: %s", d->path, pa_yes_no(busy));
> +
> +if (busy)
> +pa_log_warn(_("Can't use sound card %s, because some
> other program is using it."), d->card_name);
>

I think the path info is important because it is something that one can
then pass on to lsof.


>
>  if (!busy) {
>

This should be an else, otherwise it's weird to have if (foo) {} if (!foo)
{} blocks.
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [ANNOUNCE] PulseAudio 12.0

[Felipe Sateler]

On Wed, Jun 20, 2018 at 5:25 PM Tanu Kaskinen  wrote:

> May I have your attention, please?
>
> PulseAudio 12.0 has entered our world, and it claims to be superior to
> its predecessors at least in the following ways:
>

\o/

I have uploaded to debian unstable, and activated the gsettings module. Can
we get a new paprefs release too? Or should I just package a git snapshot?

Saludos
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [ANNOUNCE] PulseAudio 11.99.1 (a.k.a. v12.0 release candidate 1)

[Felipe Sateler]

On Sun, May 13, 2018 at 10:14 AM Felipe Sateler <fsate...@debian.org> wrote:

> Hi,
>
> On Sun, May 13, 2018 at 3:10 AM Tanu Kaskinen <ta...@iki.fi> wrote:
>
>> Hi all,
>>
>> The first release candidate for PulseAudio 12.0 is now available! As
>> always, the purpose of the release candidate is to get some testing
>> done before the final version is released. So, everybody is encouraged
>> to try the new code and report back any regressions.
>>
>
> I'll be updating in debian experimental soon.
>
>
>>
>> Before upgrading, please read the "The GConf dependency can now be
>> avoided" section in the release notes! The current paprefs release
>> requires GConf, while the git version requires GSettings, and this
>> affects how PulseAudio itself should be built. The release notes
>> explain how this migration is supposed to happen.
>>
>
> What will the next version of paprefs be numbered? I want to ensure
> paprefs and pulseaudio be upgraded in lockstep, so I need to add strict
> version dependencies. Knowing the version number in advance allows me to
> set version restrictions before upgrading paprefs itself, and it allows
> preparing a paprefs git snapshot that matches the requirement.
>
>
Turns out I don't need this after all. Paprefs already has strict
dependencies via the gconf module. I'm uploading to experimental now.

-- 

Saludos,
Felipe Sateler
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [ANNOUNCE] PulseAudio 11.99.1 (a.k.a. v12.0 release candidate 1)

[Felipe Sateler]

Hi,

On Sun, May 13, 2018 at 3:10 AM Tanu Kaskinen <ta...@iki.fi> wrote:

> Hi all,
>
> The first release candidate for PulseAudio 12.0 is now available! As
> always, the purpose of the release candidate is to get some testing
> done before the final version is released. So, everybody is encouraged
> to try the new code and report back any regressions.
>

I'll be updating in debian experimental soon.


>
> Before upgrading, please read the "The GConf dependency can now be
> avoided" section in the release notes! The current paprefs release
> requires GConf, while the git version requires GSettings, and this
> affects how PulseAudio itself should be built. The release notes
> explain how this migration is supposed to happen.
>

What will the next version of paprefs be numbered? I want to ensure paprefs
and pulseaudio be upgraded in lockstep, so I need to add strict version
dependencies. Knowing the version number in advance allows me to set
version restrictions before upgrading paprefs itself, and it allows
preparing a paprefs git snapshot that matches the requirement.

-- 

Saludos,
Felipe Sateler
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH v3 04/12] gsettings: add the modules schema to the schema description file

[Felipe Sateler]

On Tue, Apr 17, 2018 at 3:07 AM, Tanu Kaskinen <ta...@iki.fi> wrote:
> 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.

I have two questions:

1. Wouldn't it be better to do the schema migration in pulseaudio
then? I find it weird that the client is responsible for doing the
migration instead if pulseaudio, if it is pulseaudio that ships the
schema.
2. If the answer to (1) is "yes", maybe it would be best to have
gsettings supersede gconf? Ie, offer the gconf module only when
gsettings will not be built.

I can't think of a usecase for having both enabled at the same time...

-- 

Saludos,
Felipe Sateler
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH] module-gsettings: new module to store configuration using gsettings

[Felipe Sateler]

On Sun, Dec 24, 2017 at 2:54 PM, Felipe Sateler <fsate...@debian.org> wrote:
> Hi,
>
> On Thu, Oct 6, 2016 at 10:18 AM, Felipe Sateler <fsate...@debian.org> wrote:
>>
>>
>> Note that the alternative to this less-than-perfect upgrade process is
>> not glitchless status quo. It is my understanding[2] that gconf will
>> eventually be forcefully removed from mainstream distros when
>> sufficiently few apps use it, so the alternative is really to drop
>> paprefs and module-gconf entirely in a (possibly far) future date.
>>
>
> This is now happening in Debian. The GNOME maintainers want to drop
> the gconf stack, and have filed bugs with severity serious[1] for
> dropping gconf libraries. Severity serious means that the affected
> packages are not suitable for release, and thus will be kicked out of
> the next debian release (or the severity lowered, of course).

Friendly ping.


There is a patch for adding a gsettings module[1], but it has not been
merged yet. It needs its companion patches to paprefs, which have not
been posted but are available on github[2]. The gsettings module had
only a few minor comments, but was not reviewed in full detail, as
higher-level migration plans were discussed.

There is also a patch for porting paprefs from GTK2 to GTK3, and in
the process move away from libglade[3]. It has not been reviewed yet.

In light of the forceful removal of these libraries from Debian, I
think it is worthwhile to revisit this issue. At least for Debian
users, the current migration plan is simply losing paprefs support.


[1] 
https://lists.freedesktop.org/archives/pulseaudio-discuss/2016-January/025275.html
[2] https://github.com/lebauce/paprefs/commits/gsettings
[3] https://patchwork.freedesktop.org/patch/194950/

-- 

Saludos,
Felipe Sateler
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH v2 4/4] bluetooth: Rename *bluez5 modules to bluetooth

[Felipe Sateler]

On Mon, Mar 19, 2018 at 5:39 AM, Luiz Augusto von Dentz <
luiz.de...@gmail.com> wrote:

> From: Luiz Augusto von Dentz 
>
> Since there is no longer support for BlueZ 4 it makes no sense to keep
> BlueZ 5 modules separated.
>
>
AFAICT, this would render invalid many configuration files as they would
refer to module-bluez5-*. Is this desirable?


___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Remaining PA process after X logout

[Felipe Sateler]

On Wed, Feb 28, 2018 at 10:53 AM, Takashi Iwai <ti...@suse.de> wrote:
> The startup of PA wasn't
> changed with the latest package on openSUSE Tumbleweed, and it means
> that it's either started by XDG autostart (by pacmd), or autospawn by
> any program.

I would encourage you to enable the systemd units if possible in
openSUSE, and disable autospawn. They have the following benefits:

1. Process environment is less random.
2. Lifetime is more controlled.
3. No more problems with running an audio-using command from a
terminal while X is open.
4. Easier to disable per-user (by masking the relevant unit on a system path).
5. Proper autorestart policy configuration


-- 

Saludos,
Felipe Sateler
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH] set exit-idle-time to 0 when we detect a session

[Felipe Sateler]

On Wed, Feb 28, 2018 at 1:16 PM, Tanu Kaskinen <ta...@iki.fi> wrote:
> As the comments explain, this fixes relogin problems on some systems
> that remove our sockets on logout without terminating the daemon.
> ---
>
> Takashi or Rex, could you test this? I haven't done any testing.
>
>  src/modules/module-console-kit.c   | 13 +
>  src/modules/module-systemd-login.c | 14 ++
>  src/modules/x11/module-x11-xsmp.c  | 13 +
>  src/pulsecore/core.c   | 10 ++
>  src/pulsecore/core.h   |  2 ++
>  5 files changed, 52 insertions(+)

The daemon.conf manpage should be updated to indicate that this
parameter is ignored if one of the session modules is loaded.


-- 

Saludos,
Felipe Sateler

On Wed, Feb 28, 2018 at 1:16 PM, Tanu Kaskinen <ta...@iki.fi> wrote:
> As the comments explain, this fixes relogin problems on some systems
> that remove our sockets on logout without terminating the daemon.
> ---
>
> Takashi or Rex, could you test this? I haven't done any testing.
>
>  src/modules/module-console-kit.c   | 13 +
>  src/modules/module-systemd-login.c | 14 ++
>  src/modules/x11/module-x11-xsmp.c  | 13 +
>  src/pulsecore/core.c   | 10 ++
>  src/pulsecore/core.h   |  2 ++
>  5 files changed, 52 insertions(+)
>
> diff --git a/src/modules/module-console-kit.c 
> b/src/modules/module-console-kit.c
> index c79388499..c8fe2ed24 100644
> --- a/src/modules/module-console-kit.c
> +++ b/src/modules/module-console-kit.c
> @@ -118,6 +118,19 @@ static void add_session(struct userdata *u, const char 
> *id) {
>
>  pa_log_debug("Added new session %s", id);
>
> +/* Positive exit_idle_time is only useful when we have no session 
> tracking
> + * capability, so we can set it to 0 now that we have detected a session.
> + * The benefit of setting exit_idle_time to 0 is that pulseaudio will 
> exit
> + * immediately when the session ends. That in turn is useful, because 
> some
> + * systems (those that use pam_systemd but don't use systemd for managing
> + * pulseaudio) clean $XDG_RUNTIME_DIR on logout, but fail to terminate 
> all
> + * services that depend on the files in $XDG_RUNTIME_DIR. The directory
> + * contains our sockets, and if the sockets are removed without 
> terminating
> + * pulseaudio, a quick relogin will likely cause trouble, because a new
> + * instance will be spawned while the old instance is still running. */
> +if (u->core->exit_idle_time > 0)
> +pa_core_set_exit_idle_time(u->core, 0);
> +
>  fail:
>
>  if (m)
> diff --git a/src/modules/module-systemd-login.c 
> b/src/modules/module-systemd-login.c
> index 879815927..51401575a 100644
> --- a/src/modules/module-systemd-login.c
> +++ b/src/modules/module-systemd-login.c
> @@ -84,6 +84,20 @@ static int add_session(struct userdata *u, const char *id) 
> {
>  pa_hashmap_put(u->sessions, session->id, session);
>
>  pa_log_debug("Added new session %s", id);
> +
> +/* Positive exit_idle_time is only useful when we have no session 
> tracking
> + * capability, so we can set it to 0 now that we have detected a session.
> + * The benefit of setting exit_idle_time to 0 is that pulseaudio will 
> exit
> + * immediately when the session ends. That in turn is useful, because 
> some
> + * systems (those that use pam_systemd but don't use systemd for managing
> + * pulseaudio) clean $XDG_RUNTIME_DIR on logout, but fail to terminate 
> all
> + * services that depend on the files in $XDG_RUNTIME_DIR. The directory
> + * contains our sockets, and if the sockets are removed without 
> terminating
> + * pulseaudio, a quick relogin will likely cause trouble, because a new
> + * instance will be spawned while the old instance is still running. */
> +if (u->core->exit_idle_time > 0)
> +pa_core_set_exit_idle_time(u->core, 0);
> +
>  return 0;
>  }
>
> diff --git a/src/modules/x11/module-x11-xsmp.c 
> b/src/modules/x11/module-x11-xsmp.c
> index 0238e5167..6f8012372 100644
> --- a/src/modules/x11/module-x11-xsmp.c
> +++ b/src/modules/x11/module-x11-xsmp.c
> @@ -206,6 +206,19 @@ int pa__init(pa_module*m) {
>  if (!u->client)
>  goto fail;
>
> +/* Positive exit_idle_time is only useful when we have no session 
> tracking
> + * capability, so we can set it to 0 now that we have detected a session.
> + * The benefit of setting exit_idle_time to 0 is that pulseaudio will 
> exit
> + * immediately when the session ends. That in turn is useful, be

[pulseaudio-discuss] [PATCH] build-sys: don't install esdcompat tool if building without esound support

[Felipe Sateler]

---
 configure.ac| 8 ++--
 man/Makefile.am | 9 +++--
 src/Makefile.am | 6 +-
 3 files changed, 18 insertions(+), 5 deletions(-)

diff --git a/configure.ac b/configure.ac
index 013918f1a..2a820b91d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1503,7 +1503,6 @@ doxygen/doxygen.conf
 src/pulse/version.h
 po/Makefile.in
 man/pulseaudio.1.xml
-man/esdcompat.1.xml
 man/pax11publish.1.xml
 man/pacat.1.xml
 man/pacmd.1.xml
@@ -1517,7 +1516,12 @@ man/pulse-cli-syntax.5.xml
 man/start-pulseaudio-x11.1.xml
 ])
 
-AC_CONFIG_FILES([src/esdcompat:src/daemon/esdcompat.in], [chmod +x 
src/esdcompat])
+AS_IF([test "x$HAVE_ESOUND" = "x1"],
+[
+AC_CONFIG_FILES([man/esdcompat.1.xml])
+AC_CONFIG_FILES([src/esdcompat:src/daemon/esdcompat.in], [chmod +x 
src/esdcompat])
+])
+
 AC_CONFIG_FILES([src/start-pulseaudio-x11:src/daemon/start-pulseaudio-x11.in], 
[chmod +x src/start-pulseaudio-x11])
 AC_CONFIG_FILES([src/client.conf:src/pulse/client.conf.in])
 AC_CONFIG_FILES([src/daemon.conf:src/daemon/daemon.conf.in],
diff --git a/man/Makefile.am b/man/Makefile.am
index d4f4edbc9..26829c632 100644
--- a/man/Makefile.am
+++ b/man/Makefile.am
@@ -18,7 +18,6 @@ DISTCLEANFILES = \
 
 noinst_DATA = \
pulseaudio.1.xml \
-   esdcompat.1.xml \
pax11publish.1.xml \
pacat.1.xml \
pacmd.1.xml \
@@ -31,6 +30,10 @@ noinst_DATA = \
pulse-cli-syntax.5.xml \
start-pulseaudio-x11.1.xml
 
+if HAVE_ESOUND
+noinst_DATA += esdcompat.1.xml
+endif
+
 xmllint: $(noinst_DATA)
for f in $(noinst_DATA) ; do \
xmllint --noout --valid "$$f" || exit 1 ; \
@@ -40,7 +43,6 @@ if BUILD_MANPAGES
 
 dist_man_MANS = \
pulseaudio.1 \
-   esdcompat.1 \
pax11publish.1 \
pacat.1 \
pacmd.1 \
@@ -53,6 +55,9 @@ dist_man_MANS = \
pulse-cli-syntax.5 \
start-pulseaudio-x11.1
 
+if HAVE_ESOUND
+dist_man_MANS += esdcompat.1
+endif
 CLEANFILES = \
$(dist_man_MANS)
 
diff --git a/src/Makefile.am b/src/Makefile.am
index d4a649c97..45616c01c 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -183,7 +183,11 @@ endif
 #   Utility programs  #
 ###
 
-bin_SCRIPTS = esdcompat
+bin_SCRIPTS =
+
+if HAVE_ESOUND
+bin_SCRIPTS += esdcompat
+endif
 
 bin_PROGRAMS += \
pacat \
-- 
2.15.1

___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] webrtc compile problem

[Felipe Sateler]

On Mon, Jan 8, 2018 at 4:06 AM, Arun Raghavan <a...@arunraghavan.net> wrote:
> Hi Per,
>
> On Mon, 8 Jan 2018, at 11:57 AM, Per Gunnarsson wrote:
>> Hello!
>>
>> I am trying to compile webrtc on FreeBSD 11.1-RELEASE-p4.
>>
>> When I try to make, I get:
>>
>> Making all in webrtc
>> Making all in .
>> Making all in base
>>CXX  libbase_la-criticalsection.lo
>> criticalsection.cc: In constructor
>> 'rtc::CriticalSection::CriticalSection()':
>> criticalsection.cc:24:23: error: 'mutex_' was not declared in this scope
>> pthread_mutex_init(_, _attribute);
>> ^~
>> criticalsection.cc: In destructor
>> 'rtc::CriticalSection::~CriticalSection()':
>> criticalsection.cc:35:26: error: 'mutex_' was not declared in this scope
>> pthread_mutex_destroy(_);
>>^~
>> criticalsection.cc: In member function 'void rtc::CriticalSection::Enter()':
>> criticalsection.cc:43:23: error: 'mutex_' was not declared in this scope
>> pthread_mutex_lock(_);
>> ^~
>> criticalsection.cc: In member function 'bool
>> rtc::CriticalSection::TryEnter()':
>> criticalsection.cc:60:30: error: 'mutex_' was not declared in this scope
>> if (pthread_mutex_trylock(_) != 0)
>>^~
>> criticalsection.cc: In member function 'void rtc::CriticalSection::Leave()':
>> criticalsection.cc:85:25: error: 'mutex_' was not declared in this scope
>> pthread_mutex_unlock(_);
>>   ^~
>> *** Error code 1
>>
>> Stop.
>> make[2]: stopped in
>> /home/per/tmp/test/webrtc-audio-processing-0.3/webrtc/base
>> *** Error code 1
>>
>> Stop.
>> make[1]: stopped in /home/per/tmp/test/webrtc-audio-processing-0.3/webrtc
>> *** Error code 1
>>
>> Stop.
>> make: stopped in /home/per/tmp/test/webrtc-audio-processing-0.3
>
> You might need to modify configure.ac to add support for FreeBSD (look at the 
> sections that define HAVE_POSIX).
>

There is a patch here that might help you get started.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829570

The submitter has unfortunately not tried to upstream it yet.

-- 

Saludos,
Felipe Sateler
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

[pulseaudio-discuss] [PATCH] Port from GTK2 to GTK3

[Felipe Sateler]

Switch from libglade to GtkBuilder, as that is the new preferred interface.
---
 configure.ac  |   2 +-
 src/paprefs.cc|   7 +-
 src/paprefs.glade | 224 ++
 3 files changed, 110 insertions(+), 123 deletions(-)

diff --git a/configure.ac b/configure.ac
index 3df69d1..85a0e53 100644
--- a/configure.ac
+++ b/configure.ac
@@ -38,7 +38,7 @@ AC_PROG_LN_S
 AC_TYPE_SIGNAL
 AC_HEADER_STDC
 
-PKG_CHECK_MODULES(GUILIBS, [ gtkmm-2.4 libglademm-2.4 sigc++-2.0 gconfmm-2.6 
dbus-glib-1])
+PKG_CHECK_MODULES(GUILIBS, [ gtkmm-3.0 sigc++-2.0 gconfmm-2.6 dbus-glib-1])
 AC_SUBST(GUILIBS_CFLAGS)
 AC_SUBST(GUILIBS_LIBS)
 
diff --git a/src/paprefs.cc b/src/paprefs.cc
index ca6d9bf..edce40c 100644
--- a/src/paprefs.cc
+++ b/src/paprefs.cc
@@ -24,7 +24,6 @@
 #include 
 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -38,7 +37,7 @@
 
 class MainWindow : public Gtk::Window {
 public:
-MainWindow(BaseObjectType* cobject, const Glib::RefPtr& 
x);
+MainWindow(BaseObjectType* cobject, const Glib::RefPtr& x);
 static MainWindow* create();
 
 Gtk::Button
@@ -127,7 +126,7 @@ public:
 upnpAvailable;
 };
 
-MainWindow::MainWindow(BaseObjectType* cobject, const 
Glib::RefPtr& x) :
+MainWindow::MainWindow(BaseObjectType* cobject, const 
Glib::RefPtr& x) :
 Gtk::Window(cobject), ignoreChanges(true) {
 
 x->get_widget("closeButton", closeButton);
@@ -200,7 +199,7 @@ MainWindow::MainWindow(BaseObjectType* cobject, const 
Glib::RefPtr x = Gnome::Glade::Xml::create(GLADE_FILE, 
"mainWindow");
+Glib::RefPtr x = Gtk::Builder::create_from_file(GLADE_FILE, 
"mainWindow");
 x->get_widget_derived("mainWindow", w);
 return w;
 }
diff --git a/src/paprefs.glade b/src/paprefs.glade
index da6b891..401e9c1 100644
--- a/src/paprefs.glade
+++ b/src/paprefs.glade
@@ -1,35 +1,35 @@
-
-
+
+
   
   
-  
+  
 False
 PulseAudio Preferences
 False
 preferences-desktop
 
-  
+  
 True
 False
 12
 12
 
-  
+  
 True
 True
 GDK_POINTER_MOTION_MASK | 
GDK_POINTER_MOTION_HINT_MASK | GDK_BUTTON_PRESS_MASK | 
GDK_BUTTON_RELEASE_MASK
 
-  
+  
 True
 False
 12
 6
 
-  
+  
 True
 False
 
-  
+  
 Make 
discoverable _PulseAudio network sound devices available locally
 True
 True
@@ -37,7 +37,7 @@
 GDK_POINTER_MOTION_MASK | 
GDK_POINTER_MOTION_HINT_MASK | GDK_BUTTON_PRESS_MASK | 
GDK_BUTTON_RELEASE_MASK
 True
 True
-  
+  
   
 False
 False
@@ -45,13 +45,13 @@
   
 
 
-  
+  
 Install...
 True
 True
 True
 none
-  
+  
   
 False
 False
@@ -59,7 +59,7 @@
 1
   
 
-  
+  
   
 False
 False
@@ -67,11 +67,11 @@
   
 
 
-  
+  
 True
 False
 
-  
+  
 Make 
discoverable Apple A_irTunes sound devices available locally
 True
 True
@@ -79,7 +79,7 @@
 GDK_POINTER_MOTION_MASK | 
GDK_POINTER_MOTION_HINT_MASK | GDK_BUTTON_PRESS_MASK | 
GDK_BUTTON_RELEASE_MASK
 True
 True
-  
+  
   
 False
 False
@@ -87,13 +87,13 @@
   
 
 
-  
+  
 Install...
 True
 True
 True
 none
-  
+  
   
 False
 False
@@ -101,7 +101,7 @@
 1
   
 
-  
+  
   
   

Re: [pulseaudio-discuss] [PATCH] module-gsettings: new module to store configuration using gsettings

[Felipe Sateler]

Hi,

On Thu, Oct 6, 2016 at 10:18 AM, Felipe Sateler <fsate...@debian.org> wrote:
>
>
> Note that the alternative to this less-than-perfect upgrade process is
> not glitchless status quo. It is my understanding[2] that gconf will
> eventually be forcefully removed from mainstream distros when
> sufficiently few apps use it, so the alternative is really to drop
> paprefs and module-gconf entirely in a (possibly far) future date.
>

This is now happening in Debian. The GNOME maintainers want to drop
the gconf stack, and have filed bugs with severity serious[1] for
dropping gconf libraries. Severity serious means that the affected
packages are not suitable for release, and thus will be kicked out of
the next debian release (or the severity lowered, of course).

Unfortunately, just moving to gsettings from gconf is not sufficient,
as the set of libraries targeted for removal includes libglade, which
paprefs also uses[2]. I will submit a patch porting paprefs to gtk 3
and gtkbuilder.

I think this patch should be revisited.

[1] https://bugs.debian.org/885038
[2] https://bugs.debian.org/885076

-- 

Saludos,
Felipe Sateler
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH] build-sys: First pass at a meson-ified build system

[Felipe Sateler]

On Tue, Dec 12, 2017 at 1:17 AM, Arun Raghavan <a...@arunraghavan.net> wrote:
>
>
> On Tue, 12 Dec 2017, at 07:29 AM, Tanu Kaskinen wrote:
>> On Sun, 2017-12-10 at 12:46 +0530, Arun Raghavan wrote:
>> > This may be a hard, but in the long run, I actually would like to remove
>> > automagic dependencies. This makes builds more consistent, and removes a
>> > lot of (imo unnecessary) if/else-ery.
>> >
>> > So we would have want_memfd on by default (maybe conditional on OS ==
>> > Linux), and then you could disable it at configure time if you don't
>> > want it.
>>
>> That kind of plan seems likely to cause unnecessary hassle for
>> people... I think enabling features automatically based on what's
>> available is a good approach.
>
> My rationale for proposing this is largely borrowed from the thinking in
> the GNOME project, and is as follows:
>
>   1. Automagic dependencies make builds unpredictable, which makes
>   distribution packaging and CI systems more fragile as they become
>   dependent on the state of the specific system being built on.

I support this as downstream packager. I want my build to fail if a
dependency is missing instead of silently turning off a feature.

>
>   1.5 I would also argue that this adds the hassle of verifying that
>   users who are building the project have a dependency when they are
>   doing their own builds.

A slightly different way to say this is that things fails fast when a
dependency is missing. So we get a rapid build failure instead of
having the build complete and then the user wonder why bluetooth
doesn't work.

>
>   2. The pain of knowing what dependencies you need is relatively easily
>   solved in documentation for the build -- we can even just provide a
>   set of commands to pull in the required dependencies on common
>   distributions to make this simpler
>
>   3. Disabling things in the build is quite simple (meson configure
>   ...), and can easily be documented.
>
> So while this proposal flies in the face of how we've always done
> things, I think the fallout can easily be mitigated with documentation,
> and the long-term wins have merit.

I would tend to agree.

-- 

Saludos,
Felipe Sateler
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH] build-sys: First pass at a meson-ified build system

[Felipe Sateler]

On Sun, Dec 10, 2017 at 4:16 AM, Arun Raghavan <a...@arunraghavan.net> wrote:
> On Sat, 9 Dec 2017, at 10:58 PM, Felipe Sateler wrote:
>> On Sat, Dec 9, 2017 at 2:59 AM, Arun Raghavan <a...@arunraghavan.net>
>> wrote:
>> > +
>> > +apiversion = '1.0'
>> > +soversion = 0
>> > +# maintaining compatibility with the previous libtool versioning
>> > +# current = minor * 100 + micro
>> > +libversion = '@0@.@1@.0'.format(soversion, pa_version_minor.to_int() * 
>> > 100 + pa_version_micro.to_int())
>>
>> This gives 0.9901.0 instead of 0.20.2
>
> Yeah, we need to fix it up to do the right thing. Let's fix this in a
> subsequent patch.

Well, then the comment should be prefixed with FIXME or removed, since
the code does not do what the comment says :)

>
> My intention is to not have this be complete, but to have it land in
> some usable state and incrementally make it better. I expect we'll be
> supporting autofoo + meson for a while until there is parity between the
> two (across platforms).

I agree that perfect is enemy of the good. Merging the meson support
as incomplete is fine.

I'm struggling to find a way to phrase this, but I think outputting a
different artifact (as opposed to a less featureful, or missing
artifact) is a bug, and not a missing feature.

>> > +
>> > +if cc.has_function('SYS_memfd_create', prefix : '#include 
>> > ')
>> > +  cdata.set('HAVE_MEMFD', 1)
>> > +endif
>>
>> configure has the option to enable or disable this. This meson script
>> autodetects only. I think the ability to explicitly disable/enable
>> (and error out if dependencies are not found) is nice to keep when
>> moving to meson. That is, this should become something like:
>>
>> want_memfd = get_option('memfd')
>> if want_memfd != 'false'
>>   has_memfd = cc.has_function('SYS_memfd_create', prefix : '#include
>> ')
>>   if has_memfd
>> cdata.set('HAVE_MEMFD', 1)
>>   elif want_memfd == 'true'
>> error('Memfd was requested but it was not found')
>>   endif
>> endif
>>
>> plus a meson_options.txt:
>>
>> option('memfd', type: 'combo', choices: ['auto', 'true', 'false'],
>>   description: 'Enable Linux memfd shared memory')
>>
>> This applies to a lot of the checks.
>
> This may be a hard, but in the long run, I actually would like to remove
> automagic dependencies. This makes builds more consistent, and removes a
> lot of (imo unnecessary) if/else-ery.

I'm not at all opposed to this. But then the basic pattern should be
in place. This way, when new features are ported from autotools to
meson, the pattern can be copied.

>
> So we would have want_memfd on by default (maybe conditional on OS ==
> Linux), and then you could disable it at configure time if you don't
> want it.

Unfortunately I don't think meson allows OS-conditional options so it
will have to be implemented as if-else too (although it is likely it
is less than autodetection).

>> > +pax11publish_sources = [
>> > +  'pax11publish.c',
>> > +]
>> > +
>> > +# FIXME: man pages
>> > +executable('pax11publish',
>> > +  pax11publish_sources,
>> > +  install: true,
>> > +  include_directories : [configinc, topinc],
>> > +  link_with : [libpulsecommon, libpulse],
>> > +  dependencies : [x11_dep],
>> > +  c_args : pa_c_args,
>> > +)
>>
>> Shouldn't this be conditional on x11_dep being found?
>
> Yes, that makes sense. I wonder if meson automatically won't build a
> target whose dep is not found.

I don't think so. Otherwise conditionally enabling features would be
very annoying:

exe_deps = [required_dep]
if optional_dep.found()
  exe_deps += [option_dep]
endif
# etc

-- 

Saludos,
Felipe Sateler
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH] build-sys: First pass at a meson-ified build system

[Felipe Sateler]

object.h',
> +  'namereg.h',
> +  'object.h',
> +  'play-memblockq.h',
> +  'play-memchunk.h',
> +  'remap.h',
> +  'resampler.h',
> +  'rtpoll.h',
> +  'sconv.h',
> +  'sconv-s16be.h',
> +  'sconv-s16le.h',
> +  'shared.h',
> +  'sink-input.h',
> +  'sink.h',
> +  'sioman.h',
> +  'sound-file-stream.h',
> +  'sound-file.h',
> +  'source-output.h',
> +  'source.h',
> +  'start-child.h',
> +  'stream-util.h',
> +  'thread-mq.h',
> +  'typedefs.h',
> +]
> +
> +if get_option('database') == 'tdb'
> +  libpulsecore_sources += 'database-tdb.c'
> +  database_c_args = '-DHAVE_TDB'
> +elif get_option('database') == 'gdbm'
> +  libpulsecore_sources += 'database-gdbm.c'
> +  database_c_args = '-DHAVE_GDBM'
> +else
> +  libpulsecore_sources += 'database-simple.c'
> +  database_c_args = '-DHAVE_SIMPLEDB'
> +endif
> +
> +if dbus_dep.found()
> +  libpulsecore_sources += [
> +'dbus-shared.c',
> +'protocol-dbus.c',
> +  ]
> +  libpulsecore_headers += [
> +'dbus-shared.h',
> +'protocol-dbus.h',
> +  ]
> +endif
> +
> +# FIXME: walk through dependencies and add files
> +
> +# FIXME: SIMD support (ORC)
> +simd = import('unstable-simd')
> +libpulsecore_simd = simd.check('libpulsecore_simd',
> +  mmx : ['remap_mmx.c', 'svolume_mmx.c'],
> +  sse : ['remap_sse.c', 'sconv_sse.c', 'svolume_sse.c'],
> +  neon : ['remap_neon.c', 'sconv_neon.c', 'svolume_neon.c'],
> +  c_args : [pa_c_args],
> +  include_directories : [configinc, topinc],
> +  implicit_include_directories : false,
> +  compiler : cc)
> +libpulsecore_simd_lib = libpulsecore_simd[0]
> +cdata.merge_from(libpulsecore_simd[1])
> +
> +# FIXME: Implement Windows support
> +#'mutex-win32.c',
> +#'poll-win32.c',
> +#'semaphore-win32.c',
> +#'thread-win32.c',
> +
> +libpulsecore = shared_library('pulsecore-' + pa_version_major_minor,
> +  libpulsecore_sources,
> +  libpulsecore_headers,
> +  include_directories : [configinc, topinc],
> +  c_args : [pa_c_args, server_c_args],
> +  install : true,
> +  link_with : libpulsecore_simd_lib,
> +  dependencies : [libm_dep, libpulsecommon_dep, libpulse_dep, ltdl_dep, 
> shm_dep, sndfile_dep, database_dep, dbus_dep, x11_dep],
> +  implicit_include_directories : false)
> +
> +libpulsecore_dep = declare_dependency(link_with: libpulsecore)
> +
> +# For modules that need protocol native functionality
> +libprotocol_native = static_library('protocol_native',
> +  'protocol-native.c',
> +  ['protocol-native.h', 'native-common.h'],
> +  c_args : [pa_c_args, server_c_args, database_c_args],
> +  include_directories : [configinc, topinc],
> +  dependencies : [libpulse_dep, libpulsecore_dep, dbus_dep],
> +  install : false
> +)

This one is shared in the autotools build.

> diff --git a/src/pulsecore/module.c b/src/pulsecore/module.c
> index 0478b6fb8..70b816072 100644
> --- a/src/pulsecore/module.c
> +++ b/src/pulsecore/module.c
> @@ -84,7 +84,11 @@ bool pa_module_exists(const char *name) {
>  state = NULL;
>  if (PA_UNLIKELY(pa_run_from_build_tree())) {
>  while ((p = pa_split(paths, ":", ))) {
> +#ifdef MESON_BUILD
> +pathname = pa_sprintf_malloc("%s" PA_PATH_SEP "src" PA_PATH_SEP 
> "modules" PA_PATH_SEP "%s" PA_SOEXT, p, n);
> +#else
>  pathname = pa_sprintf_malloc("%s" PA_PATH_SEP ".libs" 
> PA_PATH_SEP "%s" PA_SOEXT, p, n);
> +#endif
>  result = access(pathname, F_OK) == 0 ? true : false;
>  pa_log_debug("Checking for existence of '%s': %s", pathname, 
> result ? "success" : "failure");
>  pa_xfree(pathname);
> diff --git a/src/utils/meson.build b/src/utils/meson.build
> new file mode 100644
> index 0..e407d0721
> --- /dev/null
> +++ b/src/utils/meson.build
> @@ -0,0 +1,67 @@
> +pacat_sources = [
> +  'pacat.c',
> +]
> +
> +# FIXME: man pages
> +executable('pacat',
> +  pacat_sources,
> +  install: true,
> +  include_directories : [configinc, topinc],
> +  link_with : [libpulsecommon, libpulse],
> +  dependencies : [sndfile_dep],
> +  c_args : pa_c_args,
> +)
> +
> +pactl_sources = [
> +  'pactl.c',
> +]
> +
> +# FIXME: man pages
> +executable('pactl',
> +  pactl_sources,
> +  install: true,
> +  include_directories : [configinc, topinc],
> +  link_with : [libpulsecommon, libpulse],
> +  dependencies : [sndfile_dep],
> +  c_args : pa_c_args,
> +)
> +
> +pasuspender_sources = [
> +  'pasuspender.c',
> +]
> +
> +# FIXME: man pages
> +executable('pasuspender',
> +  pasuspender_sources,
> +  install: true,
> +  include_directories : [configinc, topinc],
> +  link_with : [libpulsecommon, libpulse],
> +  c_args : pa_c_args,
> +)
> +
> +pacmd_sources = [
> +  'pacmd.c',
> +]
> +
> +# FIXME: man pages
> +executable('pacmd',
> +  pacmd_sources,
> +  install: true,
> +  include_directories : [configinc, topinc],
> +  link_with : [libpulsecommon, libpulse],
> +  c_args : pa_c_args,
> +)
> +
> +pax11publish_sources = [
> +  'pax11publish.c',
> +]
> +
> +# FIXME: man pages
> +executable('pax11publish',
> +  pax11publish_sources,
> +  install: true,
> +  include_directories : [configinc, topinc],
> +  link_with : [libpulsecommon, libpulse],
> +  dependencies : [x11_dep],
> +  c_args : pa_c_args,
> +)

Shouldn't this be conditional on x11_dep being found?


-- 

Saludos,
Felipe Sateler
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

[pulseaudio-discuss] [PATCH] build-sys: test for cxx-11 after AC_USE_SYSTEM_EXTENSIONS

[Felipe Sateler]

This avoids the following autoconf warning:
configure.ac:89: warning: AC_COMPILE_IFELSE was called before 
AC_USE_SYSTEM_EXTENSIONS
../../lib/autoconf/specific.m4:368: AC_USE_SYSTEM_EXTENSIONS is expanded from...
configure.ac:89: the top level
---
 configure.ac | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index 77b5ff5d..0c38fbb5 100644
--- a/configure.ac
+++ b/configure.ac
@@ -84,9 +84,9 @@ AM_PROG_CC_C_O
 # Only required if you want the WebRTC canceller -- no runtime dep on
 # libstdc++ otherwise
 AC_PROG_CXX
-AX_CXX_COMPILE_STDCXX_11([ext],[optional])
 AC_PROG_GCC_TRADITIONAL
 AC_USE_SYSTEM_EXTENSIONS
+AX_CXX_COMPILE_STDCXX_11([ext],[optional])
 
 # M4
 
-- 
2.15.0.rc0

___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [ANNOUNCE] PulseAudio 11.1

[Felipe Sateler]

On Mon, Sep 18, 2017 at 12:37 PM, Tanu Kaskinen <ta...@iki.fi> wrote:
> Hi all,
>
> The 11.0 release had some nasty regressions, so we decided to make a
> bug fix release.

Thanks, I have just uploaded to debian.

-- 

Saludos,
Felipe Sateler
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] AppArmor profile for pulseaudio

[Felipe Sateler]

On Sun, Sep 17, 2017 at 1:06 PM, Tanu Kaskinen <ta...@iki.fi> wrote:
> On Wed, 2017-09-13 at 21:16 -0300, Felipe Sateler wrote:
>> I have been told downstream[1] that there is an AppArmor profile that
>> is worked on by people from Debian, Ubuntu and OpenSUSE. I have been
>> asked to include it in the debian package but it seems to me that this
>> benefits most if included uptream.
>>
>> Would you be accepting of patches regarding apparmor profiles? An
>> apparmor profiles is AFAICT just a file that lists certain permissions
>> that pulseaudio needs (eg, write access to /run/user/$uid/pulse). If
>> the profile is badly written, it could result in errors as pulseaudio
>> won't have permission to do what it wants. It is my understanding that
>> Ubuntu already uses this profile so it has at least some testing in
>> the wild.
>> If a user does not have AppArmor installed, the profile becomes a NOP.
>>
>> According to the submitter, the apparmor people are more than happy to
>> assist if/when problems arise due to the pulseaudio profile.
>>
>> What do you think?
>>
>> [1] https://bugs.debian.org/857798
>
> At least I'm ok with including the apparmor profile upstream.
>

OK, I'll let them know to forward the patch here.

-- 

Saludos,
Felipe Sateler
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

[pulseaudio-discuss] AppArmor profile for pulseaudio

[Felipe Sateler]

I have been told downstream[1] that there is an AppArmor profile that
is worked on by people from Debian, Ubuntu and OpenSUSE. I have been
asked to include it in the debian package but it seems to me that this
benefits most if included uptream.

Would you be accepting of patches regarding apparmor profiles? An
apparmor profiles is AFAICT just a file that lists certain permissions
that pulseaudio needs (eg, write access to /run/user/$uid/pulse). If
the profile is badly written, it could result in errors as pulseaudio
won't have permission to do what it wants. It is my understanding that
Ubuntu already uses this profile so it has at least some testing in
the wild.
If a user does not have AppArmor installed, the profile becomes a NOP.

According to the submitter, the apparmor people are more than happy to
assist if/when problems arise due to the pulseaudio profile.

What do you think?

[1] https://bugs.debian.org/857798
-- 

Saludos,
Felipe Sateler
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH] launch: avoid autostarting pulseaudio systemd units for root

[Felipe Sateler]

On Thu, Sep 7, 2017 at 9:01 AM, Tanu Kaskinen <ta...@iki.fi> wrote:

> On Wed, 2017-09-06 at 19:55 -0300, Felipe Sateler wrote:
> > The autospawn mechanism already had a root-autospawn protection
> mechanism. When
> > using systemd that was lost. Systemd 234 has a mechanism to
> conditionalize unit starting
> > on the running user, so lets do that to protect against root
> autospawning.
> > ---
> >  src/daemon/systemd/user/pulseaudio.service.in | 1 +
> >  src/daemon/systemd/user/pulseaudio.socket | 1 +
> >  2 files changed, 2 insertions(+)
> >
> > diff --git a/src/daemon/systemd/user/pulseaudio.service.in
> b/src/daemon/systemd/user/pulseaudio.service.in
> > index 2bd780f8..46897bf5 100644
> > --- a/src/daemon/systemd/user/pulseaudio.service.in
> > +++ b/src/daemon/systemd/user/pulseaudio.service.in
> > @@ -14,6 +14,7 @@ Description=Sound Service
> >  # After=pulseaudio.socket is not needed, as it is already implicit in
> the
> >  # socket-service relationship, see systemd.socket(5).
> >  Requires=pulseaudio.socket
> > +ConditionUser=!root
> >
> >  [Service]
> >  # Note that notify will only work if --daemonize=no
> > diff --git a/src/daemon/systemd/user/pulseaudio.socket
> b/src/daemon/systemd/user/pulseaudio.socket
> > index 332ece89..98c1002a 100644
> > --- a/src/daemon/systemd/user/pulseaudio.socket
> > +++ b/src/daemon/systemd/user/pulseaudio.socket
> > @@ -1,5 +1,6 @@
> >  [Unit]
> >  Description=Sound System
> > +ConditionUser=!root
> >
> >  [Socket]
> >  Priority=6
>
> What happens if these units are used with older systemd versions? Is
> the unrecognized option just ignored?
>
>
Yes. Systemd will emit a warning like this though:

systemd[23564]: [/home/felipe/.config/systemd/user/test.service:2] Unknown
lvalue 'ConditionUser' in section 'Unit'


Saludos
<https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss>
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

[pulseaudio-discuss] [PATCH] launch: avoid autostarting pulseaudio systemd units for root

[Felipe Sateler]

The autospawn mechanism already had a root-autospawn protection mechanism. When
using systemd that was lost. Systemd 234 has a mechanism to conditionalize unit 
starting
on the running user, so lets do that to protect against root autospawning.
---
 src/daemon/systemd/user/pulseaudio.service.in | 1 +
 src/daemon/systemd/user/pulseaudio.socket | 1 +
 2 files changed, 2 insertions(+)

diff --git a/src/daemon/systemd/user/pulseaudio.service.in 
b/src/daemon/systemd/user/pulseaudio.service.in
index 2bd780f8..46897bf5 100644
--- a/src/daemon/systemd/user/pulseaudio.service.in
+++ b/src/daemon/systemd/user/pulseaudio.service.in
@@ -14,6 +14,7 @@ Description=Sound Service
 # After=pulseaudio.socket is not needed, as it is already implicit in the
 # socket-service relationship, see systemd.socket(5).
 Requires=pulseaudio.socket
+ConditionUser=!root
 
 [Service]
 # Note that notify will only work if --daemonize=no
diff --git a/src/daemon/systemd/user/pulseaudio.socket 
b/src/daemon/systemd/user/pulseaudio.socket
index 332ece89..98c1002a 100644
--- a/src/daemon/systemd/user/pulseaudio.socket
+++ b/src/daemon/systemd/user/pulseaudio.socket
@@ -1,5 +1,6 @@
 [Unit]
 Description=Sound System
+ConditionUser=!root
 
 [Socket]
 Priority=6
-- 
2.14.1

___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [ANNOUNCE] PulseAudio 11.0

[Felipe Sateler]

On Tue, Sep 5, 2017 at 7:30 AM, Tanu Kaskinen <ta...@iki.fi> wrote:

> Hello, world!
>
> The release of PulseAudio 11.0 has been a long time coming, and now it
> has finally materialized!
>
>
\o/
I have uploaded to debian unstable just now. It should reach your local
mirror shortly.


-- 

Saludos,
Felipe Sateler
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH] alsa-mixer: recognize the "Speaker Jack" control

[Felipe Sateler]

On Sun, Sep 3, 2017 at 11:10 AM, Tanu Kaskinen <ta...@iki.fi> wrote:
> On Sun, 2017-09-03 at 10:26 -0300, Felipe Sateler wrote:
>> I don't know enough to review this patch, but I notice an inconsistency.
>>
>> On Sep 2, 2017 09:39, "Tanu Kaskinen" <ta...@iki.fi> wrote:
>>
>> This control has been seen in the wild:
>> https://lists.freedesktop.org/archives/pulseaudio-discuss/
>> 2017-August/028595.html
>> (The pastebin link in that mail might not work anymore, but the paste
>> just shows that there's a Speaker Jack control).
>> ---
>>  src/modules/alsa/mixer/paths/analog-output-speaker.conf | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/src/modules/alsa/mixer/paths/analog-output-speaker.conf
>> b/src/modules/alsa/mixer/paths/analog-output-speaker.conf
>> index 9f4dac414..6f9968e1f 100644
>> --- a/src/modules/alsa/mixer/paths/analog-output-speaker.conf
>> +++ b/src/modules/alsa/mixer/paths/analog-output-speaker.conf
>> @@ -56,6 +56,9 @@ state.unplugged = unknown
>>  state.plugged = no
>>  state.unplugged = unknown
>>
>> +[Jack Speaker]
>> +required-any = any
>> +
>>
>>
>> The commit message and pastebin mention Speaker Jack, not Jack Speaker.
>
> This is because the configuration file uses this format for sections:
>
> [ ]
>
> Here the section type is "Jack" and the name is "Speaker".
>
> All jack controls in alsa have "Jack" at the end of their name (that's
> how PulseAudio recognizes that they are jack controls), so in this case
> the alsa control name is "Speaker Jack". We could write [Jack Speaker
> Jack] in the configuration file, but that would be ugly.

OK. Thanks for the explanation!

-- 

Saludos,
Felipe Sateler
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [ANNOUNCE] PulseAudio 10.99.1 (a.k.a. v11.0 release candidate 1)

[Felipe Sateler]

Hi,

On Mon, Jul 24, 2017 at 8:05 PM, Tanu Kaskinen  wrote:

> Hi all,
>
> The first release candidate for PulseAudio 11.0 is now available! As
> always, the purpose of the release candidate is to get some testing
> done before the final version is released. So, everybody is encouraged
> to try the new code and report back any regressions.
>
>
I have uploaded to debian experimental, thanks!

Saludos

___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] pulseaudio seg faults when switching to bluetooth sink on RPi3

[Felipe Sateler]

On Mar 19, 2017 09:07, "John Frankish"  wrote:

Using pulseaudio-9.0 and bluez-5.43 and the RPi3 built-in bluetooth

After starting the bluetooth daemon, pairing with bluetooth headphones and
setting them as an a2dp sink, attempting to switch the audio stream to
Bluetooth results in a seg fault.

What would be the best way to troubleshoot this?


This looks like this report:
Bug#856487: pulseaudio: SIGSEGV upon streaming to bluetooth headset
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=856487

This would be a bug in libsbc when built for arm.
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] New reviewer: Georg Chini

[Felipe Sateler]

On Tue, Mar 7, 2017 at 10:09 AM, Tanu Kaskinen <ta...@iki.fi> wrote:
> Hi all,
>
> A small (or maybe big? or mid-sized?) announcement:
>
> Georg Chini kindly offered to help with reviewing patches, and we
> granted him commit rights too. This should reduce our problems with
> keeping up with the incoming patches.

\o/ This is great news!

-- 

Saludos,
Felipe Sateler
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH] systemd: disable socket activation for root

[Felipe Sateler]

On 8 February 2017 at 09:36, Tanu Kaskinen <ta...@iki.fi> wrote:
> On Fri, 2017-02-03 at 10:17 -0300, Felipe Sateler wrote:
>> On 3 February 2017 at 05:51, Tanu Kaskinen <ta...@iki.fi> wrote:
>> > We disallow autospawning for root, but when using systemd socket
>> > activation to start pulseaudio, that replaces the autospawning
>> > mechanism, and there was no similar "root protection" in socket
>> > activation. This patch disables the socket activation for root.
>> >
>> > Thanks to Felipe Sateler for coming up with the idea of using
>> > ConditionPathIsReadWrite=!/run.
>>
>> I'm sorry but I'll have to take this back. This check only checks if
>> the path is mounted read-write, not if the calling process has the
>> necessary permissions.
>>
>> https://github.com/systemd/systemd/blob/master/src/shared/condition.c#L405
>> https://github.com/systemd/systemd/blob/master/src/basic/stat-util.c#L126
>>
>> :(
>
> Well, that's disappointing (and shame on me - I should have tested the
> patch better).
>
> I think using ExecStartPre as Ahmed first suggested is the best
> solution. It should do exactly what we want. The admin capability check
> can have some corner cases where it does the wrong thing.

The ExecStartPre= solution has the undesirable side effect that it
marks the unit as failed, and thus the systemd --user session as
degraded. I think the CAP_SYS_ADMIN solution is a bit better until we
get ConditionUID. Presumably the people running containers where root
does not have CAP_SYS_ADMIN know what they are doing.

-- 

Saludos,
Felipe Sateler
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH] systemd: disable socket activation for root

[Felipe Sateler]

On 3 February 2017 at 05:51, Tanu Kaskinen <ta...@iki.fi> wrote:
> We disallow autospawning for root, but when using systemd socket
> activation to start pulseaudio, that replaces the autospawning
> mechanism, and there was no similar "root protection" in socket
> activation. This patch disables the socket activation for root.
>
> Thanks to Felipe Sateler for coming up with the idea of using
> ConditionPathIsReadWrite=!/run.

I'm sorry but I'll have to take this back. This check only checks if
the path is mounted read-write, not if the calling process has the
necessary permissions.

https://github.com/systemd/systemd/blob/master/src/shared/condition.c#L405
https://github.com/systemd/systemd/blob/master/src/basic/stat-util.c#L126

:(


-- 

Saludos,
Felipe Sateler
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] How to avoid socket activation for root?

[Felipe Sateler]

On 31 January 2017 at 10:45, Tanu Kaskinen <ta...@iki.fi> wrote:
> On Mon, 2017-01-30 at 10:17 -0300, Felipe Sateler wrote:
>> On 28 January 2017 at 11:24, Ahmed S. Darwish <darwish...@gmail.com> wrote:
>> > On Sat, Jan 28, 2017 at 04:00:31PM +0200, Ahmed S. Darwish wrote:
>> > > Unless we want a restricting directive directly inside systemd,
>> > > below trick seems to work here:
>> > >
>> > >   # /etc/systemd/user/pulseaudio.socket.d/override.conf
>> > >   [Socket]
>> > >   ExecStartPre=/bin/sh -c '/usr/bin/test $(/usr/bin/whoami) != "root"'
>> > >
>> > > Any better solution?
>> > >
>> >
>> > Below also works, and is much better than the above:
>> >
>> > # /etc/systemd/user/pulseaudio.socket.d/override.conf
>> > [Unit]
>> > ConditionCapability=!CAP_SYS_ADMIN
>>
>> One could presumably run a system without SYS_ADMIN capabilities (eg,
>> a container). Therefore, I think it is best to test for a root-owned
>> file:
>>
>>   [Unit]
>>   ConditionPathIsReadWrite=!/root
>
> AFAIK, some people use read-only root filesystem. Doesn't this break in
> such situation? Or is it common to put /root on a different read-
> write filesystem in such situations?

Hmm. Indeed, it would not start the daemon. But is pulseaudio able to
run with a read-only $HOME? The cookie and restore databases seems to
be stored in $XDG_CONFIG_DIR (which defaults to $HOME/.config).

Alternatively, one could use /run as the flag path. That path is
guaranteed by systemd to be writable, and permission (unless modified
by something weird) are 755 root:root.


> Using CAP_SYS_ADMIN seems a bit better to me, although not quite ideal.
> Maybe this should be brought up on the systemd list?

I submitted a feature request there:

https://github.com/systemd/systemd/issues/5187

-- 

Saludos,
Felipe Sateler
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] How to avoid socket activation for root?

[Felipe Sateler]

On 28 January 2017 at 11:24, Ahmed S. Darwish <darwish...@gmail.com> wrote:
> On Sat, Jan 28, 2017 at 04:00:31PM +0200, Ahmed S. Darwish wrote:
>> Hi :-)
>>
>> On Sat, Jan 28, 2017 at 01:58:32PM +0200, Tanu Kaskinen wrote:
>> > Hi all,
>> >
>> > In the "PA 10 : paplay can't connect !" thread I noticed worrying
>> > netstat output:
>> >
>> > [video@sixcore ~]$ netstat -l -x -p | grep pulse
>> > (Not all processes could be identified, non-owned process info
>> >   will not be shown, you would have to be root to see it all.)
>> > unix  2  [ ACC ] STREAM LISTENING 512377388/pulseaudio 
>> >  /tmp/.esd-501/socket
>> > unix  2  [ ACC ] STREAM LISTENING 26773-   
>> >  /run/user/0/pulse/native
>> > unix  2  [ ACC ] STREAM LISTENING 409387362/systemd
>> >  /run/user/501/pulse/native
>> >
>> > It looks like systemd manages also root login sessions, and it creates
>> > the pulseaudio socket for root. Presumably pulseaudio would get started
>> > if some application tried to access the socket. When using the
>> > traditional autospawning mechanism, we don't start pulseaudio for root,
>> > and that's how it should be also in the systemd socket activation case.
>> >
>> > Does anyone have ideas about how we could prevent systemd from creating
>> > the socket for root by default?
>> >
>>
>> Confirmed here too, as long as a root login shell is there; e.g.
>> by something like "machinectl shell".
>>
>> Unless we want a restricting directive directly inside systemd,
>> below trick seems to work here:
>>
>>   # /etc/systemd/user/pulseaudio.socket.d/override.conf
>>   [Socket]
>>   ExecStartPre=/bin/sh -c '/usr/bin/test $(/usr/bin/whoami) != "root"'
>>
>> Any better solution?
>>
>
> Below also works, and is much better than the above:
>
> # /etc/systemd/user/pulseaudio.socket.d/override.conf
> [Unit]
> ConditionCapability=!CAP_SYS_ADMIN

One could presumably run a system without SYS_ADMIN capabilities (eg,
a container). Therefore, I think it is best to test for a root-owned
file:

  [Unit]
  ConditionPathIsReadWrite=!/root


-- 

Saludos,
Felipe Sateler
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [ANNOUNCE] PulseAudio 10.0

[Felipe Sateler]

On 18 January 2017 at 21:49, Tanu Kaskinen <ta...@iki.fi> wrote:
> Dear Sir/Madam,
>
> I'm pleased to inform you that the version 10.0 of PulseAudio is now
> officially ready for your consumption.

I have uploaded this to debian unstable. If all is well, it should
migrate to stretch within 10 days. Just in time, as the freeze is on
February 5th :)

-- 

Saludos,
Felipe Sateler
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Test failure on musl libc and slower builders (thread-test timeout)

[Felipe Sateler]

On Jan 17, 2017 00:09, "A. Wilcox"  wrote:


The second failure is that after I resolved the above issue (even just
calling srand with '2' to avoid spinning too long), our PowerPC
builder - a dual 1.8GHz 970fx - timed out.  Running it outside of
'make check' allows me to see it completes somewhere between 84 and 89
iterations before the timeout hits.  I found a thread from 2014 on
this list discussing that very issue for Debian's packaging[2], but
saw no answer as to how to prolong the timeout.  For now, I'm going to
ship the package on PowerPC with the failure since all other tests
pass.  I would however be very grateful to integrate a more permanent
solution so that the test suite may pass.


On debian I have disabled the timeouts, since the builders have their own
timeout. I also set the runtime dir environment variable so that the build
does not write to the users home directory.

http://sources.debian.net/src/pulseaudio/9.0-5/debian/rules/#L14
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] First draft of 10.0 release notes completed

[Felipe Sateler]

On 10 January 2017 at 21:00, Tanu Kaskinen <ta...@iki.fi> wrote:
> I can reset your wiki password if you tell me your username. Or if you
> don't remember the username either, I can create "FelipeSateler".

My username is fsateler. If you could reset the password that would be great.

Thanks!

-- 

Saludos,
Felipe Sateler
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] First draft of 10.0 release notes completed

[Felipe Sateler]

On 8 January 2017 at 17:05, Tanu Kaskinen <ta...@iki.fi> wrote:
> Hi all,
>
> The first draft of the 10.0 release notes is now complete:
> https://www.freedesktop.org/wiki/Software/PulseAudio/Notes/10.0/
>
> If you think something should be added or removed or changed, please
> reply to this mail or just edit the wiki.

I have forgotten my credentials for the wiki so I can't edit this
directly. I'd just add an "always" to the systemd service item, as the
key change is not the ordering, but the requirement:

When using systemd to start PulseAudio, pulseaudio.socket is always
started first

-- 

Saludos,
Felipe Sateler
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [ANNOUNCE] PulseAudio 9.99.1 (a.k.a. v10.0 release candidate 1)

[Felipe Sateler]

On 3 January 2017 at 13:29, Tanu Kaskinen <ta...@iki.fi> wrote:
>
> Hi all!
>
> The first release candidate for PulseAudio 10.0 is now out. As always,
> the purpose of the release candidate is to get some testing done before
> the final version is released. So, please test this on your own
> machine, and if you're a distro maintainer and you have some suitable
> channel for prereleases, push this also to poor unsuspecting users and
> report back what kind of regressions they find!

I have uploaded the RC to debian experimental, so it should make it
easier to install/test on debian-based distros. It built on all
release architectures[1]

The hard freeze for the next debian release is on Jan 25th. I'm still
undecided on whether to push for 10 (or an RC) for stretch, I guess we
can see for a week or so if reports pop up.

[1] https://buildd.debian.org/status/package.php?p=pulseaudio=experimental

-- 

Saludos,
Felipe Sateler
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH] remove module-xenpv-sink

[Felipe Sateler]

On 5 December 2016 at 17:20, Tanu Kaskinen <ta...@iki.fi> wrote:
> The module doesn't build any more[1], and when starting to investigate
> the build failure, I asked the module author if he'd know something
> about the breakage. He said that he didn't know about backward
> compatibility problems with libxen, but more importantly, he said that
> the module probably doesn't have any users[2]. It doesn't make sense to
> keep maintaining a module that doesn't have users, so let's drop it.

If there are such users, they are not from debian or ubuntu, as this
module disabled in both distros. Therefore no complaints from our
side.

Fedora also appears to have this disabled[1].

[1] 
https://kojipkgs.fedoraproject.org//packages/pulseaudio/9.0/1.fc25/data/logs/x86_64/build.log

-- 

Saludos,
Felipe Sateler
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH] Add env vars for PA_ALSA_PATHS_DIR and PA_ALSA_PROFILE_SETS_DIR

[Felipe Sateler]

On 25 November 2016 at 07:28, Albert Astals Cid
<albert.ast...@canonical.com> wrote:
> On Thu, Nov 24, 2016 at 9:51 PM, Tanu Kaskinen <ta...@iki.fi> wrote:
>> On Wed, 2016-11-23 at 17:10 +0100, Albert Astals Cid wrote:
>>> Helps making pulseaudio relocatable
>>
>> Could you provide more information in the commit message about what use
>> case requires pulseaudio to be relocatable?
>
> In this particular case is making pulseaudio part of a snap file [1]

Isn't it possible to have bind mounts specified in a snap file?
Alternatively, can't --datadir be specified at configure time? I don't
know much about snap, but I hope apps can expect some sort of
filesystem layout... So, I think it is worth considering if adding a
configure option (if one is missing) instead of runtime detection
might be better.

-- 

Saludos,
Felipe Sateler
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

[pulseaudio-discuss] [PATCH] padsp: allow overriding library install location

[Felipe Sateler]

The current build script hardcodes the $pkglibdir in the padsp command.
This works and is a reasonable default. However, distributions that
know where they install, can override this path and thus make padsp
work for any architecture that has the library installed by using the
following configure argument:

   --with-pulsedsp-location='/usr/\\$$LIB/pulseaudio'

This works because ld.so considers $LIB a variable that will expand to
several location paths, depending on the architecture of the binary
being executed.

In debian, for example, this would work for libpulsedsp.so installed in
/usr/lib/x86_64-linux-gnu/ for amd64 and /usr/lib/i386-linux-gnu/ for
i386, with a single padsp command.

---

The idea is that pulseaudio-utils package can provide the padsp command, and
the dsp wrapper for multiple architecture can be co-installed. Then the loader
does the job of picking which library to use according to the running program's
architecture.

---
 configure.ac   | 8 
 src/Makefile.am| 2 +-
 src/utils/padsp.in | 4 ++--
 3 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/configure.ac b/configure.ac
index 809e705..3e473fd 100644
--- a/configure.ac
+++ b/configure.ac
@@ -759,6 +759,9 @@ AC_ARG_ENABLE([oss-output],
 AC_ARG_ENABLE([oss-wrapper],
 AS_HELP_STRING([--disable-oss-wrapper],[Disable optional OSS wrapper 
support]))
 
+AC_ARG_WITH([pulsedsp-location],
+AS_HELP_STRING([--with-pulsedsp-location],[Specify location where OSS 
wrapper will be installed]))
+
 AS_IF([test "x$enable_oss_output" != "xno" -o "x$enable_oss_wrapper" != "xno"],
 [AC_CHECK_HEADERS([sys/soundcard.h], HAVE_OSS=1, HAVE_OSS=0)],
 HAVE_OSS=0)
@@ -774,7 +777,12 @@ AS_IF([test "x$enable_oss_wrapper" != "xno"],
 [AS_IF([test "x$HAVE_OSS" = "x1"], HAVE_OSS_WRAPPER=1, 
HAVE_OSS_WRAPPER=0)],
 HAVE_OSS_WRAPPER=0)
 
+AS_IF([test "x$with_pulsedsp_location" != "x"],
+[PULSEDSP_LOCATION="$with_pulsedsp_location"],
+[PULSEDSP_LOCATION="\$(pkglibdir)"])
+
 AC_SUBST(HAVE_OSS_OUTPUT)
+AC_SUBST(PULSEDSP_LOCATION)
 AM_CONDITIONAL([HAVE_OSS_OUTPUT], [test "x$HAVE_OSS_OUTPUT" = "x1"])
 AM_CONDITIONAL([HAVE_OSS_WRAPPER], [test "x$HAVE_OSS_WRAPPER" = "x1"])
 AS_IF([test "x$HAVE_OSS_OUTPUT" = "x1"], AC_DEFINE([HAVE_OSS_OUTPUT], 1, [Have 
OSS output?]))
diff --git a/src/Makefile.am b/src/Makefile.am
index 2d5bdd4..ca702c1 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -922,7 +922,7 @@ padsplib_LTLIBRARIES = libpulsedsp.la
 bin_SCRIPTS += padsp
 
 edit = @SED@ \
-   -e "s|@pkglibdir[@]|$(pkglibdir)|g"
+   -e 's|@PULSEDSP_LOCATION[@]|$(PULSEDSP_LOCATION)|g'
 
 padsp: utils/padsp.in
$(edit) $< > $@
diff --git a/src/utils/padsp.in b/src/utils/padsp.in
index 3430a65..fea00d2 100644
--- a/src/utils/padsp.in
+++ b/src/utils/padsp.in
@@ -74,9 +74,9 @@ done
 shift $(( $OPTIND - 1 ))
 
 if [ x"$LD_PRELOAD" = x ] ; then
-   LD_PRELOAD="@pkglibdir@/libpulsedsp.so"
+   LD_PRELOAD="@PULSEDSP_LOCATION@/libpulsedsp.so"
 else
-   LD_PRELOAD="$LD_PRELOAD @pkglibdir@/libpulsedsp.so"
+   LD_PRELOAD="$LD_PRELOAD @PULSEDSP_LOCATION@/libpulsedsp.so"
 fi
 
 export LD_PRELOAD
-- 
2.10.2

___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH v3 2/2] raop: add error handling to rsa_encrypt()

[Felipe Sateler]

On 4 November 2016 at 09:43, Tanu Kaskinen <ta...@iki.fi> wrote:
> While making another change in rsa_encrypt(), I noticed that it had no
> error handling. I decided to add some.
>
> 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.
> ---
>  src/modules/raop/raop_client.c | 60 
> +++---
>  1 file changed, 57 insertions(+), 3 deletions(-)
>
> diff --git a/src/modules/raop/raop_client.c b/src/modules/raop/raop_client.c
> index 864c558..32cd316 100644
> --- a/src/modules/raop/raop_client.c
> +++ b/src/modules/raop/raop_client.c
> @@ -176,19 +176,64 @@ static int rsa_encrypt(uint8_t *text, int len, uint8_t 
> *res) {
>  uint8_t exponent[8];
>  int size;
>  RSA *rsa;
> -BIGNUM *n_bn;
> -BIGNUM *e_bn;
> +BIGNUM *n_bn = NULL;
> +BIGNUM *e_bn = NULL;
> +int r;
>
>  rsa = RSA_new();
> +if (!rsa) {
> +pa_log("RSA_new() failed.");
> +goto fail;
> +}
> +
>  size = pa_base64_decode(n, modules);
> +
>  n_bn = BN_bin2bn(modules, size, NULL);
> +if (!n_bn) {
> +pa_log("BN_bin2bn() failed.");

I think this should note which instance of BN_bin2n failed? The
documentation does not mention why can bin2bn fail, other than memory
allocations. If there are other reasons, it probably will be useful to
know which call was that failed.

> +goto fail;
> +}
> +
>  size = pa_base64_decode(e, exponent);
> +
>  e_bn = BN_bin2bn(exponent, size, NULL);
> -RSA_set0_key(rsa, n_bn, e_bn, NULL);
> +if (!e_bn) {
> +pa_log("BN_bin2bn() failed.");
> +goto fail;
> +}
> +
> +r = RSA_set0_key(rsa, n_bn, e_bn, NULL);
> +if (r == 0) {

This seems to be the only use of r. I see elsewhere that usages of the form:

if (!some_func()) {
// log or do something
goto fail;
}

Is there a convention about this?

> +pa_log("RSA_set0_key() failed.");
> +goto fail;
> +}
> +
> +/* The memory allocated for n_bn and e_bn is now managed by the RSA 
> object.
> + * Let's set n_bn and e_bn to NULL to avoid freeing the memory in the 
> error
> + * handling code. */
> +n_bn = NULL;
> +e_bn = NULL;
>
>  size = RSA_public_encrypt(len, text, res, rsa, RSA_PKCS1_OAEP_PADDING);
> +if (size == -1) {
> +pa_log("RSA_public_encrypt() failed.");
> +goto fail;

Other than the log, this seems redundant. goto fail will do the same
as not doing goto fail.

> +}
> +
>  RSA_free(rsa);
>  return size;
> +
> +fail:
> +if (e_bn)
> +BN_free(e_bn);
> +
> +if (n_bn)
> +BN_free(n_bn);
> +
> +if (rsa)
> +RSA_free(rsa);
> +
> +return -1;
>  }
>
>  static int aes_encrypt(pa_raop_client* c, uint8_t *data, int size) {
> @@ -270,6 +315,15 @@ static void rtsp_cb(pa_rtsp_client *rtsp, pa_rtsp_state 
> state, pa_headerlist* he
>
>  /* Now encrypt our aes_public key to send to the device */
>  i = rsa_encrypt(c->aes_key, AES_CHUNKSIZE, rsakey);
> +if (i < 0) {
> +pa_log("rsa_encrypt() failed.");
> +pa_rtsp_disconnect(rtsp);
> +/* FIXME: This is an unrecoverable failure. We should notify
> + * the pa_raop_client owner so that it could shut itself
> + * down. */
> +return;
> +}
> +
>  pa_base64_encode(rsakey, i, );
>  rtrimchar(key, '=');
>  pa_base64_encode(c->aes_iv, AES_CHUNKSIZE, );
> --
> 2.10.1
>
> ___
> pulseaudio-discuss mailing list
> pulseaudio-discuss@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss



-- 

Saludos,
Felipe Sateler
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH v3 1/2] raop: add compatibility with openssl 1.1.0

[Felipe Sateler]

This preserves the logic as it was prior to openssl 1.1, so lgtm.

On 4 November 2016 at 09:43, Tanu Kaskinen <ta...@iki.fi> wrote:
> Openssl 1.1.0 made all structs opaque, which caused a build failure in
> raop_client.c. The struct member assignments are now replaced with a
> call to RSA_set0_key().
>
> BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=96726
> ---
>
> Changes in v3:
>  * Removed the assertion around RSA_set0_key(). The following patch will do
>proper error handling.
>
>  src/modules/raop/raop_client.c | 22 --
>  1 file changed, 20 insertions(+), 2 deletions(-)
>
> diff --git a/src/modules/raop/raop_client.c b/src/modules/raop/raop_client.c
> index 3b6c36e..864c558 100644
> --- a/src/modules/raop/raop_client.c
> +++ b/src/modules/raop/raop_client.c
> @@ -68,6 +68,21 @@
>
>  #define RAOP_PORT 5000
>
> +/* Openssl 1.1.0 broke compatibility. Before 1.1.0 we had to set RSA->n and
> + * RSA->e manually, but after 1.1.0 the RSA struct is opaque and we have to 
> use
> + * RSA_set0_key(). RSA_set0_key() is a new function added in 1.1.0. We could
> + * depend on openssl 1.1.0, but it may take some time before distributions 
> will
> + * be able to upgrade to the new openssl version. To insulate ourselves from
> + * such transition problems, let's implement RSA_set0_key() ourselves if it's
> + * not available. */
> +#if OPENSSL_VERSION_NUMBER < 0x1010L
> +static int RSA_set0_key(RSA *r, BIGNUM *n, BIGNUM *e, BIGNUM *d) {
> +r->n = n;
> +r->e = e;
> +return 1;
> +}
> +#endif
> +
>  struct pa_raop_client {
>  pa_core *core;
>  char *host;
> @@ -161,12 +176,15 @@ static int rsa_encrypt(uint8_t *text, int len, uint8_t 
> *res) {
>  uint8_t exponent[8];
>  int size;
>  RSA *rsa;
> +BIGNUM *n_bn;
> +BIGNUM *e_bn;
>
>  rsa = RSA_new();
>  size = pa_base64_decode(n, modules);
> -rsa->n = BN_bin2bn(modules, size, NULL);
> +n_bn = BN_bin2bn(modules, size, NULL);
>  size = pa_base64_decode(e, exponent);
> -rsa->e = BN_bin2bn(exponent, size, NULL);
> +e_bn = BN_bin2bn(exponent, size, NULL);
> +RSA_set0_key(rsa, n_bn, e_bn, NULL);
>
>  size = RSA_public_encrypt(len, text, res, rsa, RSA_PKCS1_OAEP_PADDING);
>  RSA_free(rsa);
> --
> 2.10.1
>
> ___
> pulseaudio-discuss mailing list
> pulseaudio-discuss@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss



-- 

Saludos,
Felipe Sateler
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Thinking about pulseaudio for debian stretch

[Felipe Sateler]

On 3 November 2016 at 10:41, Tanu Kaskinen <ta...@iki.fi> wrote:
> On Thu, 2016-11-03 at 10:03 -0300, Felipe Sateler wrote:
>> Hi,
>>
>> The release of debian stretch is getting closer so I'm starting to
>> plan for it. Currently we are shipping 9.0. The question would be if I
>> should try to get 10 into stretch, or just stay with 9.
>>
>> Currently, the freeze is planned for february 5th, with a
>> no-new-packages policy since january. How are things looking to have
>> at least an RC during this year?
>>
>> I suppose shipping stretch with pa 10.0~rcN + some cherry-picked fixes
>> (if required) is not that crazy.
>
> I'd estimate that we'll have RC1 out within a few weeks and final
> release ready well in time for the Debian freeze. No promises, of
> course.

Excellent. Having the first RC within november/early december makes me
think having version 10 (or at least a late RC + cherry-picked fixes)
will be the best choice.

-- 

Saludos,
Felipe Sateler
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

[pulseaudio-discuss] Thinking about pulseaudio for debian stretch

[Felipe Sateler]

Hi,

The release of debian stretch is getting closer so I'm starting to
plan for it. Currently we are shipping 9.0. The question would be if I
should try to get 10 into stretch, or just stay with 9.

Currently, the freeze is planned for february 5th, with a
no-new-packages policy since january. How are things looking to have
at least an RC during this year?

I suppose shipping stretch with pa 10.0~rcN + some cherry-picked fixes
(if required) is not that crazy.

-- 

Saludos,
Felipe Sateler
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH v2] raop: add compatibility with openssl 1.1.0

[Felipe Sateler]

On 3 November 2016 at 09:30, Tanu Kaskinen <ta...@iki.fi> wrote:
> Openssl 1.1.0 made all structs opaque, which caused a build failure in
> raop_client.c. The struct member assignments are now replaced with a
> call to RSA_set0_key().
>
> BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=96726
> ---
>
> Changes in v2:
>  * More verbose comment.
>  * Implement RSA_set0_key() as a function instead of a macro.
>  * Use pa_assert_se() instead of pa_assert().
>
> As before, I have tested that the code compiles against old and new openssl
> versions, but I have not tested that the code works.
>
>  src/modules/raop/raop_client.c | 22 --
>  1 file changed, 20 insertions(+), 2 deletions(-)
>
> diff --git a/src/modules/raop/raop_client.c b/src/modules/raop/raop_client.c
> index 3b6c36e..7a7bb8a 100644
> --- a/src/modules/raop/raop_client.c
> +++ b/src/modules/raop/raop_client.c
> @@ -68,6 +68,21 @@
>
>  #define RAOP_PORT 5000
>
> +/* Openssl 1.1.0 broke compatibility. Before 1.1.0 we had to set RSA->n and
> + * RSA->e manually, but after 1.1.0 the RSA struct is opaque and we have to 
> use
> + * RSA_set0_key(). RSA_set0_key() is a new function added in 1.1.0. We could
> + * depend on openssl 1.1.0, but it may take some time before distributions 
> will
> + * be able to upgrade to the new openssl version. To insulate ourselves from
> + * such transition problems, let's implement RSA_set0_key() ourselves if it's
> + * not available. */
> +#if OPENSSL_VERSION_NUMBER < 0x1010L
> +static int RSA_set0_key(RSA *r, BIGNUM *n, BIGNUM *e, BIGNUM *d) {
> +r->n = n;
> +r->e = e;
> +return 1;


I'm sorry I did not point this out before. I've looked at the
documentation of BN_bin2bn, and it can return NULL in case of failure.
The real version of RSA_set0_key will return 0 if passed NULL 'n' and
'e', thus failing the assert. I'm not sure failing to 'BN_bin2bn' is a
recoverable error so I don't think that it is bad that the assertion
will fail. This new method does not fail the assert, even when it
couldn't correctly set the key.

This code was buggy before this change, so maybe this code could go
as-is and fix this later (either by adding checks, or requiring a
new-enough openssl).

BTW, I'm probably going to have to backport this fix to debian, as
there is a push to ship 1.1 for stretch.

-- 

Saludos,
Felipe Sateler
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH] raop: add compatibility with openssl 1.1.0

[Felipe Sateler]

On 10 September 2016 at 10:39, Tanu Kaskinen <ta...@iki.fi> wrote:
> Openssl 1.1.0 made all structs opaque, which caused a build failure in
> raop_client.c. The struct member assignments are now replaced with a
> call to RSA_set0_key(). The function does not exist in older versions,
> so a compatibility macro was added.
>
> BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=96726
> ---
>
> I have tested that this builds with old and new openssl, but I have not
> tested that the code works. I don't have any RAOP hardware.

I cannot test either. AFAICT, the compat looks good:

1. The macro does roughly the same as the real function[1], except for
freeing the previous values and some checks that don't apply here.
2. RSA_new appears to initialize n, e and d to zero., thus the freeing
is not necessary.

Therefore I conclude the part for compat with 1.1.0 is good.

I do have some comments below though.

[1] 
https://github.com/openssl/openssl/blob/OpenSSL_1_1_0/crypto/rsa/rsa_lib.c#L188-L212
Don't look for copying code here, as the license is not GPL-compatible AFAIK.

>
>
>  src/modules/raop/raop_client.c | 15 +--
>  1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/src/modules/raop/raop_client.c b/src/modules/raop/raop_client.c
> index 3b6c36e..88de62c 100644
> --- a/src/modules/raop/raop_client.c
> +++ b/src/modules/raop/raop_client.c
> @@ -68,6 +68,14 @@
>
>  #define RAOP_PORT 5000
>
> +/* Openssl 1.1.0 broke compatibility. We could depend on openssl 1.1.0, but
> + * it may take some time before distributions are able to upgrade to the new
> + * openssl version. To insulate ourselves from such transition problems, 
> let's
> + * add a compatibility macro. */
> +#if OPENSSL_VERSION_NUMBER < 0x1010L
> +#define RSA_set0_key(r, n_, e_, d) (r->n = n_, r->e = e_, 1)

While as noted this appears to do the right thing, why not make it a
real function instead? This should make it nicer for debuggers too.

> +#endif
> +
>  struct pa_raop_client {
>  pa_core *core;
>  char *host;
> @@ -161,12 +169,15 @@ static int rsa_encrypt(uint8_t *text, int len, uint8_t 
> *res) {
>  uint8_t exponent[8];
>  int size;
>  RSA *rsa;
> +BIGNUM *n_bn;
> +BIGNUM *e_bn;
>
>  rsa = RSA_new();
>  size = pa_base64_decode(n, modules);
> -rsa->n = BN_bin2bn(modules, size, NULL);
> +n_bn = BN_bin2bn(modules, size, NULL);
>  size = pa_base64_decode(e, exponent);
> -rsa->e = BN_bin2bn(exponent, size, NULL);
> +e_bn = BN_bin2bn(exponent, size, NULL);
> +pa_assert(RSA_set0_key(rsa, n_bn, e_bn, NULL) == 1);

Shouldn't this be pa_assert_se?

>
>  size = RSA_public_encrypt(len, text, res, rsa, RSA_PKCS1_OAEP_PADDING);
>  RSA_free(rsa);

-- 

Saludos,
Felipe Sateler
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Make pulseaudio the default alsa device

[Felipe Sateler]

On 21 October 2016 at 10:22, Tanu Kaskinen <ta...@iki.fi> wrote:
>
> On Tue, 2016-10-18 at 09:59 -0300, Felipe Sateler wrote:
> > On 18 October 2016 at 06:50, Tanu Kaskinen <ta...@iki.fi> wrote:
> > > If the system is configured to use pulseaudio, then I would prefer alsa
> > > applications to fail if pulseaudio isn't running, rather than falling
> > > back to whatever the default is if pulse-alsa.conf isn't loaded. It
> > > makes debugging easier.
> >
> >
> > I'm not sure if it makes sense to ask if "the system is configured to
> > use pulseaudio", because individual users on a system might
> > disable/enable it.
>
> Wouldn't per-user configuration be better suited for ~/.asoundrc? Now
> you're assuming that if pulseaudio isn't available for whatever reason,
> the user doesn't want to use pulseaudio. That's not always correct, but
> it might be correct often enough that it makes sense for you to do that
> instead of requiring users to modify ~/.asoundrc.

Because pulseaudio defaults to autospawn, if the daemon can't be
reached then for most users the current heuristic means either:

1. Pulseaudio has been manually disabled via `autospawn = no`.
2. Pulseaudio is seriously malfunctioning and can't start.

In either case I don't think it makes much sense to set the alsa
default device to pulseaudio.

>
> One alternative would be to create a program/script for
> disabling/enabling pulseaudio (which is nowadays annoyingly
> distribution specific, so a unifying script would be welcome even for
> this reason alone), which would also (optionally) set up the default
> device in ~/.asoundrc. That way there would be just one step for users
> to toggle between pulseaudio and plain alsa.

Does alsa support ~/.asoundrc.d or equivalent? Otherwise the script
would get hairy very fast.

>
> > > But if the Debian alsa maintainers prefer to
> > > fall back to non-pulseaudio configuration even when pulseaudio is
> > > installed, then it seems reasonable to propose this to alsa upstream.
> >
> >
> > This file is being shipped by pulseaudio, not alsa.
>
> (By "pulseaudio" you obviously mean the Debian package, not the
> upstream project.)

Yes, sorry if that confused anyone.

> Ok, so shipping this in pulseaudio upstream would be more convenient
> for Debian.

Yes :). Alternatively, I'm also happy to use an upstream-sanctioned
way to achieve the same. What I really want is for the debian package
to diverge as little as possible from upstream, but without degrading
user experience, of course.

> However, alsa-plugins already has a file that sets
> pulseaudio as the default device, and e.g. OpenEmbedded ships the
> configuration in alsa-plugins-pulseaudio-conf, which is a binary
> package generated from the alsa-plugins source.

This is an interesting approach. Debian package pulseaudio could
Recommends: alsa-plugins-pulseaudio-conf (this means install by
default, but allow uninstalling). The only problem I see is how to
disable per-user (via .asoundrc?). I have gotten requests to be able
to disable per-application, because some specific apps malfunction
with the pulse virtual device.

> Having two different but similar-in-purpose alsa configuration files in
> two upstream projects doesn't seem sensible, so either the existing
> file in alsa-plugins should be moved to pulseaudio, or you should try
> to upstream your configuration file to alsa-plugins.

Yes, the current situation is fairly confusing. To add to the
confusion, the debian pulseaudio package ships a copy of the
alsa-plugins configuration file :/

> I don't think
> either option is clearly better than the other (but as the OpenEmbedded
> alsa and pulseaudio maintainer I'd obviously prefer shipping the files
> in alsa-plugins, since that would be less work for me).

I think it makes sense that all alsa-pulse glue should belong in one package.

-- 

Saludos,
Felipe Sateler
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Make pulseaudio the default alsa device

[Felipe Sateler]

On 18 October 2016 at 06:50, Tanu Kaskinen <ta...@iki.fi> wrote:
> On Fri, 2016-10-14 at 14:49 -0300, Felipe Sateler wrote:
>> On 14 October 2016 at 13:12, Felipe Sateler <fsate...@debian.org> wrote:
>> > On 14 October 2016 at 12:13, Tanu Kaskinen <ta...@iki.fi> wrote:
>> > > The relevant configuration snippet is already shipped in alsa-plugins
>> > > upstream. The file in the source tree is
>> > >
>> > > pulse/99-pulseaudio-default.conf.example
>> > >
>> > > and it gets installed to
>> > >
>> > > $datadir/alsa/alsa.conf.d/99-pulseaudio-default.conf.example
>> >
>> > Yes, but that is not enabled by default. In debian we use the
>> > following file to load that config automatically:
>> >
>> > https://sources.debian.net/src/pulseaudio/9.0-4/debian/pulse.conf/
>>
>> I realized that link may die in the future, so I'm copying the contents:
>>
>> # PulseAudio alsa plugin configuration file to set the pulseaudio plugin as
>> # default output for applications using alsa when pulseaudio is running.
>> hook_func.pulse_load_if_running {
>> lib "libasound_module_conf_pulse.so"
>> func "conf_pulse_hook_load_if_running"
>> }
>>
>> @hooks [
>> {
>> func pulse_load_if_running
>> files [
>> "/usr/share/alsa/pulse-alsa.conf"
>> ]
>> errors false
>> }
>> ]
>
> If the system is configured to use pulseaudio, then I would prefer alsa
> applications to fail if pulseaudio isn't running, rather than falling
> back to whatever the default is if pulse-alsa.conf isn't loaded. It
> makes debugging easier.

I'm not sure if it makes sense to ask if "the system is configured to
use pulseaudio", because individual users on a system might
disable/enable it.

> But if the Debian alsa maintainers prefer to
> fall back to non-pulseaudio configuration even when pulseaudio is
> installed, then it seems reasonable to propose this to alsa upstream.

This file is being shipped by pulseaudio, not alsa.

> Maybe it could be an alternate "example" side-by-side with the current
> pulseaudio-default.conf.example. Distributions could then easily choose
> between the two approaches.

I'd like to avoid having to force users into doing stuff as root to
disable/enable this. The current solution achieves this by simply
disabling autospawn in the user config. A file that is loaded
unconditionally must be removed by the user.

> As a sidenote, I think it would be good to add much more commenting to
> that file. The alsa configuration syntax is very hard to understand, so
> it would be good to explain pretty much everything that is happening in
> that file, line by line. I understand what the file does in general,
> but I can't confidently explain almost any of the individual lines.

Neither do I, FWIW. This file is part of the pulseaudio debian package
since before I got involved, and I have never touched it yet, mostly
for that reason[1].


[1] There is a request to be able to disable the pulse default via an envvar.

-- 

Saludos,
Felipe Sateler
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Make pulseaudio the default alsa device (Was: LADSPA Per Channel\Audio Woes)

[Felipe Sateler]

On 14 October 2016 at 13:12, Felipe Sateler <fsate...@debian.org> wrote:
> On 14 October 2016 at 12:13, Tanu Kaskinen <ta...@iki.fi> wrote:
>> On Fri, 2016-10-14 at 11:48 -0300, Felipe Sateler wrote:
>>> On 14 October 2016 at 11:44, Tanu Kaskinen <ta...@iki.fi> wrote:
>>> > The stock configuration of Ubuntu will set
>>> > pulseaudio as the default device for alsa applications, and that's the
>>> > way things should be.
>>>
>>> Would it make sense to upstream this bit? This should be fairly
>>> similar across linux distros, no?
>>
>> The relevant configuration snippet is already shipped in alsa-plugins
>> upstream. The file in the source tree is
>>
>> pulse/99-pulseaudio-default.conf.example
>>
>> and it gets installed to
>>
>> $datadir/alsa/alsa.conf.d/99-pulseaudio-default.conf.example
>
>
>
> Yes, but that is not enabled by default. In debian we use the
> following file to load that config automatically:
>
> https://sources.debian.net/src/pulseaudio/9.0-4/debian/pulse.conf/

I realized that link may die in the future, so I'm copying the contents:

# PulseAudio alsa plugin configuration file to set the pulseaudio plugin as
# default output for applications using alsa when pulseaudio is running.
hook_func.pulse_load_if_running {
lib "libasound_module_conf_pulse.so"
func "conf_pulse_hook_load_if_running"
}

@hooks [
{
func pulse_load_if_running
files [
"/usr/share/alsa/pulse-alsa.conf"
]
errors false
}
]

-- 

Saludos,
Felipe Sateler
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Make pulseaudio the default alsa device (Was: LADSPA Per Channel\Audio Woes)

[Felipe Sateler]

On 14 October 2016 at 12:13, Tanu Kaskinen <ta...@iki.fi> wrote:
> On Fri, 2016-10-14 at 11:48 -0300, Felipe Sateler wrote:
>> On 14 October 2016 at 11:44, Tanu Kaskinen <ta...@iki.fi> wrote:
>> > The stock configuration of Ubuntu will set
>> > pulseaudio as the default device for alsa applications, and that's the
>> > way things should be.
>>
>> Would it make sense to upstream this bit? This should be fairly
>> similar across linux distros, no?
>
> The relevant configuration snippet is already shipped in alsa-plugins
> upstream. The file in the source tree is
>
> pulse/99-pulseaudio-default.conf.example
>
> and it gets installed to
>
> $datadir/alsa/alsa.conf.d/99-pulseaudio-default.conf.example



Yes, but that is not enabled by default. In debian we use the
following file to load that config automatically:

https://sources.debian.net/src/pulseaudio/9.0-4/debian/pulse.conf/

-- 

Saludos,
Felipe Sateler
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Service File for running in system mode

[Felipe Sateler]

On 6 October 2016 at 14:56, Florian Lindner <mailingli...@xgm.de> wrote:
>
>>> Ok, so you mean adding a .socket file to that. I will try this later...
>>
>> Please also add a Requires=pulseaudio.socket to the service file so
>> that it is always started (see the current user unit in git master)
>
> I will, as soon as I add the socket file. I'm not really sure, isn't
> that either the socket or the service file should be enabled, not both?

Well, the Requires is merely to force the socket to always be active
when the daemon is started. Otherwise if you start the daemon on its
own and then you start the socket, it will fail. And there is not much
benefit to not enabling the socket.

>
>>>
>>> Do you have any idea what could be the problem with having the default
>>> sink muted always? (see my other mail in this thread).
>>
>> This is a shot in the dark, but you may be racing with alsa-restore or
>> alsa-state. Maybe you should add `After=alsa-state.service
>> alsa-restore.service`? (On second thought, this sounds like a good idea 
>> anyway)
>
> Mhh, I don't have any service files like alsa*.
>
> Could it be because the $HOME of user pulse is /var/run/pulse which is
> emptied at each boot? I don't really think so, so only files there are a
> "native" socket file and "pid".
>
> In /var/lib/pulse/ are the state files:
>
> 0a95f82340cb4818a15b1fabc2ca2001-card-database.tdb
> 0a95f82340cb4818a15b1fabc2ca2001-default-sink
> 0a95f82340cb4818a15b1fabc2ca2001-default-source
> 0a95f82340cb4818a15b1fabc2ca2001-device-volumes.tdb
> 0a95f82340cb4818a15b1fabc2ca2001-stream-volumes.tdb
>
> Any more ideas?

No, sorry. A verbose log might have give clues.

-- 

Saludos,
Felipe Sateler
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH] module-gsettings: new module to store configuration using gsettings

[Felipe Sateler]

On 6 October 2016 at 08:28, Tanu Kaskinen <ta...@iki.fi> wrote:
> On Wed, 2016-10-05 at 12:14 -0300, Felipe Sateler wrote:
>> On 5 October 2016 at 05:17, Sylvain Baubeau <leba...@gmail.com> wrote:
>> >
>> >
>> >
>> > 2016-10-04 13:04 GMT+02:00 Tanu Kaskinen <ta...@iki.fi>:
>> > >
>> > >
>> > > On Fri, 2016-09-30 at 23:21 +0200, Sylvain Baubeau wrote:
>> > > > Thanks for pointing this out. I updated my paprefs patch to apply
>> > > > paprefs.convert at startup.
>> > >
>> > > Would it be feasible for you to make it a build time option to use
>> > > gconf or gsettings in paprefs?
>> >
>> >
>> > Yes, I think it's feasible but the code would need quite a lot of rework.
>>
>> I don't think this is necessary.
>
> If it's not configurable, that will force the gsettings transition on
> all distros. But I think I agree that it's good enough if the data gets
> moved on the first run of the new paprefs version, even if paprefs
> won't necessarily work before pulseaudio gets restarted.

Distros can do the transition on their own pace by delaying the
paprefs update. Paprefs is AFAICS a mature piece of software, it is
not getting new releases frequently anyway. Delaying a couple of
months the release would not be terrible I think.

>
>> > > > > However that leaves us with another problem, as the pulseaudio daemon
>> > > > > is not restarted automatically after an upgrade, and thus gsettings
>> > > > > module might not be loaded. But, I hope paprefs can already deal with
>> > > > > such a scenario and prompt the user accordingly.
>> > > > >
>> > > >
>> > > > Unfortunately, paprefs does not deal with such a scenario. It will
>> > > > therefore be able to modify the configuration but this configuration
>> > > > will
>> > > > only take effect when pulseaudio is restarted. What do you suggest
>> > > > prompting the user with ?
>> > >
>> > > Figuring out a good message is tricky. paprefs could just say "module-
>> > > gsettings not loaded", but it would be nice to able to tell the user
>> > > what to do. However, module-gsettings not being loaded may be because
>> > > the server is too old version and doesn't support module-gsettings at
>> > > all (distributions can deal this by depending on new enough server,
>> > > though), or it has been removed from default.pa and needs to be added
>> > > there, or the server has been updated but not restarted. The last
>> > > reason is the most likely one in the beginning, but over time it
>> > > becomes less and less likely, so just saying "restart pulseaudio" or
>> > > "reboot the machine" probably isn't a good idea.
>> > >
>> > > >
>> > > > >
>> > > > > In debian there is only paprefs depending on module-gconf. I don't
>> > > > > think we'll keep module-gconf after paprefs has migrated.
>> > >
>> > > If we release a pulseaudio version with module-gsettings before we
>> > > release paprefs with gsettings support, will you run pulseaudio with
>> > > both gconf and gsettings enabled, or only with gconf? Running with both
>> > > would have the benefit that if everything goes well, the data will be
>> > > migrated without any glitch when the new paprefs version is run for the
>> > > first time, because module-gsettings will be already loaded. The risk
>> > > with that is that the migration can't be tested at the time you enable
>> > > module-gsettings, since paprefs isn't ready. If there's some unforeseen
>> > > problem when paprefs is finally updated, and module-gsettings needs to
>> > > be fixed in some way, the migration might become even more complex,
>> > > because you need to deal with detecting a situation where the server is
>> > > running with a broken version of module-gsettings.
>> > >
>> >
>> > You're right, it's probably too complicated. It's better to stick with
>> > GConf.
>>
>> FWIW, I'd rather face a one-time upgrade glitch[1] than be stuck
>> forever with an unmaintained stack. So I don't agree that it is better
>> to stick with GConf.
>>
>> From my POV, making paprefs do the migration automatically is all that
>> is missing to perform an upgrade that is as seamless as possible.
>
> (I'm not sure

Re: [pulseaudio-discuss] Service File for running in system mode

[Felipe Sateler]

On 5 October 2016 at 13:44, Florian Lindner <mailingli...@xgm.de> wrote:
> Hey,
>
> thanks for your input!
>
> Am 04.10.2016 um 22:02 schrieb Felipe Sateler:
>> On 4 October 2016 at 14:42, Florian Lindner <mailingli...@xgm.de> wrote:
>>> Hey,
>>>
>>> ok, my working configuration on Arch with pulseaudio 9.0.
>>>
>>> The unit file:
>>>
>>> # /etc/systemd/system/pulseaudio.service
>>> [Unit]
>>> Description=PulseAudio system server
>>> After=dbus.socket
>>
>> This is redundant, as services by default have an implicit
>> After=sockets.target (via basic.target).
>>
>>> Wants=dbus.socket
>>
>> This is also questionable, as strictly speaking the dbus socket is not
>> needed by pulseaudio. If the system has dbus disabled, pulseaudio
>> should not pull it in.
>>
>>>
>>> [Service]
>>> Type=notify
>>> ExecStart=/usr/bin/pulseaudio --daemonize=no --system --realtime
>>> --disallow-module-loading --disallow-exit --log-target=journal
>>>
>>> [Install]
>>> WantedBy=sound.target
>
> Ok, I have removed Wants and After.
>
>> I think it may be a good idea to also enable the socket activation
>> (like the user units do).
>
> Ok, so you mean adding a .socket file to that. I will try this later...

Please also add a Requires=pulseaudio.socket to the service file so
that it is always started (see the current user unit in git master)

>
> Do you have any idea what could be the problem with having the default
> sink muted always? (see my other mail in this thread).

This is a shot in the dark, but you may be racing with alsa-restore or
alsa-state. Maybe you should add `After=alsa-state.service
alsa-restore.service`? (On second thought, this sounds like a good idea anyway)

-- 

Saludos,
Felipe Sateler
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH] module-gsettings: new module to store configuration using gsettings

[Felipe Sateler]

On 5 October 2016 at 05:17, Sylvain Baubeau <leba...@gmail.com> wrote:
>
>
> 2016-10-04 13:04 GMT+02:00 Tanu Kaskinen <ta...@iki.fi>:
>>
>> On Fri, 2016-09-30 at 23:21 +0200, Sylvain Baubeau wrote:
>> > 2016-09-27 21:32 GMT+02:00 Felipe Sateler <fsate...@debian.org>:
>> > > I have to say I'm not sure how an upgrade scenario would play out. My
>> > > understanding currently is as follows:
>> > >
>> > > 1. paprefs can ship a file for gsettings-data-convert, which migrates
>> > > the settings.
>> > >
>> > > 2. However that tool is only run at login.
>> > >
>> > > 3. As a consequence, the paprefs tool can be in an inconsistent state
>> > > after an upgrade and before the next login.
>> > >
>> > > It seems that the problem is resolved by papfrefs triggering the tool
>> > > on startup as suggested by the gnome documentation[1].
>> > >
>> >
>> > Thanks for pointing this out. I updated my paprefs patch to apply
>> > paprefs.convert at startup.
>>
>> Would it be feasible for you to make it a build time option to use
>> gconf or gsettings in paprefs?
>
>
> Yes, I think it's feasible but the code would need quite a lot of rework.

I don't think this is necessary.

>>
>> > > However that leaves us with another problem, as the pulseaudio daemon
>> > > is not restarted automatically after an upgrade, and thus gsettings
>> > > module might not be loaded. But, I hope paprefs can already deal with
>> > > such a scenario and prompt the user accordingly.
>> > >
>> >
>> > Unfortunately, paprefs does not deal with such a scenario. It will
>> > therefore be able to modify the configuration but this configuration
>> > will
>> > only take effect when pulseaudio is restarted. What do you suggest
>> > prompting the user with ?
>>
>> Figuring out a good message is tricky. paprefs could just say "module-
>> gsettings not loaded", but it would be nice to able to tell the user
>> what to do. However, module-gsettings not being loaded may be because
>> the server is too old version and doesn't support module-gsettings at
>> all (distributions can deal this by depending on new enough server,
>> though), or it has been removed from default.pa and needs to be added
>> there, or the server has been updated but not restarted. The last
>> reason is the most likely one in the beginning, but over time it
>> becomes less and less likely, so just saying "restart pulseaudio" or
>> "reboot the machine" probably isn't a good idea.
>>
>> > > In debian there is only paprefs depending on module-gconf. I don't
>> > > think we'll keep module-gconf after paprefs has migrated.
>>
>> If we release a pulseaudio version with module-gsettings before we
>> release paprefs with gsettings support, will you run pulseaudio with
>> both gconf and gsettings enabled, or only with gconf? Running with both
>> would have the benefit that if everything goes well, the data will be
>> migrated without any glitch when the new paprefs version is run for the
>> first time, because module-gsettings will be already loaded. The risk
>> with that is that the migration can't be tested at the time you enable
>> module-gsettings, since paprefs isn't ready. If there's some unforeseen
>> problem when paprefs is finally updated, and module-gsettings needs to
>> be fixed in some way, the migration might become even more complex,
>> because you need to deal with detecting a situation where the server is
>> running with a broken version of module-gsettings.
>>
>
> You're right, it's probably too complicated. It's better to stick with
> GConf.

FWIW, I'd rather face a one-time upgrade glitch[1] than be stuck
forever with an unmaintained stack. So I don't agree that it is better
to stick with GConf.

From my POV, making paprefs do the migration automatically is all that
is missing to perform an upgrade that is as seamless as possible.
Restarting user (as opposed to system) daemons is a problem that is
not solved in general, and I don't expect to solve it now. It just
happens to be a fact of life that during some upgrades a logout-login
is required (especially on the complex desktop environments). If the
module is introduced before the updated papfref is shipped, the window
for such a glitchy upgrade lowers considerably.

[1] With my downstream maintainer hat on, package dependencies can be
tightened sufficiently so that this happens only once.

-- 

Saludos,
Felipe Sateler
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Service File for running in system mode

[Felipe Sateler]

On 4 October 2016 at 14:42, Florian Lindner <mailingli...@xgm.de> wrote:
> Hey,
>
> ok, my working configuration on Arch with pulseaudio 9.0.
>
> The unit file:
>
> # /etc/systemd/system/pulseaudio.service
> [Unit]
> Description=PulseAudio system server
> After=dbus.socket

This is redundant, as services by default have an implicit
After=sockets.target (via basic.target).

> Wants=dbus.socket

This is also questionable, as strictly speaking the dbus socket is not
needed by pulseaudio. If the system has dbus disabled, pulseaudio
should not pull it in.

>
> [Service]
> Type=notify
> ExecStart=/usr/bin/pulseaudio --daemonize=no --system --realtime
> --disallow-module-loading --disallow-exit --log-target=journal
>
> [Install]
> WantedBy=sound.target

I think it may be a good idea to also enable the socket activation
(like the user units do).

-- 

Saludos,
Felipe Sateler
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH] module-gsettings: new module to store configuration using gsettings

[Felipe Sateler]

On 26 September 2016 at 06:27, Tanu Kaskinen <ta...@iki.fi> wrote:
> On Wed, 2016-09-21 at 13:04 +0200, Sylvain Baubeau wrote:
>> Hello,
>>
>> First of all, I do not work for Fedora. I happen to use it, that's about
>> it. Please don't blame Fedora for my less-than-perfect patch.
>
> Ok, thanks for the clarification.
>
>> I did the paprefs patch to make the upgrade process easier but it seems it
>> makes it harder so I suggest we forget about the paprefs migration to
>> gsettings and stick to gconf.
>>
>> In this case, I don't really see a problem with the upgrade :
>> By default, module-gsettings is disabled and module-gconf stays enabled and
>> nothing will change if the distribution maintainer does nothing.
>>
>> If a distribution wants to move to gsettings, it could do so during a major
>> upgrade of the distro (that would probably update Gnome, the kernel and
>> would require a session restart). They could decide to enable both modules
>> - so that old programs keep working and new ones could use the new module -
>> or switch completely to gsettings, after they make sure all programs
>> packaged by the distribution have a migration script.
>
> (A sidenote: paprefs is (at least I hope so) the only application that
> uses this stuff, so we don't need to worry about others.)
>
> It would be nice to have thoughts from actual package maintaners about
> this.

I have to say I'm not sure how an upgrade scenario would play out. My
understanding currently is as follows:

1. paprefs can ship a file for gsettings-data-convert, which migrates
the settings.
2. However that tool is only run at login.
3. As a consequence, the paprefs tool can be in an inconsistent state
after an upgrade and before the next login.

It seems that the problem is resolved by papfrefs triggering the tool
on startup as suggested by the gnome documentation[1].

However that leaves us with another problem, as the pulseaudio daemon
is not restarted automatically after an upgrade, and thus gsettings
module might not be loaded. But, I hope paprefs can already deal with
such a scenario and prompt the user accordingly.

In debian there is only paprefs depending on module-gconf. I don't
think we'll keep module-gconf after paprefs has migrated.

[1] 
https://www.freedesktop.org/software/gstreamer-sdk/data/docs/latest/gio/ch29s07.html

-- 

Saludos,
Felipe Sateler
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

[pulseaudio-discuss] [PATCH 2/2] build-sys: bump minor gettext version to 0.18.2

[Felipe Sateler]

This avoids a warning in the intl.m4 macro:
configure.ac:106: warning: The 'AM_PROG_MKDIR_P' macro is deprecated, and its 
use is discouraged.
configure.ac:106: You should use the Autoconf-provided 'AC_PROG_MKDIR_P' macro 
instead,
configure.ac:106: and use '' instead of ''in your Makefile.am files.
---
 configure.ac | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

0.18.2 is not available in the following (old) distros, I don't know about OSX 
or Windows:

- Debian Wheezy (but available via backports)
- Ubuntu Precise
- Centos/RHEL 6

diff --git a/configure.ac b/configure.ac
index db5b3dc..cffeed6 100644
--- a/configure.ac
+++ b/configure.ac
@@ -102,7 +102,7 @@ PKG_PROG_PKG_CONFIG
 if test "x$enable_nls" != "xno"; then
 IT_PROG_INTLTOOL([0.35.0])
 
-AM_GNU_GETTEXT_VERSION([0.18.1])
+AM_GNU_GETTEXT_VERSION([0.18.2])
 AM_GNU_GETTEXT([external])
 
 GETTEXT_PACKAGE=pulseaudio
-- 
2.9.3

___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

[pulseaudio-discuss] [PATCH 1/2] build-sys: use AC_USE_SYSTEM_EXCEPTIONS before trying to compile anything

[Felipe Sateler]

This silences a warning:
configure.ac:89: warning: AC_COMPILE_IFELSE was called before 
AC_USE_SYSTEM_EXTENSIONS
---
 configure.ac | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index 1bcdda6..db5b3dc 100644
--- a/configure.ac
+++ b/configure.ac
@@ -84,9 +84,9 @@ AM_PROG_CC_C_O
 # Only required if you want the WebRTC canceller -- no runtime dep on
 # libstdc++ otherwise
 AC_PROG_CXX
+AC_USE_SYSTEM_EXTENSIONS
 AX_CXX_COMPILE_STDCXX_11([ext],[optional])
 AC_PROG_GCC_TRADITIONAL
-AC_USE_SYSTEM_EXTENSIONS
 
 # M4
 
-- 
2.9.3

___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] 98766: Bug and bounty to improve HDMI handling in PA

[Felipe Sateler]

On 19 September 2016 at 15:00, Manuel Amador (Rudd-O) <rud...@rudd-o.com> wrote:

> I believe that there's a good compromise to be made:
>
> 1. if PulseAudio ('s D-Bus session) is tied to a GUI session in X11 or
> Wayland,

It appears the world is moving towards per-user daemons from the
per-session model. This means this part may not be valid. However, a
different solution might be to use the logind api[1] to determine if
there is any graphical session by the current user attached to the
seat corresponding to the hdmi device (this can be obtained via the
ID_SEAT udev property, or seat0 as fallback).

[1] https://www.freedesktop.org/wiki/Software/systemd/logind/

-- 

Saludos,
Felipe Sateler
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH 0/5] Fix the conflict between bluetooth-policy and card-restore

[Felipe Sateler]

On 4 August 2016 at 13:49, Pali Rohár <pali.ro...@gmail.com> wrote:
> On Thursday 04 August 2016 19:35:57 Tanu Kaskinen wrote:
>> This may very well cause a regression for BlueZ 4, because I didn't
>> make the corresponding changes there. The code isn't identical with
>> BlueZ 5, and it would be a bit difficult for me to test with BlueZ 4.
>> What do others think - should I nevertheless try to install BlueZ 4
>> and update the BlueZ 4 code too, or can we let the BlueZ 4 code just
>> rot?
>
> I have only Bluez 4, so please do not drop Bluez 4 code. If you to do
> testing code for Bluez 4 setup, I can do that.

Out of curiosity, what distro is this? From what I can look at, only
SourceMage still has bluez 4, and both Debian and Ubuntu moved to
bluez 5 in their latest (LTS) release.

From what I know, the pulseaudio maintainers use Debian, Fedora and
Gentoo (I may be wrong though). As all of these distros have moved to
bluez 5, I think it is kind of inevitable that bluez 4 code will
bitrot.

-- 

Saludos,
Felipe Sateler
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH] bluetooth: When doing autoswitch call pa_card_set_profile with save=true

[Felipe Sateler]

On 4 August 2016 at 06:59, Tanu Kaskinen <ta...@iki.fi> wrote:
> it doesn't make sense for module-card-restore to switch to a profile
> when an alsa profile becomes available due to the user plugging
> something in.

Why doesn't it makes sense? I think it makes a lot of sense. One of
the things I miss from KDE is its capability to restore streams back
to HDMI when the cable is plugged, or when a bluetooth speaker becomes
available.

-- 

Saludos,
Felipe Sateler
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

[pulseaudio-discuss] [PATCH] launch: make pulseaudio.service properly order and require the socket

[Felipe Sateler]

This commit fixes two problems:

1. Because there are no implicit dependencies between sockets and services,
   the socket, as set up by systemd will race with the socket, as set up
   by the pulseaudio daemon. This can cause the pulseaudio.socket unit to
   fail (even though the pulseaudio service started just fine), which can
   confuse users.
2. While it is possible to use the service without the socket, it is not
   clear why it would be desirable. And a user installing pulseaudio and
   doing `systemctl --user start pulseaudio` will not get the socket
   started, which might be confusing and problematic if the server is to
   be restarted later on, as the client autospawn feature might kick in.
---
 src/daemon/systemd/user/pulseaudio.service.in | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/daemon/systemd/user/pulseaudio.service.in 
b/src/daemon/systemd/user/pulseaudio.service.in
index df42fc3..0bd2a91 100644
--- a/src/daemon/systemd/user/pulseaudio.service.in
+++ b/src/daemon/systemd/user/pulseaudio.service.in
@@ -1,5 +1,7 @@
 [Unit]
 Description=Sound Service
+Requires=pulseaudio.socket
+After=pulseaudio.socket
 
 [Service]
 # Note that notify will only work if --daemonize=no
-- 
2.8.1

___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] webrtc: build failures on i386

[Felipe Sateler]

On 27 May 2016 at 00:04, Arun Raghavan <a...@arunraghavan.net> wrote:
> Hey Felipe,
>
> On Thu, 26 May 2016, at 07:03 AM, Felipe Sateler wrote:
>> Hi,
>>
>> Turns out webrtc 0.2 does not work on most debian archs[1]. One part
>> is big-endian arches are not supported (already filed at [2]).
>
> I'll try to take a look at that shortly.
>
>> But the one that brings me here is that debian does not require i386
>> machines to have SSE, but xmmintrin.h requires that, and is
>> unconditionally used on i386. I don't know if webrtc can do runtime
>> detection to use said SSE code, (in which case the required sse flags
>> should be added to the compilation unit), or we (debian) should
>> disable SSE support in i386. It should also be possible to build a
>> sse-enabled variant and use the dynamic loader's support for
>> conditinal loading (although I'd prefer not to do that).
>>
>> What would be the best course of action?
>
> Looking at the code, they already do runtime detection, so if you build
> on a machine with SSE2 and intrinsics, you should be okay for this to
> run on any machine with or with SSE2.

Excellent. So no double building necessary :)

> Example of the code:
>
>   #if defined(WEBRTC_ARCH_X86_FAMILY)
> if (WebRtc_GetCPUInfo(kSSE2)) {
>   WebRtcAec_InitAec_SSE2();
> }
>   #endif
>
> Is there some reason you can't /build/ with SSE2 support on the
> compiler? Or were you suggesting that we needed to add  compiler flags
> to make this work?

My fear is that enabling SSE2 support globally for the library might
induce gcc to use SSE2 instructions in its generated code. See the
-msse section in the gcc manual[1]:

> In particular, the file containing the CPU detection code should be
> compiled without these options.

So, I think what is needed is to split sse-using functions to a
separate file and add -msse2 only to that file. However, I am not very
confident I understand this very well, so this may not be optimal
either.

[1] https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html#x86-Options

-- 

Saludos,
Felipe Sateler
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

[pulseaudio-discuss] webrtc: build failures on i386

[Felipe Sateler]

Hi,

Turns out webrtc 0.2 does not work on most debian archs[1]. One part
is big-endian arches are not supported (already filed at [2]).

But the one that brings me here is that debian does not require i386
machines to have SSE, but xmmintrin.h requires that, and is
unconditionally used on i386. I don't know if webrtc can do runtime
detection to use said SSE code, (in which case the required sse flags
should be added to the compilation unit), or we (debian) should
disable SSE support in i386. It should also be possible to build a
sse-enabled variant and use the dynamic loader's support for
conditinal loading (although I'd prefer not to do that).

What would be the best course of action?

[1] 
https://buildd.debian.org/status/package.php?p=webrtc-audio-processing=experimental
[2] https://bugs.freedesktop.org/show_bug.cgi?id=95738

-- 

Saludos,
Felipe Sateler
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [ANNOUNCE] PulseAudio 9.0 RC1

[Felipe Sateler]

On 12 May 2016 at 08:15, Arun Raghavan <a...@arunraghavan.net> wrote:
> Hi folks,
> I'm pleased to announce that the first release candidate for PulseAudio
> 9.0 is out.

I have just uploaded an update to debian experimental. Please test!

-- 

Saludos,
Felipe Sateler
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [ANNOUNCE] WebRTC AudioProcessing v0.2 release

[Felipe Sateler]

On 11 May 2016 05:49, "Georg Chini" <ge...@chini.tk> wrote:
>
> On 28.04.2016 01:46, Felipe Sateler wrote:
>>
>> On 27 April 2016 at 09:56, Arun Raghavan <a...@accosted.net> wrote:
>>>
>>> Hi folks,
>>> I'm happy to finally announce an update to the webrtc-audio-processing
>>> library. A copy of the updates and git shortlog is at the end.
>>>
>>> *Important*: This is an API breaking release, so packagers beware.
>>> PulseAudio versions 8.0 and before should depend on
>>> webrtc-audio-processing 0.1. Upcoming PulseAudio 9.0 release
>>> candidates and later will depend on webrtc-audio-processing 0.2.
>>
>>
>> I've just uploaded webrtc-audio-processing to debian experimental, so
>> we should be ready for the pulseaudio 9 release.
>>
> Hi,
>
> looks like the development files are still missing. I can't compile pulse
> with --enable-webrtc-aec on Debian unstable.

You need to install the headers from experimental.

I'll upload to unatable when there is a RC that can build against it.

Saludos
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [ANNOUNCE] WebRTC AudioProcessing v0.2 release

[Felipe Sateler]

On 27 April 2016 at 09:56, Arun Raghavan <a...@accosted.net> wrote:
> Hi folks,
> I'm happy to finally announce an update to the webrtc-audio-processing
> library. A copy of the updates and git shortlog is at the end.
>
> *Important*: This is an API breaking release, so packagers beware.
> PulseAudio versions 8.0 and before should depend on
> webrtc-audio-processing 0.1. Upcoming PulseAudio 9.0 release
> candidates and later will depend on webrtc-audio-processing 0.2.


I've just uploaded webrtc-audio-processing to debian experimental, so
we should be ready for the pulseaudio 9 release.

-- 

Saludos,
Felipe Sateler
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH v4 1/2] client audio: Support memfd transport

[Felipe Sateler]

On 26 April 2016 at 09:35, Arun Raghavan <a...@accosted.net> wrote:
> On 26 April 2016 at 18:02, Arun Raghavan <a...@accosted.net> wrote:
>> On 26 April 2016 at 17:58, Felipe Sateler <fsate...@debian.org> wrote:
>>> On 26 April 2016 at 03:29, Tanu Kaskinen <ta...@iki.fi> wrote:
>>>>
>>>> We've had this problem before. According to this[1] blog post, the
>>>> issue was fixed earlier by linking json-glib with -Bsymbolic. The
>>>> option forces json-glib's internal json_object_get_type() calls to
>>>> always use json-glib's own implementation, but I don't think it helps
>>>> applications that use json-glib.
>>>
>>>
>>> According to the same blog post:
>>>
>>>> another solution is to link json-c with -Bsymbolic
>>>
>>> And that is done by the latest json-c (0.12)[1]. What version do you
>>> have installed?
>>
>> I have 0.12.
>
> From what I could tell of -Bsymbolic, it only guarantees that calls to
> functions within the library will be resolved to use the version in
> the library even if an external version of the symbol is available.
>
> I saw no way to guarantee via linker flags that calls from one library
> into another are always resolved to the intended library.

Right. The real solution then is for either of the libraries to use
symbol versioning (I wonder why neither does, actually...).

-- 

Saludos,
Felipe Sateler
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH v4 1/2] client audio: Support memfd transport

[Felipe Sateler]

On 26 April 2016 at 03:29, Tanu Kaskinen <ta...@iki.fi> wrote:
>
> We've had this problem before. According to this[1] blog post, the
> issue was fixed earlier by linking json-glib with -Bsymbolic. The
> option forces json-glib's internal json_object_get_type() calls to
> always use json-glib's own implementation, but I don't think it helps
> applications that use json-glib.


According to the same blog post:

> another solution is to link json-c with -Bsymbolic

And that is done by the latest json-c (0.12)[1]. What version do you
have installed?


[1] https://github.com/json-c/json-c/blob/master/ChangeLog#L26

-- 

Saludos,
Felipe Sateler
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Stepping down; future thoughts

[Felipe Sateler]

On 28 March 2016 at 01:36, David Henningsson <di...@ubuntu.com> wrote:
> I've decided to stop working for Canonical, and with that, I intend to ramp
> down my contributions to PulseAudio, on both upstream and Ubuntu levels.

Good luck in your next projects!

-- 

Saludos,
Felipe Sateler
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH 0/8] Add GStreamer-based RTP support

[Felipe Sateler]

On 29 February 2016 at 07:16,  <a...@accosted.net> wrote:
> Hi folks,
> Here's a patch set to add a GStreamer-based RTP implementation for
> module-rtp-send and module-rtp-receive. The rationale for this is that
> our own RTP implementation is rather basic, and using a more
> well-established stack will allow us to do more, such as add support for
> RTCP, clock synchronisation, and compressed formats. This should also
> reduce our support burden for the RTP stack in theory (although we don't
> have too much other than the occasional crasher, I think).
>
> For compressed formats, in particular, moving to a GStreamer-based
> implementation lets us not have to deal with messy codec bits within
> PulseAudio, which is important IMO, since it opens a whole can of worms
> that I'd rather not deal with at the PulseAudio layer. Conversely, it
> would be useful to support Opus or other compression since we currently
> end up flooding the network while streaming raw audio.
>
> Patch 1, 2 and 6 are small fixes to the existing code
> Patch 3 drops support for non-L16 formats which seem to not be useful
> Patch 4 and 5 refactor the code to hide away the RTP implementation
> details from the actual modules
> Patch 7 is minor rtpoll plumbing improvement that was needed
> Patch 8 is the actual GStreamer implementation
>
> From a packaging perspective, this might be a bit confusing since we add
> a dependency on the GStreamer package which might in turn depend on
> PulseAudio (for pulsesrc and pulsesink). The exact dependencies are:
>
>  * The PulseAudio server has a compile and run time dependency on
>gstreamer and  gst-plugins-base
>  * The PulseAudio server has a run time dependency on gst-plugins-good
>  * gst-plugins-good has a compile and run time dependency on the
>PulseAudio client library

Hmm. Would only the rtp module require gstreamer? If so, would it make
sense to split out rtp into a separate package due to this new
dependency? I guess if there are plans to add other gstreamer deps it
wouldn't...

Also, it took me a while to realize there is apparantly no circular
dependency: plugins-good comes in a separate source package from the
gstreamer parts required by pulseaudio, thus avoiding the circularity.

-- 

Saludos,
Felipe Sateler
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Using module-combine-sink with intermittent devices

[Felipe Sateler]

On 19 Jan 2016 18:53, "Ahmed S. Darwish" <darwish...@gmail.com> wrote:
>
> On Mon, Jan 18, 2016 at 11:47:50PM -0300, Felipe Sateler wrote:
> >
> > On 18 January 2016 at 23:25, Arun Raghavan <a...@accosted.net> wrote:
> >
> > > This should be okay. I thought systemd has (or was going to have) a
> > > mechanism for per-user services to come up at boot, but I might've
> > > been imagining this.
> >
> > You can enable linger on your user, then your enabled user services
> > should start up at boot and exit at shutdown.
> >
> > You'd need to add yourself to the audio group, however, because
> > otherwise you'd loose access to the sound device when not logged in.
> >
>
> Shouldn't PulseAudio's systemd logind integration (module-systemd-login)
> be disabled in that case?

No, why would you do that? The login integration is meant to prevent the
daemon from exiting on idle as long as there is an active user session .
This is still useful if daemon initialization is slow.

Having an always active pulseaudio socket does not necessarily mean having
an always active daemon.

Saludos
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [ANNOUNCE] PulseAudio 8.0 RC2

[Felipe Sateler]

On 15 January 2016 at 08:09, Arun Raghavan <a...@accosted.net> wrote:
> On 12 January 2016 at 09:13, Arun Raghavan <a...@accosted.net> wrote:
>> Hello,
>> Things seem to have been fairly stable with RC1, but we had a few small
>> changes worth an RC2, so here we go. If things continue to be quiet, I
>> think we can likely roll the release out next.
>>
>> http://www.freedesktop.org/software/pulseaudio/releases/pulseaudio-7.99.2.tar.xz
>> MD5: 0028dea2cc88be8e874b63e9d1f4bd17
>> SHA1: b3b90489161c424202b841639a37c8e2357fa4c8
>>
>> Changes include re-enabling timer-based scheduling on USB devices, and
>> fixes for OS X, and some minor build and bug fixes. A detailed
>> changelog will accompany the release.
>>
>> As usual, please test and report any problems you find.
>
> As usual, there are Fedora RPMs up at:
>
>   https://copr.fedoraproject.org/coprs/arunsr/pulseaudio-latest/
>

I have also just uploaded the package to debian experimental.

-- 

Saludos,
Felipe Sateler
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [ANNOUNCE] PulseAudio 8.0 RC1

[Felipe Sateler]

On 28 December 2015 at 09:56, Arun Raghavan <a...@accosted.net> wrote:
> Hi folks,
> As promised, master has been frozen for the 8.0 release. I've rolled
> out the RC1 tarball (7.99.1, as usual). Please test and file bugs if
> you see regressions.

It's now available from debian experimental, if you want to try it out
but don't want to compile it!

-- 

Saludos,
Felipe Sateler
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH 3/6] stream: Implement a pa_stream_get_volume() API

[Felipe Sateler]

On 29 December 2015 at 00:33,  <a...@accosted.net> wrote:
> diff --git a/PROTOCOL b/PROTOCOL
> index 3c08fea..45e3c96 100644
> --- a/PROTOCOL
> +++ b/PROTOCOL
> @@ -371,6 +371,22 @@ PA_COMMAND_DISABLE_SRBCHANNEL
>  Tells the client to stop listening on the additional SHM ringbuffer channel.
>  Acked by client by sending PA_COMMAND_DISABLE_SRBCHANNEL back.
>
> +## v31, implemented by >= 8.0


This says 8.0, but other patches say "\since 9.0".

-- 

Saludos,
Felipe Sateler
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH 1/2] build-sys: Fix install order of libpulsecore

[Felipe Sateler]

On 28 December 2015 at 21:41, Arun Raghavan <a...@accosted.net> wrote:
> On 29 December 2015 at 05:33, Felipe Sateler <fsate...@debian.org> wrote:
>> On 28 December 2015 at 20:34, Felipe Sateler <fsate...@debian.org> wrote:
>>> It needs to be installed after libpulse, because of libtool relinking.
>>
>> Sorry for not noticing earlier. This is fallout from my earlier patch
>> to install libpulsecore into pkglibdir. When building on a system that
>> does not have libpulse installed, the followin error occurs:
>>
>> /usr/bin/ld: cannot find -lpulse
>> collect2: error: ld returned 1 exit status
>> libtool: install: error: relink `libpulsecore-7.99.la' with the above
>> command before installing it
>> Makefile:5012: recipe for target 'install-pkglibLTLIBRARIES' failed
>>
>> This patch orders first libpulsecommon, then normal libs, and then
>> pkglibs (which is only libpulsecore now).
>>
>> --
>
> Thanks, pushing this and the Travis one.

Thanks!

-- 

Saludos,
Felipe Sateler
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

[pulseaudio-discuss] [PATCH 2/2] travis: Run make install in travis.

[Felipe Sateler]

This helps detect ordering problems in the install target
---
 .travis.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.travis.yml b/.travis.yml
index 456cfb5..da3b352 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -58,7 +58,7 @@ before_script:
   - NOCONFIGURE=1 ./bootstrap.sh
 
 script:
-  - ./configure --localstatedir=/var && make && make check && make check-daemon
+  - ./configure --localstatedir=/var && make && make check && make 
check-daemon && make install DESTDIR=`mktemp -d`
 
 notifications:
   email:
-- 
2.6.4

___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH 1/2] build-sys: Fix install order of libpulsecore

[Felipe Sateler]

On 28 December 2015 at 20:34, Felipe Sateler <fsate...@debian.org> wrote:
> It needs to be installed after libpulse, because of libtool relinking.

Sorry for not noticing earlier. This is fallout from my earlier patch
to install libpulsecore into pkglibdir. When building on a system that
does not have libpulse installed, the followin error occurs:

/usr/bin/ld: cannot find -lpulse
collect2: error: ld returned 1 exit status
libtool: install: error: relink `libpulsecore-7.99.la' with the above
command before installing it
Makefile:5012: recipe for target 'install-pkglibLTLIBRARIES' failed

This patch orders first libpulsecommon, then normal libs, and then
pkglibs (which is only libpulsecore now).

-- 

Saludos,
Felipe Sateler
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

[pulseaudio-discuss] [PATCH] build-sys: Make pulsecore a private library

[Felipe Sateler]

It is not meant to be used by third parties, so do not install in a public dir
---
 src/Makefile.am | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

This is a resend, earlier patch was not picked up by patchwork.

diff --git a/src/Makefile.am b/src/Makefile.am
index de975c5..f1bd38d 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -918,7 +918,7 @@ libpulsedsp_la_LDFLAGS = $(AM_LDFLAGS) $(AM_LIBLDFLAGS) 
-avoid-version -disable-
 #  Daemon core library#
 ###
 
-lib_LTLIBRARIES += libpulsecore-@PA_MAJORMINOR@.la
+pkglib_LTLIBRARIES += libpulsecore-@PA_MAJORMINOR@.la
 
 # Pure core stuff
 libpulsecore_@PA_MAJORMINOR@_la_SOURCES = \
-- 
2.6.3

___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH v2 1/2] conf-parser: add support for .d directories

[Felipe Sateler]

On 6 December 2015 at 20:51, Tanu Kaskinen <ta...@iki.fi> wrote:
> On Sat, 2015-12-05 at 19:50 +0200, Tanu Kaskinen wrote:
>> On Sat, 2015-12-05 at 12:24 -0300, Felipe Sateler wrote:
>> > On 4 December 2015 at 09:46, Tanu Kaskinen <ta...@iki.fi> wrote:
>> > > On Fri, 2015-12-04 at 09:29 -0300, Felipe Sateler wrote:
>> > > > On 4 December 2015 at 02:58, Tanu Kaskinen <ta...@iki.fi> wrote:
>> > > > > + * If use_dot_d is true, then before parsing the file named by the 
>> > > > > filename
>> > > > > + * argument, the function will parse all files ending with ".conf" 
>> > > > > in
>> > > > > + * alphabetical order from a directory whose name is filename + 
>> > > > > ".d", if such
>> > > > > + * directory exists.
>> > > >
>> > > > This is opposite to how other software (eg systemd) work: first the
>> > > > main file is read, and then the .d/*.conf files are read to override
>> > > > the configurations.
>> > > >
>> > > > So if a distro default has an uncommented line, the .d should override
>> > > > that line. This would allow (in the future) to extend the search path
>> > > > to /usr/share/pulseaudio, and ship the defaults (uncommented) there.
>> > > > Then local configuration can be done via dropin files.
>> > >
>> > > All advice given to users so far has been to modify the main files,
>> > > because nothing else has existed. If users put their changes to the
>> > > main files and distros put their changes to the .d files, that will be
>> > > compatible with existing advice on the internet.
>> >
>> > The alternative does not preclude editing the main file either.
>> >
>> > Maybe it would be best to step back a bit. Desirable properties for
>> > the configuration loading are (IMO, of course):
>> >
>> > 1. Any upstream default should be easily overridable by a downstream
>> >distributor.
>> > 2. Any upstream/distribution default should be easily overridable by a
>> >local admin.
>> > 3. Any upstream/distribution/admin default should be easily
>> >overridable by a local user.
>> > 4. Admin overriding a setting should not require writing all the options 
>> > again.
>> > 5. Local user overriding a setting should not require writing all the
>> > options again.
>> > 6. Third party packages should be able to provide configuration,
>> > without overriding other options.
>> > 7. Local admin/user should be able to override such configuration.
>> > 8. Local admin changes to configuration should be clearly visible.
>>
>> I agree on all of these.
>>
>> > Currently, pulseaudio only covers 1-3. Your proposed patch addresses
>> > point 6, but only in the case the distro default is "everything
>> > commented".
>>
>> I guess you mean that my proposal breaks if the distro overrides
>> upstream defaults in the main file, because packages can't override
>> those in .d files.
>>
>> My suggestion is to not patch the main files in distros. Instead, put
>> distro defaults that diverge from the upstream defaults to .d files.
>> Use 00- prefix to make these defaults have the lowest precedence, and
>> use higher numbers in third-party packages.
>>
>> > If the load order is inverted, then there is a path to achieving all 8
>> > properties:
>> >
>> > - If the dropins were read after the main configuration file, then 6
>> >   would be fully addressed.
>> > - If then the path loading is extended to load dropins in the entire
>> >   search path, keeping only the highest precedence one, then point 4 and
>> >   5 would be addressed.
>>
>> I guess you mean merging the file list in all .d directories before
>> starting processing. For example:
>>
>> $datadir/client.conf.d/10-foo.conf
>> $sysconfdir/client.conf.d/30-bar.conf
>> $userconfdir/client.conf.d/20-blub.conf
>>
>> The processing order would be 10-foo.conf -> 20-blub.conf -> 30-
>> bar.conf. That ordering is needed when dealing with scripts (like udev
>> configuration): 10-foo.conf may set some variable that the admin uses
>> as a condition in 30-bar.conf. If the user is happy with the code in
>> 30-bar.conf, but wants to change the variable set in 10-foo.conf before
>> 30-bar.conf uses it, the user has to be able to inser

Re: [pulseaudio-discuss] [PATCH v2 1/2] conf-parser: add support for .d directories

[Felipe Sateler]

On 4 December 2015 at 09:46, Tanu Kaskinen <ta...@iki.fi> wrote:
> On Fri, 2015-12-04 at 09:29 -0300, Felipe Sateler wrote:
>> On 4 December 2015 at 02:58, Tanu Kaskinen <ta...@iki.fi> wrote:
>> > + * If use_dot_d is true, then before parsing the file named by the 
>> > filename
>> > + * argument, the function will parse all files ending with ".conf" in
>> > + * alphabetical order from a directory whose name is filename + ".d", if 
>> > such
>> > + * directory exists.
>>
>> This is opposite to how other software (eg systemd) work: first the
>> main file is read, and then the .d/*.conf files are read to override
>> the configurations.
>>
>> So if a distro default has an uncommented line, the .d should override
>> that line. This would allow (in the future) to extend the search path
>> to /usr/share/pulseaudio, and ship the defaults (uncommented) there.
>> Then local configuration can be done via dropin files.
>
> All advice given to users so far has been to modify the main files,
> because nothing else has existed. If users put their changes to the
> main files and distros put their changes to the .d files, that will be
> compatible with existing advice on the internet.

The alternative does not preclude editing the main file either.

Maybe it would be best to step back a bit. Desirable properties for
the configuration loading are (IMO, of course):

1. Any upstream default should be easily overridable by a downstream
   distributor.
2. Any upstream/distribution default should be easily overridable by a
   local admin.
3. Any upstream/distribution/admin default should be easily
   overridable by a local user.
4. Admin overriding a setting should not require writing all the options again.
5. Local user overriding a setting should not require writing all the
options again.
6. Third party packages should be able to provide configuration,
without overriding other options.
7. Local admin/user should be able to override such configuration.
8. Local admin changes to configuration should be clearly visible.

Currently, pulseaudio only covers 1-3. Your proposed patch addresses
point 6, but only in the case the distro default is "everything
commented".

If the load order is inverted, then there is a path to achieving all 8
properties:

- If the dropins were read after the main configuration file, then 6
  would be fully addressed.
- If then the path loading is extended to load dropins in the entire
  search path, keeping only the highest precedence one, then point 4 and
  5 would be addressed.
- If then the loading stops looking at the search path at the first
  file with same name found, then point 7 would be addressed.
- And then point 8 can be implemented by shipping the full
  configuration file, uncommented, in $datadir. Thus only admin changes
  would live in /etc, and local user changes would live in ~/.config.

Not inverting the change, though, makes it cumbersome to provide a
distro default that can be overriden in a package: some arbitrary
prefix should be determined so that packages ship their defaults
ordered after that. This will necessarily be distro-dependent. It also
makes it harder to have properties 4 and 5, since a setting written in
the main file necessarily requires modifying or copying it.

This is the way many other packages work (eg, systemd and dbus), so
people already familiar with that configuration would be surprised by
pa's scheme.

There is a small wrinkle to observe with this load order: if a
package ships a setting in a dropin file, then the user needs to
override that dropin (or ship a new one with a higher ordering) for
his change to work, because the dropin is processed after the main
file. For example, a dropin in /etc that sets autospawn=no, will take
precedence over the main file in ~/.config/pulse that says
autospawn=yes.

This can be addressed by making the dropins from later in the
search path be loaded before the main file being read (eg, a dropin in
/etc would be loaded before reading ~/.config/pulse/client.conf). This
is not done AFAIK in other software; I'm not sure it is a good idea
to deviate.


-- 

Saludos,
Felipe Sateler
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH v2 1/2] conf-parser: add support for .d directories

[Felipe Sateler]

On 4 December 2015 at 02:58, Tanu Kaskinen <ta...@iki.fi> wrote:
> + * If use_dot_d is true, then before parsing the file named by the filename
> + * argument, the function will parse all files ending with ".conf" in
> + * alphabetical order from a directory whose name is filename + ".d", if such
> + * directory exists.

This is opposite to how other software (eg systemd) work: first the
main file is read, and then the .d/*.conf files are read to override
the configurations.

So if a distro default has an uncommented line, the .d should override
that line. This would allow (in the future) to extend the search path
to /usr/share/pulseaudio, and ship the defaults (uncommented) there.
Then local configuration can be done via dropin files.

-- 

Saludos,
Felipe Sateler
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH 08/11] echo-cancel: Mark private function as static

[Felipe Sateler]

On 4 November 2015 at 09:14,  <a...@accosted.net> wrote:
> From: Arun Raghavan <g...@arunraghavan.net>
>
> ---
>  src/modules/echo-cancel/webrtc.cc | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/src/modules/echo-cancel/webrtc.cc 
> b/src/modules/echo-cancel/webrtc.cc
> index 3be7fe5..a8b69b5 100644
> --- a/src/modules/echo-cancel/webrtc.cc
> +++ b/src/modules/echo-cancel/webrtc.cc
> @@ -78,9 +78,9 @@ static int routing_mode_from_string(const char *rmode) {
>  return -1;
>  }
>
> -void pa_webrtc_ec_fixate_spec(pa_sample_spec *rec_ss, pa_channel_map 
> *rec_map,
> -  pa_sample_spec *play_ss, pa_channel_map 
> *play_map,
> -  pa_sample_spec *out_ss, pa_channel_map 
> *out_map)
> +static void pa_webrtc_ec_fixate_spec(pa_sample_spec *rec_ss, pa_channel_map 
> *rec_map,
> + pa_sample_spec *play_ss, pa_channel_map 
> *play_map,
> + pa_sample_spec *out_ss, pa_channel_map 
> *out_map)

Isn't the convention that static methods do not have pa_ prefix?

-- 

Saludos,
Felipe Sateler
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] webrtc-audio-processing API breakage

[Felipe Sateler]

On 28 October 2015 at 14:38, Arun Raghavan <a...@accosted.net> wrote:
> Hi folks,
> I'm looking at updating the webrtc-audio-processing code, and will
> probably look at doing a new release that breaks API.

Would it be possible to write code that compiles (not run, ABI would
be incompatible) against both versions of the library (by using an
appropriate subset)? Or would pulseaudio have to require the new
version?

-- 

Saludos,
Felipe Sateler
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Device reservation improvement suggestions

[Felipe Sateler]

On 20 October 2015 at 03:46, David Henningsson
<david.hennings...@canonical.com> wrote:
>
>
> On 2015-10-19 14:27, Felipe Sateler wrote:
>>
>> On 19 October 2015 at 05:41, Tanu Kaskinen <ta...@iki.fi> wrote:
>>>>
>>>> (Side note: I would have liked to see the device reservation protocol on
>>>> the system bus instead of the session one, but that's likely too late to
>>>> change now)
>>>
>>>
>>> I think it's probably possible to do the transition to the system bus,
>>> if we just can find someone to write patches for both PulseAudio and
>>> Jack. During a transition phase we would have to use both buses, to
>>> cooperate with applications using only the session bus.
>>
>>
>> Note that now that everyone is moving to a user instead of session
>> bus,
>
>
> Are we? :-) I haven't heard anything about e g Ubuntu switching over, but I
> could have just missed it?

On wily the dbus package first offers dbus-user-session (user bus)
over dbus-x11 (session bus)[1], just as in debian unstable. So I guess
there is still some transitioning to be done for upgrades, but unless
the installer does something manually you should end up with user
sessions by default. Moreover, I think under kdbus session bus is not
supported (I can't find a link though).

[1] http://packages.ubuntu.com/wily/dbus

>
>> the benefits of moving to the system bus are reduced.
>
>
> For me the main use case would still be collaboration between a user-level
> PulseAudio and system-level daemon(s). Which does not change with the move
> from session to user.

Indeed.

>
>> Also, who
>> would ship the dbus/polkit policy to allow logged in users to own the
>> name?
>
>
> Hmm, that's a good point. As a starting point, maybe the same package that
> gives access to the soundcard itself to logged in users?

Well, in the end this is really a distribution problem. I don't see a
problem with everyone that uses this protocol shipping the policy file
and let distributors handle shipping just one version via
Conflicts/internal coordination.

-- 

Saludos,
Felipe Sateler
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Device reservation improvement suggestions

[Felipe Sateler]

On 19 October 2015 at 05:41, Tanu Kaskinen <ta...@iki.fi> wrote:
>> (Side note: I would have liked to see the device reservation protocol on
>> the system bus instead of the session one, but that's likely too late to
>> change now)
>
> I think it's probably possible to do the transition to the system bus,
> if we just can find someone to write patches for both PulseAudio and
> Jack. During a transition phase we would have to use both buses, to
> cooperate with applications using only the session bus.

Note that now that everyone is moving to a user instead of session
bus, the benefits of moving to the system bus are reduced. Also, who
would ship the dbus/polkit policy to allow logged in users to own the
name?

-- 

Saludos,
Felipe Sateler
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Pulseaudio daemon initialization perjury

[Felipe Sateler]

On 8 October 2015 at 11:22, Glenn Golden <g...@zplane.com> wrote:
> Felipe Sateler <fsate...@debian.org> [2015-10-08 09:45:51 -0300]:
>> On 8 October 2015 at 06:28, Glenn Golden <g...@zplane.com> wrote:
>> > Tanu Kaskinen <ta...@iki.fi> [2015-10-08 11:33:48 +0300]:
>> >> On Wed, 2015-10-07 at 12:21 -0600, Glenn Golden wrote:
>> >> > The following observations were made on a setup (Arch Linux, x86_64, 
>> >> > recently
>> >> > synched, Arch pulseaudio package 7.0-2) on which the user desires that 
>> >> > no
>> >> > automated launch or respawning of the PA daemon should occur; the user
>> >> > wishes to start the PA daemon only manually, without any behind the 
>> >> > scenes
>> >> > "assistance".
>> >> >
>> >> > The user's client.conf contains only the following lines:
>> >> >
>> >> > default-server =
>> >> > autospawn = no
>> >> >
>> >> > First, verify via ps that no PA process is running. Then, from the 
>> >> > commandline
>> >> > as the (non-root) user:
>> >> >
>> >> > $ export PULSE_LOG=99
>> >> > $ pulseaudio -v -v -v -v -v --start
>> >> > D: [pulseaudio] caps.c: Cleaning up privileges.
>> >> > D: [pulseaudio] conf-parser.c: Parsing configuration file \
>> >> >'/etc/pulse/daemon.conf'
>> >> > D: [pulseaudio] conf-parser.c: Parsing configuration file \
>> >> >'/home/XXX/.config/pulse/client.conf'
>> >> > E: [pulseaudio] main.c: Daemon startup failed.
>> >> >
>> >> > Upon return to the shell prompt, interrogate the exit status:
>> >> >
>> >> >  $ echo $?
>> >> >  1
>> >> >
>> >> > Now observe via ps that a PA daemon process is running:
>> >> >
>> >> >  ...  S
>> >> >
>> >> > and appears to be behaving normally in all respects.
>> >> >
>> >> > At least three things in the above are worthy of head-scratching:
>> >> >
>> >> > 1. The error message states "daemon startup failed", yet a 
>> >> > pulseaudio
>> >> >process clearly did start, and appears to be running as a daemon 
>> >> > process.
>> >> >
>> >> > 2. The '--daemonize=no' shown on the ps line seems wrong, since the 
>> >> > PA
>> >> >process -- which was reported as having failed to start -- is in 
>> >> > fact
>> >> >running as a daemon process.
>> >> >
>> >> > 3. The exit status from the startup command is nonzero (failure), 
>> >> > yet the
>> >> >daemon was evidently started successfully.
>> >>
>> >> Arch uses systemd's socket activation to start pulseaudio.
>> >>
>> >
>> > Hmm, ok, maybe I'm not appreciating the implication of what you're saying
>> > above, but it seems to me that socket-based activation is irrelevant what
>> > is being reported: There was no pulseaudio daemon running at the beginning
>> > of the sequence shown above.
>>
>> Socket activation means systemd will start pulseaudio automatically
>> when a client tries to connect to it, so it starts on demand.
>>
>
> Yes, that much I know. But I still don't see any connection to the original
> example showing the misinformation being reported during a manual start. At
> no time is any client running (that I am aware of) so why should socket
> activation come into play at all?
>
>> >
>> >>
>> >> To prevent automatic starting, I think "systemctl --user disable
>> >> pulseaudio.socket" should do the trick.
>> >>
>> >
>> > Here's the result of the above:
>> >
>> > $ systemctl --user disable pulseaudio.socket
>> > Failed to get D-Bus connection: No such file or directory
>>
>> That doesn't look like a simple file not found, as the dbus connection
>> is to the systemd user instance.
>>
>
> The above 'disable' was done as root, perhaps that was not intended. Doing it
> instead as non-root user yields the following:
>
> $ systemctl --user disable pulseaudio.socket
> Failed to execute operation: No such file or 

[pulseaudio-discuss] [PATCH] build-sys: Make pulsecore a private library

[Felipe Sateler]

It is not meant to be used by third parties, so do not install in a public dir
---
 src/Makefile.am | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/Makefile.am b/src/Makefile.am
index 0c58d37..838560d 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -917,7 +917,7 @@ libpulsedsp_la_LDFLAGS = $(AM_LDFLAGS) $(AM_LIBLDFLAGS) 
-avoid-version -disable-
 #  Daemon core library#
 ###
 
-lib_LTLIBRARIES += libpulsecore-@PA_MAJORMINOR@.la
+pkglib_LTLIBRARIES += libpulsecore-@PA_MAJORMINOR@.la
 
 # Pure core stuff
 libpulsecore_@PA_MAJORMINOR@_la_SOURCES = \
-- 
2.6.0

___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Dynamic range compression

[Felipe Sateler]

On 28 September 2015 at 10:43, Tanu Kaskinen <ta...@iki.fi> wrote:
> On Mon, 2015-09-28 at 15:30 +0200, Mikhail Morfikov wrote:
>> A few days ago I found a module called module-ladspa-sink ,
>> and it can be enabled by adding the following code to the
>> /etc/pulse/default.pa file:
>>
>> .ifexists module-ladspa-sink.so
>> .nofail
>> load-module module-ladspa-sink sink_name=compressor plugin=sc4m_1916
>> label=sc4m control=1,1.5,401,-30,20,5,12
>> .fail
>> .endif
>>
>> It works, but I was trying to figure out what exactly
>> control=1,1.5,401,-30,20,5,12 means. There's a link
>> (http://plugin.org.uk/ladspa-swh/docs/ladspa-swh.html#tth_sEc2.92),
>> where you can find some documentation on the sc4m_1916 plugin,
>> but actually I don't really know which of the values corresponds
>> to the specific options. In the link, there's 9 parameters,
>> and in the code above, there's 7 I think.
>>
>> Is there someone who could cast a little light on the control
>> numbers?
>
> module-ladspa-sink fails to load if you don't provide all parameters,
> so if it works, the plugin really has only 7 control parameters. I
> don't know how you then should map them to the documentation. There
> very likely is some handy little program somewhere that you could use
> to inspect the plugin, but the only one that I can mention off the top
> of my head is JACK Rack, but that obviously depends on JACK, and if you
> don't already use JACK, it can be a bit of a hassle to set it up. I'd
> expect there to be some simple command line ladspa plugin inspector
> program too that doesn't need any audio access.

There is analyseplugin that is part of the ladspa sdk:

% analyseplugin sc4m_1916

Plugin Name: "SC4 mono"
Plugin Label: "sc4m"
Plugin Unique ID: 1916
Maker: "Steve Harris <st...@plugin.org.uk>"
Copyright: "GPL"
Must Run Real-Time: No
Has activate() Function: No
Has deactivate() Function: No
Has run_adding() Function: Yes
Environment: Normal or Hard Real-Time
Ports:  "RMS/peak" input, control, 0 to 1, default 0
   "Attack time (ms)" input, control, 1.5 to 400, default 101.125
   "Release time (ms)" input, control, 2 to 800, default 401
   "Threshold level (dB)" input, control, -30 to 0, default 0
   "Ratio (1:n)" input, control, 1 to 20, default 1
   "Knee radius (dB)" input, control, 1 to 10, default 3.25
   "Makeup gain (dB)" input, control, 0 to 24, default 0
   "Amplitude (dB)" output, control, -40 to 12
   "Gain reduction (dB)" output, control, -24 to 0
   "Input" input, audio
   "Output" output, audio

-- 

Saludos,
Felipe Sateler
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

[pulseaudio-discuss] coverity and pa_asser_se

[Felipe Sateler]

Hi,

On 15 September 2015 at 19:01, Peter Meerwald <pme...@pmeerw.net> wrote:
> nota bene: put the following in user_nodefs.h in the cov-analysis/config
> directory to address pa_assert_se() false alarms:
>
>  #nodef pa_assert_se(x) do { int y = x ; if (!(y)) __coverity_panic__(); } 
> while (0)

This indeed fixes the problem, but introduces a new one (although
rarer). See CID 1324353, where coverity complains about an
uninitialized variable y is used. I suggest replacing the variable
names with less common ones.

#nodef pa_assert_se(expr1234) do { int result1234 = expr1234 ; if
(!(result1234)) __coverity_panic__(); } while (0)


-- 

Saludos,
Felipe Sateler
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Ready for 7.0?

[Felipe Sateler]

On 21 September 2015 at 02:51, Arun Raghavan <a...@accosted.net> wrote:
> Hi folks,
> This came up during the weekly dev meeting [1], but I just wanted to
> check in (particularly with our distro maintainers) how things are
> looking with 7.0 RC2.
>
> We did have one crasher fix since [2], but if user reports have been
> relatively stable, then we might be able to do 7.0 in a couple of
> days.

I have not received any reports in debian, but then not many people
use experimental.


-- 

Saludos,
Felipe Sateler
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Enabling automatic coverity scans for pulseaudio via travis

[Felipe Sateler]

On 11 September 2015 at 04:14, Peter Meerwald <pme...@pmeerw.net> wrote:
>
>
> > > somehow the last scan completed now, just FYI
> >
> > And it is riddled with false positives about side effects in assert.
> > Is it possible to teach coverity that pa_assert_se always executes the
> > side effects?
>
> under https://scan.coverity.com/projects/pulseaudio?tab=analysis_settings
> you can upload a modeling file,

I do not have permission to see that page.

> currently
>
> void fail(void) {
> __coverity_panic__();
> }
>
> void pa_assert_se(int x) {
> if (!x)
> __coverity_panic__();
> }
>
> it seems to ignore the hint for pa_assert_se() (or it is wrong)

My guess is that the model is not getting picked up because
pa_asser_se is a macro that expands a lot like assert, and thus
coverity thinks it can be optimized away.


-- 

Saludos,
Felipe Sateler
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH 2/3] pa_get_fqdn: always free addrinfo

[Felipe Sateler]

On 11 September 2015 at 10:45, Felipe Sateler <fsate...@debian.org> wrote:
> On 11 September 2015 at 08:20, Tanu Kaskinen <ta...@iki.fi> wrote:
>> On Thu, 2015-09-10 at 21:42 -0300, Felipe Sateler wrote:
>>> Found by coverity
>>> ---
>>>  src/pulse/util.c | 5 -
>>>  1 file changed, 4 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/src/pulse/util.c b/src/pulse/util.c
>>> index 305673f..e4e8207 100644
>>> --- a/src/pulse/util.c
>>> +++ b/src/pulse/util.c
>>> @@ -311,8 +311,11 @@ char *pa_get_fqdn(char *s, size_t l) {
>>>  hints.ai_family = AF_UNSPEC;
>>>  hints.ai_flags = AI_CANONNAME;
>>>
>>> -if (getaddrinfo(hn, NULL, , ) < 0 || !a || !a
>>> ->ai_canonname || !*a->ai_canonname)
>>> +if (getaddrinfo(hn, NULL, , ) < 0 || !a || !a
>>> ->ai_canonname || !*a->ai_canonname) {
>>> +if (a)
>>> +freeaddrinfo(a);
>>>  return pa_strlcpy(s, hn, l);
>>> +}
>>
>> I don't know if getaddrinfo() is guaranteed to always initialize a, but
>> if not, this code may access a while it's uninitialized. I think we
>> should initialize a to NULL.
>
> My man pages do not say anything about this. So this seems like a sane
> thing to do anyway, or split the check in two: successful getaddrinfo
> and canonname is set.

I just realized my manpage doesn't say anything about the sign of the
return codes. So the check is bad, (which is why I suspect there was
the extra !a check, and has been there since the beginning).



-- 

Saludos,
Felipe Sateler
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

[pulseaudio-discuss] [PATCH 1/2] pa_get_fqdn: always free addrinfo

[Felipe Sateler]

Also fix the return error code check of getaddrinfo call

Coverity ID: 1323587
---
 src/pulse/util.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/src/pulse/util.c b/src/pulse/util.c
index 305673f..54fe7a2 100644
--- a/src/pulse/util.c
+++ b/src/pulse/util.c
@@ -297,7 +297,7 @@ char *pa_path_get_filename(const char *p) {
 char *pa_get_fqdn(char *s, size_t l) {
 char hn[256];
 #ifdef HAVE_GETADDRINFO
-struct addrinfo *a, hints;
+struct addrinfo *a = NULL, hints;
 #endif
 
 pa_assert(s);
@@ -311,9 +311,14 @@ char *pa_get_fqdn(char *s, size_t l) {
 hints.ai_family = AF_UNSPEC;
 hints.ai_flags = AI_CANONNAME;
 
-if (getaddrinfo(hn, NULL, , ) < 0 || !a || !a->ai_canonname || 
!*a->ai_canonname)
+if (getaddrinfo(hn, NULL, , ))
 return pa_strlcpy(s, hn, l);
 
+if (!a->ai_canonname || !*a->ai_canonname) {
+freeaddrinfo(a);
+return pa_strlcpy(s, hn, l);
+}
+
 pa_strlcpy(s, a->ai_canonname, l);
 freeaddrinfo(a);
 return s;
-- 
2.5.1

___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

[pulseaudio-discuss] [PATCH 2/2] pa_*_volume_change_push: Do not dereference freed memory when freeing the next events

[Felipe Sateler]

Coverity IDs: 1138197, 1138196
---
 src/pulsecore/sink.c   | 3 ++-
 src/pulsecore/source.c | 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/pulsecore/sink.c b/src/pulsecore/sink.c
index c2bf0e4..9ddb527 100644
--- a/src/pulsecore/sink.c
+++ b/src/pulsecore/sink.c
@@ -3543,6 +3543,7 @@ static void 
pa_sink_volume_change_free(pa_sink_volume_change *c) {
 void pa_sink_volume_change_push(pa_sink *s) {
 pa_sink_volume_change *c = NULL;
 pa_sink_volume_change *nc = NULL;
+pa_sink_volume_change *pc = NULL;
 uint32_t safety_margin = s->thread_info.volume_change_safety_margin;
 
 const char *direction = NULL;
@@ -3600,7 +3601,7 @@ void pa_sink_volume_change_push(pa_sink *s) {
 pa_log_debug("Volume going %s to %d at %llu", direction, 
pa_cvolume_avg(>hw_volume), (long long unsigned) nc->at);
 
 /* We can ignore volume events that came earlier but should happen later 
than this. */
-PA_LLIST_FOREACH(c, nc->next) {
+PA_LLIST_FOREACH_SAFE(c, pc, nc->next) {
 pa_log_debug("Volume change to %d at %llu was dropped", 
pa_cvolume_avg(>hw_volume), (long long unsigned) c->at);
 pa_sink_volume_change_free(c);
 }
diff --git a/src/pulsecore/source.c b/src/pulsecore/source.c
index 2dd7a28..b553a2d 100644
--- a/src/pulsecore/source.c
+++ b/src/pulsecore/source.c
@@ -2654,6 +2654,7 @@ static void 
pa_source_volume_change_free(pa_source_volume_change *c) {
 void pa_source_volume_change_push(pa_source *s) {
 pa_source_volume_change *c = NULL;
 pa_source_volume_change *nc = NULL;
+pa_source_volume_change *pc = NULL;
 uint32_t safety_margin = s->thread_info.volume_change_safety_margin;
 
 const char *direction = NULL;
@@ -2711,7 +2712,7 @@ void pa_source_volume_change_push(pa_source *s) {
 pa_log_debug("Volume going %s to %d at %llu", direction, 
pa_cvolume_avg(>hw_volume), (long long unsigned) nc->at);
 
 /* We can ignore volume events that came earlier but should happen later 
than this. */
-PA_LLIST_FOREACH(c, nc->next) {
+PA_LLIST_FOREACH_SAFE(c, pc, nc->next) {
 pa_log_debug("Volume change to %d at %llu was dropped", 
pa_cvolume_avg(>hw_volume), (long long unsigned) c->at);
 pa_source_volume_change_free(c);
 }
-- 
2.5.1

___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH 2/3] pa_get_fqdn: always free addrinfo

[Felipe Sateler]

On 11 September 2015 at 08:20, Tanu Kaskinen <ta...@iki.fi> wrote:
> On Thu, 2015-09-10 at 21:42 -0300, Felipe Sateler wrote:
>> Found by coverity
>> ---
>>  src/pulse/util.c | 5 -
>>  1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/pulse/util.c b/src/pulse/util.c
>> index 305673f..e4e8207 100644
>> --- a/src/pulse/util.c
>> +++ b/src/pulse/util.c
>> @@ -311,8 +311,11 @@ char *pa_get_fqdn(char *s, size_t l) {
>>  hints.ai_family = AF_UNSPEC;
>>  hints.ai_flags = AI_CANONNAME;
>>
>> -if (getaddrinfo(hn, NULL, , ) < 0 || !a || !a
>> ->ai_canonname || !*a->ai_canonname)
>> +if (getaddrinfo(hn, NULL, , ) < 0 || !a || !a
>> ->ai_canonname || !*a->ai_canonname) {
>> +if (a)
>> +freeaddrinfo(a);
>>  return pa_strlcpy(s, hn, l);
>> +}
>
> I don't know if getaddrinfo() is guaranteed to always initialize a, but
> if not, this code may access a while it's uninitialized. I think we
> should initialize a to NULL.

My man pages do not say anything about this. So this seems like a sane
thing to do anyway, or split the check in two: successful getaddrinfo
and canonname is set.


-- 

Saludos,
Felipe Sateler
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH 3/3] pa_*_volume_change_push: Do not dereference freed memory when freeing the next events

[Felipe Sateler]

On 11 September 2015 at 08:18, David Henningsson
<david.hennings...@canonical.com> wrote:
> Ack, but would it not be more elegant to use PA_LLIST_FOREACH_SAFE?

OK, will change it to use that.

-- 

Saludos,
Felipe Sateler
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss