Re: [pulseaudio-discuss] [PATCH] sink, source: Rework reconfiguration logic to apply to more than rate

[Arun Raghavan]

On Sun, 15 Oct 2017, at 09:45 PM, Tanu Kaskinen wrote:
> On Sun, 2017-09-03 at 16:58 +0530, Arun Raghavan wrote:
> > @@ -1447,52 +1449,57 @@ int pa_sink_update_rate(pa_sink *s, uint32_t rate, 
> > bool passthrough) {
> >  }
> >  }
> >  
> > -if (PA_UNLIKELY(!pa_sample_rate_valid(rate)))
> > +if (PA_UNLIKELY(!pa_sample_spec_valid(spec)))
> >  return -1;
> >  
> > +desired_spec = s->sample_spec;
> > +
> >  if (passthrough) {
> >  /* We have to try to use the sink input rate */
> > -desired_rate = rate;
> > +desired_spec.rate = spec->rate;
> >  
> > -} else if (avoid_resampling && (rate >= default_rate || rate >= 
> > alternate_rate)) {
> > +} else if (avoid_resampling && (spec->rate >= default_rate || 
> > spec->rate >= alternate_rate)) {
> >  /* We just try to set the sink input's sample rate if it's not too 
> > low */
> > -desired_rate = rate;
> > +desired_spec.rate = spec->rate;
> >  
> > -} else if (default_rate == rate || alternate_rate == rate) {
> > +} else if (default_rate == spec->rate || alternate_rate == spec->rate) 
> > {
> >  /* We can directly try to use this rate */
> > -desired_rate = rate;
> > +desired_spec.rate = spec->rate;
> >  
> >  } else {
> >  /* See if we can pick a rate that results in less resampling 
> > effort */
> > -if (default_rate % 11025 == 0 && rate % 11025 == 0)
> > +if (default_rate % 11025 == 0 && spec->rate % 11025 == 0)
> >  default_rate_is_usable = true;
> > -if (default_rate % 4000 == 0 && rate % 4000 == 0)
> > +if (default_rate % 4000 == 0 && spec->rate % 4000 == 0)
> >  default_rate_is_usable = true;
> > -if (alternate_rate && alternate_rate % 11025 == 0 && rate % 11025 
> > == 0)
> > +if (alternate_rate && alternate_rate % 11025 == 0 && spec->rate % 
> > 11025 == 0)
> >  alternate_rate_is_usable = true;
> > -if (alternate_rate && alternate_rate % 4000 == 0 && rate % 4000 == 
> > 0)
> > +if (alternate_rate && alternate_rate % 4000 == 0 && spec->rate % 
> > 4000 == 0)
> >  alternate_rate_is_usable = true;
> >  
> >  if (alternate_rate_is_usable && !default_rate_is_usable)
> > -desired_rate = alternate_rate;
> > +desired_spec.rate = alternate_rate;
> >  else
> > -desired_rate = default_rate;
> > +desired_spec.rate = default_rate;
> >  }
> >  
> > -if (desired_rate == s->sample_spec.rate)
> > +if (pa_sample_spec_equal(&desired_spec, &s->sample_spec) && 
> > passthrough == pa_sink_is_passthrough(s))
> >  return -1;
> >  
> >  if (!passthrough && pa_sink_used_by(s) > 0)
> >  return -1;
> >  
> > -pa_log_debug("Suspending sink %s due to changing the sample rate.", 
> > s->name);
> > +pa_log_debug("Suspending sink %s due to changing format.", s->name);
> >  pa_sink_suspend(s, true, PA_SUSPEND_INTERNAL);
> >  
> > -if (s->update_rate(s, desired_rate) >= 0) {
> > +/* Flag for the sink now that we want it configured for passthrough */
> > +s->is_passthrough_set = passthrough;
> > +
> > +if (s->reconfigure(s, &desired_spec, passthrough) >= 0) {
> 
> The comment is not very good. "Now that we want it configured for
> passthrough" seems to imply that at this point we want the sink
> configured for passthrough, but that's not true if passthrough is
> false.
> 
> Could we remove the passthrough argument from reconfigure()? The
> information is available also via pa_sink.is_passthrough_set. Or could
> we remove the is_passthrough_set flag? It seems to be used only in
> pa_sink_is_passthrough(), and the previous implementation of that
> function would presumably still work. The flag doesn't exist for
> sources.
> 
> If reconfigure() fails and passthrough is true, is_passthrough_set
> should be reverted to false, or alternatively is_passthrough_set could
> be set only after a successful reconfigure() call. However, if
> reconfigure() fails and passthrough is false, then is_passthrough_set
> should still be set to false.

[pulseaudio-discuss] [PATCH] sink, source: Rework reconfiguration logic to apply to more than rate

[Arun Raghavan]

This rejigs the update_rate() logic to encompass changes to the sample
spec as a whole, as well as passthrough status. As a result,
sinks/sources provide a reconfigure() method which allows
reconfiguration as required.

The behaviour itself is currently unchanged -- alsa-sink/-source do not
actually implement anything other than rate updates for now (nor are
they ever requested to). This can be modified in the future, to allow,
for example 24-bit output when incoming media supports it, as well as
channel count changes for passthrough sinks.

Another related change is that passthrough status is now part of
sink/source reconfiguration, and we can stop doing a suspend/unsuspend
when entering/leaving passthrough state. So that part is now divided
in two -- pa_sink_reconfigure() sets the sink in passthrough mode if
required, and pa_sink_enter_passthrough() sets up everything else
(this currently means only volumes, but could disable other processing)
for passthrough mode.
---
 src/modules/alsa/alsa-sink.c   | 16 ++
 src/modules/alsa/alsa-source.c | 14 +
 src/pulsecore/sink-input.c |  6 ++--
 src/pulsecore/sink.c   | 71 +-
 src/pulsecore/sink.h   |  7 ++---
 src/pulsecore/source-output.c  |  6 ++--
 src/pulsecore/source.c | 58 ++
 src/pulsecore/source.h |  6 ++--
 8 files changed, 90 insertions(+), 94 deletions(-)

diff --git a/src/modules/alsa/alsa-sink.c b/src/modules/alsa/alsa-sink.c
index 827a65081..96fd02aec 100644
--- a/src/modules/alsa/alsa-sink.c
+++ b/src/modules/alsa/alsa-sink.c
@@ -1596,31 +1596,35 @@ static bool sink_set_formats(pa_sink *s, pa_idxset 
*formats) {
 return true;
 }
 
-static int sink_update_rate_cb(pa_sink *s, uint32_t rate) {
+static int sink_reconfigure_cb(pa_sink *s, pa_sample_spec *spec, bool 
passthrough) {
 struct userdata *u = s->userdata;
 int i;
 bool supported = false;
 
+/* FIXME: we only update rate for now */
+
 pa_assert(u);
 
 for (i = 0; u->rates[i]; i++) {
-if (u->rates[i] == rate) {
+if (u->rates[i] == spec->rate) {
 supported = true;
 break;
 }
 }
 
 if (!supported) {
-pa_log_info("Sink does not support sample rate of %d Hz", rate);
+pa_log_info("Sink does not support sample rate of %d Hz", spec->rate);
 return -1;
 }
 
 if (!PA_SINK_IS_OPENED(s->state)) {
-pa_log_info("Updating rate for device %s, new rate is 
%d",u->device_name, rate);
-u->sink->sample_spec.rate = rate;
+pa_log_info("Updating rate for device %s, new rate is %d", 
u->device_name, spec->rate);
+u->sink->sample_spec.rate = spec->rate;
 return 0;
 }
 
+/* Passthrough status change is handled during unsuspend */
+
 return -1;
 }
 
@@ -2357,7 +2361,7 @@ pa_sink *pa_alsa_sink_new(pa_module *m, pa_modargs *ma, 
const char*driver, pa_ca
 else
 u->sink->set_port = sink_set_port_cb;
 if (u->sink->alternate_sample_rate)
-u->sink->update_rate = sink_update_rate_cb;
+u->sink->reconfigure = sink_reconfigure_cb;
 u->sink->userdata = u;
 
 pa_sink_set_asyncmsgq(u->sink, u->thread_mq.inq);
diff --git a/src/modules/alsa/alsa-source.c b/src/modules/alsa/alsa-source.c
index 6bec188ea..3f87a4792 100644
--- a/src/modules/alsa/alsa-source.c
+++ b/src/modules/alsa/alsa-source.c
@@ -1398,28 +1398,30 @@ static void 
source_update_requested_latency_cb(pa_source *s) {
 update_sw_params(u);
 }
 
-static int source_update_rate_cb(pa_source *s, uint32_t rate) {
+static int source_reconfigure_cb(pa_source *s, pa_sample_spec *spec, bool 
passthrough) {
 struct userdata *u = s->userdata;
 int i;
 bool supported = false;
 
+/* FIXME: we only update rate for now */
+
 pa_assert(u);
 
 for (i = 0; u->rates[i]; i++) {
-if (u->rates[i] == rate) {
+if (u->rates[i] == spec->rate) {
 supported = true;
 break;
 }
 }
 
 if (!supported) {
-pa_log_info("Source does not support sample rate of %d Hz", rate);
+pa_log_info("Source does not support sample rate of %d Hz", 
spec->rate);
 return -1;
 }
 
 if (!PA_SOURCE_IS_OPENED(s->state)) {
-pa_log_info("Updating rate for device %s, new rate is %d", 
u->device_name, rate);
-u->source->sample_spec.rate = rate;
+pa_log_info("Updating rate for device %s, new rate is %d", 
u->device_name, spec->rate);
+u->source->sample_spec.rate = spec->rate;
 return 0;
 }
 
@@ -2041,7 +2043,7 @@ pa_source *pa_alsa_source_new(pa_module *m, pa_modargs 
*ma, const char*driver, p
 else
 u->source->set_port = source_set_port_cb;
 if (u->source->alternate_sample_rate)
-u->source->update_rate = source_update_rate_cb;
+u->source->reconfigure = source_reconfigure_cb;
 u->source->userdata = u;
 
 pa_source_

Re: [pulseaudio-discuss] pavucontrol and single launch

[Arun Raghavan]

On Tue, 24 Oct 2017, at 03:45 PM, Colin Leroy wrote:
> Hello,
> 
> I very often end up with six or more instances of pavucontrol running,
> because I click on its launcher to set things up, and then go back to
> whatever I was doing without closing the pavucontrol window.
> 
> Would a single-instance launch patch be welcome ? If so, I could cook
> up something based on GtkApplication.

++ from me!

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

[pulseaudio-discuss] [PATCH] client-conf: Add a default value for disable-memfd

[Arun Raghavan]

This got missed while adding the client option.
---
 src/pulse/client-conf.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/pulse/client-conf.c b/src/pulse/client-conf.c
index a3c9486d4..1daaf9111 100644
--- a/src/pulse/client-conf.c
+++ b/src/pulse/client-conf.c
@@ -65,6 +65,7 @@ static const pa_client_conf default_conf = {
 .cookie_file_from_client_conf = NULL,
 .autospawn = true,
 .disable_shm = false,
+.disable_memfd = false,
 .shm_size = 0,
 .auto_connect_localhost = false,
 .auto_connect_display = false
-- 
2.13.6

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

Re: [pulseaudio-discuss] [PATCH] sink-input, source-output: add a couple of assertions

[Arun Raghavan]

On Mon, 30 Oct 2017, at 12:45 AM, Tanu Kaskinen wrote:
> Coverity complained about data->sink being possibly NULL when it's
> dereferenced later. It was difficult for me to figure out whether that
> was a false positive or not. Hopefully the comments make it a bit
> easier to reason about the code in the future.
> 
> It might be a good idea to set data->req_formats early, so that it's
> always set when setting the sink for a stream. Currently, if the
> application doesn't use the new format negotiation API, req_formats is
> set according to the sample spec at a very late stage. That means that
> sometimes data->sink gets set after data->req_formats, and sometimes
> data->req_formats gets set after data->sink, which makes it difficult to
> follow the code.

It's hard to deterministically set it earlier than pa_sink_input_new(),
unless we make it a contract that it is set before that call for all
callers. Or did you mean we should set it early just for the
protocol-native case?

> CID: 1323591
> ---
>  src/pulsecore/sink-input.c| 5 +
>  src/pulsecore/source-output.c | 5 +
>  2 files changed, 10 insertions(+)
> 
> diff --git a/src/pulsecore/sink-input.c b/src/pulsecore/sink-input.c
> index 05fe2c026..f993322e9 100644
> --- a/src/pulsecore/sink-input.c
> +++ b/src/pulsecore/sink-input.c
> @@ -338,6 +338,11 @@ int pa_sink_input_new(
>  data->format =
>  pa_format_info_copy(pa_idxset_first(data->nego_formats, NULL));
>  
>  if (PA_LIKELY(data->format)) {
> +/* We know that data->sink is set, because data->format has been
> set.
> + * data->format is set after a successful format negotiation,
> and that
> + * can't happen before data->sink has been set. */
> +pa_assert(data->sink);
> +
>  pa_log_debug("Negotiated format: %s",
>  pa_format_info_snprint(fmt, sizeof(fmt), data->format));
>  } else {
>  pa_format_info *format;
> diff --git a/src/pulsecore/source-output.c
> b/src/pulsecore/source-output.c
> index f8a421aa8..f8f4e0ef0 100644
> --- a/src/pulsecore/source-output.c
> +++ b/src/pulsecore/source-output.c
> @@ -280,6 +280,11 @@ int pa_source_output_new(
>  data->format =
>  pa_format_info_copy(pa_idxset_first(data->nego_formats, NULL));
>  
>  if (PA_LIKELY(data->format)) {
> +/* We know that data->source is set, because data->format has
> been set.
> + * data->format is set after a successful format negotiation,
> and that
> + * can't happen before data->source has been set. */
> +pa_assert(data->source);
> +
>  pa_log_debug("Negotiated format: %s",
>  pa_format_info_snprint(fmt, sizeof(fmt), data->format));
>  } else {
>  pa_format_info *format;
> -- 

Looks good.

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

Re: [pulseaudio-discuss] [PATCH] core-util, cpu-x86: use __get_cpuid() instead of homegrown assembly

[Arun Raghavan]

On Wed, 22 Nov 2017, at 08:44 PM, Tanu Kaskinen wrote:
> The get_cpuid() function in cpu-x86.c was buggy on x86-64. When building
> without optimizations, the homegrown assembly code overwrote the
> beginning of the function argument list on the stack. That happened to
> work fine on regular x86-64, but caused crashing with the x32 ABI.
> 
> At least GCC and clang provide cpuid.h, which has the __get_cpuid()
> function that can be used instead of the homegrown assembly.

Just as a sanity check -- does this introduce any compiler version
dependencies? The clang header seems to have been updated relatively
recently for SSE 4.1/4.2 (2016), but the gcc header seems quite old, so
probably okay.
 
> The PA_REG_* constants can be removed as well, because they're not used
> any more.
> 
> BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=103656
> ---
>  configure.ac  |  2 +-
>  src/pulsecore/core-util.c | 35 ---
>  src/pulsecore/cpu-x86.c   | 37 +
>  src/pulsecore/cpu-x86.h   | 12 
>  4 files changed, 38 insertions(+), 48 deletions(-)
> 
> diff --git a/configure.ac b/configure.ac
> index 0c38fbb52..013918f1a 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -410,7 +410,7 @@ AC_SUBST([LIBLTDL])
>  AC_HEADER_STDC
>  
>  # POSIX
> -AC_CHECK_HEADERS_ONCE([arpa/inet.h glob.h grp.h netdb.h netinet/in.h \
> +AC_CHECK_HEADERS_ONCE([arpa/inet.h cpuid.h glob.h grp.h netdb.h
> netinet/in.h \
>  netinet/in_systm.h netinet/tcp.h poll.h pwd.h sched.h \
>  sys/mman.h sys/select.h sys/socket.h sys/wait.h \
>  sys/uio.h syslog.h sys/dl.h dlfcn.h linux/sockios.h])
> diff --git a/src/pulsecore/core-util.c b/src/pulsecore/core-util.c
> index d4cfa20c7..64e9f2171 100644
> --- a/src/pulsecore/core-util.c
> +++ b/src/pulsecore/core-util.c
> @@ -124,6 +124,10 @@
>  #include 
>  #endif
>  
> +#ifdef HAVE_CPUID_H
> +#include 
> +#endif
> +
>  #include 
>  #include 
>  #include 
> @@ -136,7 +140,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  
> @@ -3663,11 +3666,13 @@ bool pa_running_in_vm(void) {

I wonder if the use-case for this is still valid (not being able to run
tsched in a VM).

>  
>  /* Both CPUID and DMI are x86 specific interfaces... */
>  
> -uint32_t eax = 0x4000;
> +#ifdef HAVE_CPUID_H
> +uint32_t eax;
>  union {
>  uint32_t sig32[3];
>  char text[13];
>  } sig;
> +#endif
>  
>  #ifdef __linux__
>  const char *const dmi_vendors[] = {
> @@ -3701,19 +3706,18 @@ bool pa_running_in_vm(void) {
>  
>  #endif
>  
> -/* http://lwn.net/Articles/301888/ */
> -pa_zero(sig);
> -
> -__asm__ __volatile__ (
> -/* ebx/rbx is being used for PIC! */
> -"  push %%"PA_REG_b" \n\t"
> -"  cpuid \n\t"
> -"  mov %%ebx, %1 \n\t"
> -"  pop %%"PA_REG_b"  \n\t"
> +#ifdef HAVE_CPUID_H
>  
> -: "=a" (eax), "=r" (sig.sig32[0]), "=c" (sig.sig32[1]), "=d"
> (sig.sig32[2])
> -: "0" (eax)
> -);
> +/* Hypervisors provide their signature on the 0x4000 cpuid leaf.
> + * http://lwn.net/Articles/301888/
> + *
> + * XXX: Why are we checking a list of signatures instead of the
> + * "hypervisor present bit"? According to the LWN article, the
> "hypervisor
> + * present bit" would be available on bit 31 of ECX on leaf 0x1, and
> that
> + * bit would tell us directly whether we're in a virtual machine or
> not. */
> +pa_zero(sig);
> +if (__get_cpuid(0x4000, &eax, &sig.sig32[0], &sig.sig32[1],
> &sig.sig32[2]) == 0)
> +return false;
>  
>  if (pa_streq(sig.text, "XenVMMXenVMM") ||
>  pa_streq(sig.text, "KVMKVMKVM") ||
> @@ -3722,8 +3726,9 @@ bool pa_running_in_vm(void) {
>  /* http://msdn.microsoft.com/en-us/library/bb969719.aspx */
>  pa_streq(sig.text, "Microsoft Hv"))
>  return true;
> +#endif /* HAVE_CPUID_H */
>  
> -#endif
> +#endif /* defined(__i386__) || defined(__x86_64__) */
>  
>  return false;
>  }
> diff --git a/src/pulsecore/cpu-x86.c b/src/pulsecore/cpu-x86.c
> index a86c26da4..4e59e14cc 100644
> --- a/src/pulsecore/cpu-x86.c
> +++ b/src/pulsecore/cpu-x86.c
> @@ -24,35 +24,28 @@
>  
>  #include 
>  
> +#ifdef HAVE_CPUID_H
> +#include 
> +#endif
> +
>  #include 
>  
>  #include "cpu-x86.h"
>  
> -#if defined (__i386__) || defined (__amd64__)
> -static void get_cpuid(uint32_t op, uint32_t *a, uint32_t *b, uint32_t
> *c, uint32_t *d) {
> -__asm__ __volatile__ (
> -"  push %%"PA_REG_b"   \n\t"
> -"  cpuid   \n\t"
> -"  mov %%ebx, %%esi\n\t"
> -"  pop %%"PA_REG_b"\n\t"
> -
> -: "=a" (*a), "=S" (*b), "=c" (*c), "=d" (*d)
> -: "0" (op)
> -);
> -}
> -#endif
> -
>  void pa_cpu_get_x86_flags(pa_cpu_x86_flag_t *flags) {
> -#if defined (__i386__) || defined (__amd64__)
> +#if (defined(__i386__

[pulseaudio-discuss] RFC: Remove symdef header generation

[Arun Raghavan]

Hello,
While trying to meson-ify our build, I realised that the symdef header
generation is a pain and started trying to remove it. I have a solution
for this, but wanted broader comments on the approach before going and
changing all the modules and removing the m4 bits.

Comments welcome.

Cheers,
Arun

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

[pulseaudio-discuss] [PATCH] RFC: Remove symdef header generation

[Arun Raghavan]

---
 src/modules/module-allow-passthrough.c |  5 +++--
 src/modules/module-null-sink.c |  6 +++---
 src/pulsecore/module.h | 29 +
 3 files changed, 35 insertions(+), 5 deletions(-)

diff --git a/src/modules/module-allow-passthrough.c 
b/src/modules/module-allow-passthrough.c
index aea81cb52..5fda6878a 100644
--- a/src/modules/module-allow-passthrough.c
+++ b/src/modules/module-allow-passthrough.c
@@ -25,6 +25,9 @@
 
 #include 
 
+#define PA_MODULE_NAME module_allow_passthrough
+#include 
+
 #include 
 #include 
 #include 
@@ -34,8 +37,6 @@
 #include 
 #include 
 
-#include "module-allow-passthrough-symdef.h"
-
 PA_MODULE_AUTHOR("Guillaume Desmottes");
 PA_MODULE_DESCRIPTION("When a passthrough stream is requested, route all the 
other streams to a dummy device");
 PA_MODULE_VERSION(PACKAGE_VERSION);
diff --git a/src/modules/module-null-sink.c b/src/modules/module-null-sink.c
index 9237656a3..f4107f554 100644
--- a/src/modules/module-null-sink.c
+++ b/src/modules/module-null-sink.c
@@ -30,10 +30,12 @@
 #include 
 #include 
 
+#define PA_MODULE_NAME module_null_sink
+#include 
+
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -41,8 +43,6 @@
 #include 
 #include 
 
-#include "module-null-sink-symdef.h"
-
 PA_MODULE_AUTHOR("Lennart Poettering");
 PA_MODULE_DESCRIPTION(_("Clocked NULL sink"));
 PA_MODULE_VERSION(PACKAGE_VERSION);
diff --git a/src/pulsecore/module.h b/src/pulsecore/module.h
index ec2de0b94..d20c80258 100644
--- a/src/pulsecore/module.h
+++ b/src/pulsecore/module.h
@@ -92,4 +92,33 @@ void pa_module_hook_connect(pa_module *m, pa_hook *hook, 
pa_hook_priority_t prio
 bool pa__load_once(void) { return b; } \
 struct __stupid_useless_struct_to_allow_trailing_semicolon
 
+/* Check if we're defining a module */
+#ifdef PA_MODULE_NAME
+
+/* Jump through some double-indirection hoops to get PA_MODULE_NAME 
substituted before the concatenation */
+#define _PA_MACRO_CONCAT1(a, b) a ## b
+#define _PA_MACRO_CONCAT(a, b) _PA_MACRO_CONCAT1(a, b)
+
+#define pa__init _PA_MACRO_CONCAT(PA_MODULE_NAME, _LTX_pa__init)
+#define pa__done _PA_MACRO_CONCAT(PA_MODULE_NAME, _LTX_pa__done)
+#define pa__get_author _PA_MACRO_CONCAT(PA_MODULE_NAME, _LTX_pa__get_author)
+#define pa__get_description _PA_MACRO_CONCAT(PA_MODULE_NAME, 
_LTX_pa__get_description)
+#define pa__get_usage _PA_MACRO_CONCAT(PA_MODULE_NAME, _LTX_pa__get_usage)
+#define pa__get_version _PA_MACRO_CONCAT(PA_MODULE_NAME, _LTX_pa__get_version)
+#define pa__get_deprecated _PA_MACRO_CONCAT(PA_MODULE_NAME, 
_LTX_pa__get_deprecated)
+#define pa__load_once _PA_MACRO_CONCAT(PA_MODULE_NAME, _LTX_pa__load_once)
+#define pa__get_n_used _PA_MACRO_CONCAT(PA_MODULE_NAME, _LTX_pa__get_n_used)
+
+int pa__init(pa_module*m);
+void pa__done(pa_module*m);
+int pa__get_n_used(pa_module*m);
+
+const char* pa__get_author(void);
+const char* pa__get_description(void);
+const char* pa__get_usage(void);
+const char* pa__get_version(void);
+const char* pa__get_deprecated(void);
+bool pa__load_once(void);
+#endif /* PA_MODULE_NAME */
+
 #endif
-- 
2.14.3

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

Re: [pulseaudio-discuss] [PATCH] core-util, cpu-x86: use __get_cpuid() instead of homegrown assembly

[Arun Raghavan]

On Thu, 7 Dec 2017, at 12:58 AM, Tanu Kaskinen wrote:
> On Mon, 2017-12-04 at 19:44 +0530, Arun Raghavan wrote:
> > On Wed, 22 Nov 2017, at 08:44 PM, Tanu Kaskinen wrote:
> > > The get_cpuid() function in cpu-x86.c was buggy on x86-64. When building
> > > without optimizations, the homegrown assembly code overwrote the
> > > beginning of the function argument list on the stack. That happened to
> > > work fine on regular x86-64, but caused crashing with the x32 ABI.
> > > 
> > > At least GCC and clang provide cpuid.h, which has the __get_cpuid()
> > > function that can be used instead of the homegrown assembly.
> > 
> > Just as a sanity check -- does this introduce any compiler version
> > dependencies? The clang header seems to have been updated relatively
> > recently for SSE 4.1/4.2 (2016), but the gcc header seems quite old, so
> > probably okay.
> 
> I haven't checked the history of the compilers, but if there are any
> compilers in use that don't support __get_cpuid(), they will hopefully
> just skip the cpuid parts since the code is guarded by HAVE_CPUID_H.
> 
> > > @@ -3663,11 +3666,13 @@ bool pa_running_in_vm(void) {
> > 
> > I wonder if the use-case for this is still valid (not being able to run
> > tsched in a VM).
> 
> I don't know, and I don't plan to find out... If you want to test
> tsched in all the VMs, be my guest :)
> 
> I suppose the patch is okay to push?

Yes, please go ahead.

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

Re: [pulseaudio-discuss] [PATCH] RFC: Remove symdef header generation

[Arun Raghavan]

On Thu, 7 Dec 2017, at 03:57 AM, Tanu Kaskinen wrote:
> On Tue, 2017-12-05 at 10:56 +0530, Arun Raghavan wrote:
> > ---
> >  src/modules/module-allow-passthrough.c |  5 +++--
> >  src/modules/module-null-sink.c |  6 +++---
> >  src/pulsecore/module.h | 29 +
> >  3 files changed, 35 insertions(+), 5 deletions(-)
> 
> Thanks, this seems nicer than using m4 magic.
> 
> > diff --git a/src/modules/module-allow-passthrough.c 
> > b/src/modules/module-allow-passthrough.c
> > index aea81cb52..5fda6878a 100644
> > --- a/src/modules/module-allow-passthrough.c
> > +++ b/src/modules/module-allow-passthrough.c
> > @@ -25,6 +25,9 @@
> >  
> >  #include 
> >  
> > +#define PA_MODULE_NAME module_allow_passthrough
> > +#include 
> > +
> 
> This works only if nothing else has included module.h first. I think it
> would be more robust to define PA_MODULE_NAME with the -D compiler
> option.

Sure, that works.

> > diff --git a/src/pulsecore/module.h b/src/pulsecore/module.h
> > index ec2de0b94..d20c80258 100644
> > --- a/src/pulsecore/module.h
> > +++ b/src/pulsecore/module.h
> > @@ -92,4 +92,33 @@ void pa_module_hook_connect(pa_module *m, pa_hook *hook, 
> > pa_hook_priority_t prio
> >  bool pa__load_once(void) { return b; } \
> >  struct __stupid_useless_struct_to_allow_trailing_semicolon
> >  
> > +/* Check if we're defining a module */
> > +#ifdef PA_MODULE_NAME
> > +
> > +/* Jump through some double-indirection hoops to get PA_MODULE_NAME 
> > substituted before the concatenation */
> > +#define _PA_MACRO_CONCAT1(a, b) a ## b
> > +#define _PA_MACRO_CONCAT(a, b) _PA_MACRO_CONCAT1(a, b)
> 
> Bikeshedding: I don't like the _PA_ prefix, since these macros aren't
> meant to be used elsewhere. My suggestion is just "MACRO_CONCAT".

I'm okay with that (we can rename to something more generic if we we
find this being reused).

Thanks for the review, I'll go ahed and complete this now.

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

Re: [pulseaudio-discuss] [PATCH] augment-properties: fix a memory leak

[Arun Raghavan]

On Thu, 7 Dec 2017, at 04:09 AM, Tanu Kaskinen wrote:
> If the desktop file is not found, fn was not being freed after the last
> loop iteration.
> 
> CID: 1462477
> ---
>  src/modules/module-augment-properties.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/src/modules/module-augment-properties.c
> b/src/modules/module-augment-properties.c
> index f0584328d..4c38e7418 100644
> --- a/src/modules/module-augment-properties.c
> +++ b/src/modules/module-augment-properties.c
> @@ -140,6 +140,7 @@ static char * find_desktop_file_in_dir(struct rule
> *r, const char *desktop_file_
>  if (stat(fn, st) == 0) {
>  return fn;
>  } else {
> +pa_xfree(fn);
>  #ifdef DT_DIR
>  DIR *desktopfiles_dir;
>  struct dirent *dir;
> @@ -152,13 +153,14 @@ static char * find_desktop_file_in_dir(struct rule
> *r, const char *desktop_file_
>  || pa_streq(dir->d_name, ".."))
>  continue;
>  
> -pa_xfree(fn);
>  fn = pa_sprintf_malloc("%s" PA_PATH_SEP "%s" PA_PATH_SEP
>  "%s.desktop", desktop_file_dir, dir->d_name,
>  r->process_name);
>  
>  if (stat(fn, st) == 0) {
>  closedir(desktopfiles_dir);
>  return fn;
>  }
> +
> +pa_xfree(fn);
>  }
>  closedir(desktopfiles_dir);
>  }
> -- 

Looks good.

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

[pulseaudio-discuss] [PATCH] build-sys: Stop using symdef headers for modules

[Arun Raghavan]

This removes the symdef header generation m4 magic in favour of a
simpler macro method, allowing us to skip one unnecessary build step
while moving to meson, and removing an 11 year old todo!
---
 src/.gitignore|   1 -
 src/Makefile.am   | 271 --
 src/modules/alsa/module-alsa-card.c   |   1 -
 src/modules/alsa/module-alsa-sink.c   |   1 -
 src/modules/alsa/module-alsa-source.c |   1 -
 src/modules/bluetooth/module-bluetooth-discover.c |   2 -
 src/modules/bluetooth/module-bluetooth-policy.c   |   2 -
 src/modules/bluetooth/module-bluez4-device.c  |   1 -
 src/modules/bluetooth/module-bluez4-discover.c|   1 -
 src/modules/bluetooth/module-bluez5-device.c  |   2 -
 src/modules/bluetooth/module-bluez5-discover.c|   2 -
 src/modules/dbus/module-dbus-protocol.c   |   2 -
 src/modules/echo-cancel/module-echo-cancel.c  |   2 -
 src/modules/gconf/module-gconf.c  |   2 -
 src/modules/jack/module-jack-sink.c   |   2 -
 src/modules/jack/module-jack-source.c |   2 -
 src/modules/jack/module-jackdbus-detect.c |   2 -
 src/modules/macosx/module-bonjour-publish.c   |   2 -
 src/modules/macosx/module-coreaudio-detect.c  |   2 -
 src/modules/macosx/module-coreaudio-device.c  |   2 -
 src/modules/module-allow-passthrough.c|   2 -
 src/modules/module-always-sink.c  |   2 -
 src/modules/module-always-source.c|   2 -
 src/modules/module-augment-properties.c   |   2 -
 src/modules/module-card-restore.c |   2 -
 src/modules/module-cli.c  |   2 -
 src/modules/module-combine-sink.c |   2 -
 src/modules/module-combine.c  |   2 -
 src/modules/module-console-kit.c  |   2 -
 src/modules/module-default-device-restore.c   |   2 -
 src/modules/module-defs.h.m4  |  35 ---
 src/modules/module-detect.c   |   2 -
 src/modules/module-device-manager.c   |   2 -
 src/modules/module-device-restore.c   |   2 -
 src/modules/module-equalizer-sink.c   |   2 -
 src/modules/module-esound-compat-spawnfd.c|   2 -
 src/modules/module-esound-compat-spawnpid.c   |   2 -
 src/modules/module-esound-sink.c  |   2 -
 src/modules/module-filter-apply.c |   2 -
 src/modules/module-filter-heuristics.c|   2 -
 src/modules/module-hal-detect-compat.c|   2 -
 src/modules/module-intended-roles.c   |   2 -
 src/modules/module-ladspa-sink.c  |   1 -
 src/modules/module-lirc.c |   2 -
 src/modules/module-loopback.c |   2 -
 src/modules/module-match.c|   2 -
 src/modules/module-mmkbd-evdev.c  |   2 -
 src/modules/module-native-protocol-fd.c   |   2 -
 src/modules/module-null-sink.c|   2 -
 src/modules/module-null-source.c  |   2 -
 src/modules/module-pipe-sink.c|   2 -
 src/modules/module-pipe-source.c  |   2 -
 src/modules/module-position-event-sounds.c|   2 -
 src/modules/module-protocol-stub.c|  30 ---
 src/modules/module-remap-sink.c   |   2 -
 src/modules/module-remap-source.c |   2 -
 src/modules/module-rescue-streams.c   |   2 -
 src/modules/module-role-cork.c|   2 -
 src/modules/module-role-ducking.c |   2 -
 src/modules/module-rygel-media-server.c   |   2 -
 src/modules/module-sine-source.c  |   2 -
 src/modules/module-sine.c |   2 -
 src/modules/module-solaris.c  |   2 -
 src/modules/module-stream-restore.c   |   2 -
 src/modules/module-suspend-on-idle.c  |   2 -
 src/modules/module-switch-on-connect.c|   2 -
 src/modules/module-switch-on-port-available.c |   2 -
 src/modules/module-systemd-login.c|   2 -
 src/modules/module-tunnel-sink-new.c  |   2 -
 src/modules/module-tunnel-source-new.c|   2 -
 src/modules/module-tunnel.c   |   6 -
 src/modules/module-udev-detect.c  |   2 -
 src/modules/module-virtual-sink.c |   2 -
 src/modules/module-virtual-source.c   |   2 -
 src/modules/module-virtual-surround-sink.c|   2 -
 src/modules/module-volume-restore.c   |   2 -
 src/modules/module-waveout.c  |   2 -
 src/modules/module-zeroconf-discover.c|   2 -
 src/modules/module-zeroconf-publish.c |   2 -
 src/modules/oss/module-oss.c  |   1 -
 src/modules/raop/module-raop-discover.c   |   1 -

Re: [pulseaudio-discuss] WIP meson build

[Arun Raghavan]

Hi everyone,

On Fri, 4 Aug 2017, at 09:58 AM, Arun Raghavan wrote:
> On Mon, 31 Jul 2017, at 05:12 PM, Arun Raghavan wrote:
> > Hello,
> > If anyone is interested in moving PulseAudio to meson, I've got some
> > very early work here:
> > 
> >   https://cgit.freedesktop.org/~arun/pulseaudio/log/?h=meson
[...]

That tree is now updated to the point that I think we can upstream and
continue improving -- you can use that to get to the point of a running
daemon + working ALSA modules.

As a reference, the times taken for the build are:

  configure: 2s
  compile (no cache): 13.2s
  compile (ccache): 1.9s

Just waiting for some review comments from the meson folks before I git
send-email it.

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

Re: [pulseaudio-discuss] [PATCH v2] augment-properties: fix a memory leak

[Arun Raghavan]

On Thu, 7 Dec 2017, at 04:56 AM, Tanu Kaskinen wrote:
> If the desktop file is not found, fn was not being freed after the last
> loop iteration.
> 
> CID: 1462477
> ---
>  src/modules/module-augment-properties.c | 13 +
>  1 file changed, 9 insertions(+), 4 deletions(-)
> 
> diff --git a/src/modules/module-augment-properties.c
> b/src/modules/module-augment-properties.c
> index f0584328d..3eb503aa0 100644
> --- a/src/modules/module-augment-properties.c
> +++ b/src/modules/module-augment-properties.c
> @@ -137,10 +137,13 @@ static char * find_desktop_file_in_dir(struct rule
> *r, const char *desktop_file_
>  pa_assert(st);
>  
>  fn = pa_sprintf_malloc("%s" PA_PATH_SEP "%s.desktop",
>  desktop_file_dir, r->process_name);
> -if (stat(fn, st) == 0) {
> +if (stat(fn, st) == 0)
>  return fn;
> -} else {
> +
> +pa_xfree(fn);
> +
>  #ifdef DT_DIR
> +{
>  DIR *desktopfiles_dir;
>  struct dirent *dir;
>  
> @@ -152,18 +155,20 @@ static char * find_desktop_file_in_dir(struct rule
> *r, const char *desktop_file_
>  || pa_streq(dir->d_name, ".."))
>  continue;
>  
> -pa_xfree(fn);
>  fn = pa_sprintf_malloc("%s" PA_PATH_SEP "%s" PA_PATH_SEP
>  "%s.desktop", desktop_file_dir, dir->d_name,
>  r->process_name);
>  
>  if (stat(fn, st) == 0) {
>  closedir(desktopfiles_dir);
>  return fn;
>  }
> +
> +pa_xfree(fn);
>  }
>  closedir(desktopfiles_dir);
>  }
> -#endif
>  }
> +#endif
> +
>  return NULL;
>  }
>  
> -- 

Looks good.

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

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

[Arun Raghavan]

(Note: this patch depends on the symdef header removal work from a few
days ago)

This is a working implementation of a build with meson. The server,
utils, and most modules build with this, and it is possible to run from
a build tree and play/capture audio on ALSA devices.

There are a number of FIXMEs, of course, and a number of features that
need to be enabled (modules, dependencies, installation, etc.), but this
should provide everything we need to get there relatively quickly.

To use this, install meson (distro package, or mesonbuild.com) and run:

  $ cd 
  $ meson 
  $ ninja -C 
---
 meson.build   | 218 ++
 meson_options.txt |  13 +++
 src/daemon/daemon-conf.c  |   4 +
 src/daemon/main.c |   9 ++
 src/daemon/meson.build|  34 ++
 src/meson.build   | 194 +
 src/modules/alsa/meson.build  |  31 ++
 src/modules/meson.build   | 127 ++
 src/modules/module-role-cork.c|   2 +-
 src/modules/module-role-ducking.c |   2 +-
 src/pulse/meson.build |  73 +
 src/pulsecore/meson.build | 170 +
 src/pulsecore/module.c|   4 +
 src/utils/meson.build |  67 
 14 files changed, 946 insertions(+), 2 deletions(-)
 create mode 100644 meson.build
 create mode 100644 meson_options.txt
 create mode 100644 src/daemon/meson.build
 create mode 100644 src/meson.build
 create mode 100644 src/modules/alsa/meson.build
 create mode 100644 src/modules/meson.build
 create mode 100644 src/pulse/meson.build
 create mode 100644 src/pulsecore/meson.build
 create mode 100644 src/utils/meson.build

diff --git a/meson.build b/meson.build
new file mode 100644
index 0..1b00dc1e0
--- /dev/null
+++ b/meson.build
@@ -0,0 +1,218 @@
+project('pulseaudio', 'c', 'cpp',
+version : '10.99.1',
+meson_version : '>= 0.31.0',
+default_options : [ 'c_std=gnu11', 'cpp_std=c++11' ]
+)
+
+pa_version = meson.project_version()
+version_split = pa_version.split('.')
+pa_version_major = version_split[0]
+pa_version_minor = version_split[1]
+pa_version_micro = version_split[2]
+pa_version_major_minor = pa_version_major + '.' + pa_version_minor
+
+pa_api_version = 12
+pa_protocol_version = 31
+
+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())
+
+prefix = get_option('prefix')
+datadir = join_paths(prefix, get_option('datadir'))
+localstatedir = join_paths(prefix, get_option('localstatedir'))
+sysconfdir = join_paths(prefix, get_option('sysconfdir'))
+
+cc = meson.get_compiler('c')
+
+cdata = configuration_data()
+cdata.set_quoted('PACKAGE', 'pulseaudio')
+cdata.set_quoted('PACKAGE_NAME', 'pulseaudio')
+cdata.set_quoted('PACKAGE_VERSION', pa_version)
+cdata.set_quoted('CANONICAL_HOST', host_machine.cpu())
+cdata.set_quoted('PA_MACHINE_ID', join_paths(sysconfdir, 'machine-id'))
+cdata.set_quoted('PA_MACHINE_ID_FALLBACK', join_paths(localstatedir, 'lib', 
'dbus', 'machine-id'))
+cdata.set_quoted('PA_SRCDIR', join_paths(meson.current_source_dir(), 'src'))
+cdata.set_quoted('PA_BUILDDIR', meson.current_build_dir())
+cdata.set_quoted('PA_SOEXT', '.so')
+cdata.set_quoted('PA_DEFAULT_CONFIG_DIR', join_paths(sysconfdir, 'pulse'))
+cdata.set_quoted('PA_BINARY', join_paths(prefix, get_option('bindir'), 
'pulseaudio'))
+cdata.set_quoted('PA_SYSTEM_RUNTIME_PATH', join_paths(localstatedir, 'run', 
'pulse'))
+cdata.set_quoted('PA_SYSTEM_CONFIG_PATH', join_paths(localstatedir, 'lib', 
'pulse'))
+cdata.set_quoted('PA_SYSTEM_STATE_PATH', join_paths(localstatedir, 'lib', 
'pulse'))
+cdata.set_quoted('PA_DLSEARCHPATH', join_paths(prefix, get_option('libdir'), 
'pulse-' + pa_version_major_minor, 'modules'))
+cdata.set_quoted('PA_SYSTEM_USER', get_option('system_user'))
+cdata.set_quoted('PA_SYSTEM_GROUP', get_option('system_group'))
+cdata.set_quoted('PA_ACCESS_GROUP', get_option('access_group'))
+cdata.set_quoted('PA_CFLAGS', 'Not yet supported on meson')
+cdata.set_quoted('PA_ALSA_PATHS_DIR', join_paths(datadir, 'pulseaudio', 
'alsa-mixer', 'paths'))
+cdata.set_quoted('PA_ALSA_PROFILE_SETS_DIR', join_paths(datadir, 'pulseaudio', 
'alsa-mixer', 'profile-sets'))
+cdata.set_quoted('DESKTOPFILEDIR', join_paths(datadir, 'applications'))
+
+# Headers
+
+check_headers = [
+  'arpa/inet.h',
+  'cpuid.h',
+  'grp.h',
+  'langinfo.h',
+  'locale.h',
+  'netdb.h',
+  'netinet/in.h',
+  'netinet/in_systm.h',
+  'netinet/ip.h',
+  'netinet/tcp.h',
+  'pcreposix.h',
+  'poll.h',
+  'pwd.h',
+  'regex.h',
+  'sched.h',
+  'sys/capability.h',
+  'sys/ioctl.h',
+  'sys/mman.h',
+  'sys/prctl.h',
+  'sys/resource.h',
+  'sys/select.h',
+  'sys/socket.h',
+  'sys/un.h',
+  'valgrind/memchec

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

[Arun Raghavan]

On Sat, 9 Dec 2017, at 10:58 PM, Felipe Sateler wrote:
> On Sat, Dec 9, 2017 at 2:59 AM, Arun Raghavan 
> wrote:
> > (Note: this patch depends on the symdef header removal work from a few
> > days ago)
> >
> > This is a working implementation of a build with meson. The server,
> > utils, and most modules build with this, and it is possible to run from
> > a build tree and play/capture audio on ALSA devices.
> >
> > There are a number of FIXMEs, of course, and a number of features that
> > need to be enabled (modules, dependencies, installation, etc.), but this
> > should provide everything we need to get there relatively quickly.
> >
> 
> This is nice. Build times should be greatly reduced. As a datapoint,
> you can check how the systemd debian package takes about hallf the
> time since version 234, when meson was introduced.
> 
> https://buildd.debian.org/status/logs.php?pkg=systemd&arch=amd64&suite=sid
> 
> > To use this, install meson (distro package, or mesonbuild.com) and run:
> >
> >   $ cd 
> >   $ meson 
> >   $ ninja -C 
> > ---
> >  meson.build   | 218 
> > ++
> >  meson_options.txt |  13 +++
> >  src/daemon/daemon-conf.c  |   4 +
> >  src/daemon/main.c |   9 ++
> >  src/daemon/meson.build|  34 ++
> >  src/meson.build   | 194 +
> >  src/modules/alsa/meson.build  |  31 ++
> >  src/modules/meson.build   | 127 ++
> >  src/modules/module-role-cork.c|   2 +-
> >  src/modules/module-role-ducking.c |   2 +-
> >  src/pulse/meson.build |  73 +
> >  src/pulsecore/meson.build | 170 +
> >  src/pulsecore/module.c|   4 +
> >  src/utils/meson.build |  67 
> >  14 files changed, 946 insertions(+), 2 deletions(-)
> >  create mode 100644 meson.build
> >  create mode 100644 meson_options.txt
> >  create mode 100644 src/daemon/meson.build
> >  create mode 100644 src/meson.build
> >  create mode 100644 src/modules/alsa/meson.build
> >  create mode 100644 src/modules/meson.build
> >  create mode 100644 src/pulse/meson.build
> >  create mode 100644 src/pulsecore/meson.build
> >  create mode 100644 src/utils/meson.build
> >
> > diff --git a/meson.build b/meson.build
> > new file mode 100644
> > index 0..1b00dc1e0
> > --- /dev/null
> > +++ b/meson.build
> > @@ -0,0 +1,218 @@
> > +project('pulseaudio', 'c', 'cpp',
> > +version : '10.99.1',
> > +meson_version : '>= 0.31.0',
> > +default_options : [ 'c_std=gnu11', 'cpp_std=c++11' ]
> > +)
> > +
> > +pa_version = meson.project_version()
> > +version_split = pa_version.split('.')
> > +pa_version_major = version_split[0]
> > +pa_version_minor = version_split[1]
> > +pa_version_micro = version_split[2]
> > +pa_version_major_minor = pa_version_major + '.' + pa_version_minor
> > +
> > +pa_api_version = 12
> > +pa_protocol_version = 31
> > +
> > +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.

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).
 
> > +
> > +prefix = get_option('prefix')
> > +datadir = join_paths(prefix, get_option('datadir'))
> > +localstatedir = join_paths(prefix, get_option('localstatedir'))
> > +sysconfdir = join_paths(prefix, get_option('sysconfdir'))
> > +
> > +cc = meson.get_compiler('c')
> > +
> > +cdata = configuration_data()
> > +cdata.set_quoted('PACKAGE', 'pulseaudio')
> > +cdata.set_quoted('PACKAGE_NAME', 'pulseaudio')
> > +cdata.set_quoted('PACKAGE_VERSION', pa_version)
> > +cdata.set_quoted('CANONICAL_HOST', host_machine.cpu())
> > 

Re: [pulseaudio-discuss] [PATCH] map-file: add pa_encoding_from_string

[Arun Raghavan]

On Tue, 12 Dec 2017, at 09:46 AM, Tanu Kaskinen wrote:
> The function is declared in pulse/format.h and it has Doxygen
> documentation, which tells me that the intention was to make the
> function available to clients.
> 
> BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=103806
> ---
>  src/map-file | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/src/map-file b/src/map-file
> index 93a62b860..9b6cba223 100644
> --- a/src/map-file
> +++ b/src/map-file
> @@ -151,6 +151,7 @@ pa_cvolume_snprint_verbose;
>  pa_cvolume_valid;
>  pa_direction_to_string;
>  pa_direction_valid;
> +pa_encoding_from_string;
>  pa_encoding_to_string;
>  pa_ext_device_manager_delete;
>  pa_ext_device_manager_enable_role_device_priority_routing;
> -- 

Looks good, thanks.

-- Arun
___
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

[Arun Raghavan]

On Tue, 12 Dec 2017, at 07:29 AM, Tanu Kaskinen wrote:
> On Sun, 2017-12-10 at 12:46 +0530, Arun Raghavan wrote:
> > On Sat, 9 Dec 2017, at 10:58 PM, Felipe Sateler wrote:
> > > On Sat, Dec 9, 2017 at 2:59 AM, Arun Raghavan 
> > > wrote:
> > > > (Note: this patch depends on the symdef header removal work from a few
> > > > days ago)
> > > > 
> > > > This is a working implementation of a build with meson. The server,
> > > > utils, and most modules build with this, and it is possible to run from
> > > > a build tree and play/capture audio on ALSA devices.
> > > > 
> > > > There are a number of FIXMEs, of course, and a number of features that
> > > > need to be enabled (modules, dependencies, installation, etc.), but this
> > > > should provide everything we need to get there relatively quickly.
> > > > 
> > > 
> > > This is nice. Build times should be greatly reduced. As a datapoint,
> > > you can check how the systemd debian package takes about hallf the
> > > time since version 234, when meson was introduced.
> > > 
> > > https://buildd.debian.org/status/logs.php?pkg=systemd&arch=amd64&suite=sid
> > > 
> > > > To use this, install meson (distro package, or mesonbuild.com) and run:
> > > > 
> > > >   $ cd 
> > > >   $ meson 
> > > >   $ ninja -C 
> > > > ---
> > > >  meson.build   | 218 
> > > > ++
> > > >  meson_options.txt |  13 +++
> > > >  src/daemon/daemon-conf.c  |   4 +
> > > >  src/daemon/main.c |   9 ++
> > > >  src/daemon/meson.build|  34 ++
> > > >  src/meson.build   | 194 
> > > > +
> > > >  src/modules/alsa/meson.build  |  31 ++
> > > >  src/modules/meson.build   | 127 ++
> > > >  src/modules/module-role-cork.c|   2 +-
> > > >  src/modules/module-role-ducking.c |   2 +-
> > > >  src/pulse/meson.build |  73 +
> > > >  src/pulsecore/meson.build | 170 +
> > > >  src/pulsecore/module.c|   4 +
> > > >  src/utils/meson.build |  67 
> > > >  14 files changed, 946 insertions(+), 2 deletions(-)
> > > >  create mode 100644 meson.build
> > > >  create mode 100644 meson_options.txt
> > > >  create mode 100644 src/daemon/meson.build
> > > >  create mode 100644 src/meson.build
> > > >  create mode 100644 src/modules/alsa/meson.build
> > > >  create mode 100644 src/modules/meson.build
> > > >  create mode 100644 src/pulse/meson.build
> > > >  create mode 100644 src/pulsecore/meson.build
> > > >  create mode 100644 src/utils/meson.build
> > > > 
> > > > diff --git a/meson.build b/meson.build
> > > > new file mode 100644
> > > > index 0..1b00dc1e0
> > > > --- /dev/null
> > > > +++ b/meson.build
> > > > @@ -0,0 +1,218 @@
> > > > +project('pulseaudio', 'c', 'cpp',
> > > > +version : '10.99.1',
> > > > +meson_version : '>= 0.31.0',
> > > > +default_options : [ 'c_std=gnu11', 'cpp_std=c++11' ]
> > > > +)
> > > > +
> > > > +pa_version = meson.project_version()
> > > > +version_split = pa_version.split('.')
> > > > +pa_version_major = version_split[0]
> > > > +pa_version_minor = version_split[1]
> > > > +pa_version_micro = version_split[2]
> > > > +pa_version_major_minor = pa_version_major + '.' + pa_version_minor
> > > > +
> > > > +pa_api_version = 12
> > > > +pa_protocol_version = 31
> > > > +
> > > > +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 

Re: [pulseaudio-discuss] [PATCH] build-sys: Stop using symdef headers for modules

[Arun Raghavan]

On Sat, 9 Dec 2017, at 01:19 PM, Tanu Kaskinen wrote:
> On Thu, 2017-12-07 at 05:39 +0530, Arun Raghavan wrote:
> > This removes the symdef header generation m4 magic in favour of a
> > simpler macro method, allowing us to skip one unnecessary build step
> > while moving to meson, and removing an 11 year old todo!
> > ---
> >  src/.gitignore|   1 -
> >  src/Makefile.am   | 271 
> > --
> >  src/modules/alsa/module-alsa-card.c   |   1 -
> >  src/modules/alsa/module-alsa-sink.c   |   1 -
> >  src/modules/alsa/module-alsa-source.c |   1 -
> >  src/modules/bluetooth/module-bluetooth-discover.c |   2 -
> >  src/modules/bluetooth/module-bluetooth-policy.c   |   2 -
> >  src/modules/bluetooth/module-bluez4-device.c  |   1 -
> >  src/modules/bluetooth/module-bluez4-discover.c|   1 -
> >  src/modules/bluetooth/module-bluez5-device.c  |   2 -
> >  src/modules/bluetooth/module-bluez5-discover.c|   2 -
> >  src/modules/dbus/module-dbus-protocol.c   |   2 -
> >  src/modules/echo-cancel/module-echo-cancel.c  |   2 -
> >  src/modules/gconf/module-gconf.c  |   2 -
> >  src/modules/jack/module-jack-sink.c   |   2 -
> >  src/modules/jack/module-jack-source.c |   2 -
> >  src/modules/jack/module-jackdbus-detect.c |   2 -
> >  src/modules/macosx/module-bonjour-publish.c   |   2 -
> >  src/modules/macosx/module-coreaudio-detect.c  |   2 -
> >  src/modules/macosx/module-coreaudio-device.c  |   2 -
> >  src/modules/module-allow-passthrough.c|   2 -
> >  src/modules/module-always-sink.c  |   2 -
> >  src/modules/module-always-source.c|   2 -
> >  src/modules/module-augment-properties.c   |   2 -
> >  src/modules/module-card-restore.c |   2 -
> >  src/modules/module-cli.c  |   2 -
> >  src/modules/module-combine-sink.c |   2 -
> >  src/modules/module-combine.c  |   2 -
> >  src/modules/module-console-kit.c  |   2 -
> >  src/modules/module-default-device-restore.c   |   2 -
> >  src/modules/module-defs.h.m4  |  35 ---
> >  src/modules/module-detect.c   |   2 -
> >  src/modules/module-device-manager.c   |   2 -
> >  src/modules/module-device-restore.c   |   2 -
> >  src/modules/module-equalizer-sink.c   |   2 -
> >  src/modules/module-esound-compat-spawnfd.c|   2 -
> >  src/modules/module-esound-compat-spawnpid.c   |   2 -
> >  src/modules/module-esound-sink.c  |   2 -
> >  src/modules/module-filter-apply.c |   2 -
> >  src/modules/module-filter-heuristics.c|   2 -
> >  src/modules/module-hal-detect-compat.c|   2 -
> >  src/modules/module-intended-roles.c   |   2 -
> >  src/modules/module-ladspa-sink.c  |   1 -
> >  src/modules/module-lirc.c |   2 -
> >  src/modules/module-loopback.c |   2 -
> >  src/modules/module-match.c|   2 -
> >  src/modules/module-mmkbd-evdev.c  |   2 -
> >  src/modules/module-native-protocol-fd.c   |   2 -
> >  src/modules/module-null-sink.c|   2 -
> >  src/modules/module-null-source.c  |   2 -
> >  src/modules/module-pipe-sink.c|   2 -
> >  src/modules/module-pipe-source.c  |   2 -
> >  src/modules/module-position-event-sounds.c|   2 -
> >  src/modules/module-protocol-stub.c|  30 ---
> >  src/modules/module-remap-sink.c   |   2 -
> >  src/modules/module-remap-source.c |   2 -
> >  src/modules/module-rescue-streams.c   |   2 -
> >  src/modules/module-role-cork.c|   2 -
> >  src/modules/module-role-ducking.c |   2 -
> >  src/modules/module-rygel-media-server.c   |   2 -
> >  src/modules/module-sine-source.c  |   2 -
> >  src/modules/module-sine.c |   2 -
> >  src/modules/module-solaris.c  |   2 -
> >  src/modules/module-stream-restore.c   |   2 -
> >  src/modules/module-suspend-on-idle.c  |   2 -
> >  src/modules/module-switch-on-connect.c|   2 -
> >  src/modules/module-switch-on-port-availab

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

[Arun Raghavan]

On Tue, 12 Dec 2017, at 07:00 PM, Felipe Sateler wrote:
> On Sun, Dec 10, 2017 at 4:16 AM, Arun Raghavan 
> wrote:
> > On Sat, 9 Dec 2017, at 10:58 PM, Felipe Sateler wrote:
> >> On Sat, Dec 9, 2017 at 2:59 AM, Arun Raghavan 
> >> 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 :)

I'm not sure what the right fix is, so in the mean time I'm going to
make a FIXME of it.

> > 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.

I agree that it's a bug, and I think that's okay to fix subsequently if
it's something non-trivial. In the case of the above, we should figure
out what's needed to not break clients, and how other projects are
handling this.

> >> > +
> >> > +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.

Exactly.

> >
> > 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

So we'd basically wrap the entire executable() in if x11_dep.found(), I
guess.

-- Arun
___
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

[Arun Raghavan]

On Wed, 13 Dec 2017, at 12:10 PM, Tanu Kaskinen wrote:
> On Tue, 2017-12-12 at 09:47 +0530, Arun Raghavan 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:
> > > > On Sat, 9 Dec 2017, at 10:58 PM, Felipe Sateler wrote:
> > > > > On Sat, Dec 9, 2017 at 2:59 AM, Arun Raghavan 
> > > > > wrote:
> > > > > > (Note: this patch depends on the symdef header removal work from a 
> > > > > > few
> > > > > > days ago)
> > > > > > 
> > > > > > This is a working implementation of a build with meson. The server,
> > > > > > utils, and most modules build with this, and it is possible to run 
> > > > > > from
> > > > > > a build tree and play/capture audio on ALSA devices.
> > > > > > 
> > > > > > There are a number of FIXMEs, of course, and a number of features 
> > > > > > that
> > > > > > need to be enabled (modules, dependencies, installation, etc.), but 
> > > > > > this
> > > > > > should provide everything we need to get there relatively quickly.
> > > > > > 
> > > > > 
> > > > > This is nice. Build times should be greatly reduced. As a datapoint,
> > > > > you can check how the systemd debian package takes about hallf the
> > > > > time since version 234, when meson was introduced.
> > > > > 
> > > > > https://buildd.debian.org/status/logs.php?pkg=systemd&arch=amd64&suite=sid
> > > > > 
> > > > > > To use this, install meson (distro package, or mesonbuild.com) and 
> > > > > > run:
> > > > > > 
> > > > > >   $ cd 
> > > > > >   $ meson 
> > > > > >   $ ninja -C 
> > > > > > ---
> > > > > >  meson.build   | 218 
> > > > > > ++
> > > > > >  meson_options.txt |  13 +++
> > > > > >  src/daemon/daemon-conf.c  |   4 +
> > > > > >  src/daemon/main.c |   9 ++
> > > > > >  src/daemon/meson.build|  34 ++
> > > > > >  src/meson.build   | 194 
> > > > > > +
> > > > > >  src/modules/alsa/meson.build  |  31 ++
> > > > > >  src/modules/meson.build   | 127 ++
> > > > > >  src/modules/module-role-cork.c|   2 +-
> > > > > >  src/modules/module-role-ducking.c |   2 +-
> > > > > >  src/pulse/meson.build |  73 +
> > > > > >  src/pulsecore/meson.build | 170 
> > > > > > +
> > > > > >  src/pulsecore/module.c|   4 +
> > > > > >  src/utils/meson.build |  67 
> > > > > >  14 files changed, 946 insertions(+), 2 deletions(-)
> > > > > >  create mode 100644 meson.build
> > > > > >  create mode 100644 meson_options.txt
> > > > > >  create mode 100644 src/daemon/meson.build
> > > > > >  create mode 100644 src/meson.build
> > > > > >  create mode 100644 src/modules/alsa/meson.build
> > > > > >  create mode 100644 src/modules/meson.build
> > > > > >  create mode 100644 src/pulse/meson.build
> > > > > >  create mode 100644 src/pulsecore/meson.build
> > > > > >  create mode 100644 src/utils/meson.build
> > > > > > 
> > > > > > diff --git a/meson.build b/meson.build
> > > > > > new file mode 100644
> > > > > > index 0..1b00dc1e0
> > > > > > --- /dev/null
> > > > > > +++ b/meson.build
> > > > > > @@ -0,0 +1,218 @@
> > > > > > +project('pulseaudio', 'c', 'cpp',
> > > > > > +version : '10.99.1',
> > > > > > +meson_version : '>= 0.31.0',
> > > > > > +default_options : [ 'c_std=gnu11', 'cpp_std=c++11' ]
> > > > > > +)
> > > > > > +
> > > > > > +pa_version = meson.project_version()

Re: [pulseaudio-discuss] webrtc compile problem

[Arun Raghavan]

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(&mutex_, &mutex_attribute);
>     ^~
> criticalsection.cc: In destructor 
> 'rtc::CriticalSection::~CriticalSection()':
> criticalsection.cc:35:26: error: 'mutex_' was not declared in this scope
>     pthread_mutex_destroy(&mutex_);
>    ^~
> criticalsection.cc: In member function 'void rtc::CriticalSection::Enter()':
> criticalsection.cc:43:23: error: 'mutex_' was not declared in this scope
>     pthread_mutex_lock(&mutex_);
>     ^~
> 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(&mutex_) != 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(&mutex_);
>   ^~
> *** 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).

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

Re: [pulseaudio-discuss] Pulseaudio moulde echo-cancellation: Initialization failed

[Arun Raghavan]

On Mon, 29 Jan 2018, at 10:38 AM, Vimal Babu wrote:
> Hi All,
> 
> A help is needed, I am trying to used echo-cancellation module of pulse 
> audio, but is failing. What is the proper method to call echo-
> cancellation, what are the necessary arguments that are to be given.
> 
> Please specify the pactl command for that or line that should be added 
> in default.pa, if possible please provide separate commands for the 
> supported aec_method.

Could you share the server side error messages that you are seeing?

> Regards,
> Vimal Babu
> 
> 
> Confidentiality Statement / Disclaimer : This message and any 
> attachments is intended for the sole use of the intended recipient. It 
> may contain confidential information. Any unauthorized use, 
> dissemination or modification is strictly prohibited. If you are not the 
> intended recipient, please notify the sender immediately then delete it 
> from all your systems, and do not copy, use or print. Internet 
> communications are not secure and it is the responsibility of the 
> recipient to make sure that it is virus/malicious code exempt.
> 
> The company/sender cannot be responsible for any unauthorized 
> alterations or modifications made to the contents. If you require any 
> form of confirmation of the contents, please contact the company/sender. 
> The company/sender is not liable for any errors or omissions in the 
> content of this message.

Please avoid sending these footers. I understand your company might add these 
automatically, but it is considered poor public mailing list etiquette to have 
these.

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

Re: [pulseaudio-discuss] [PATCH v2 2/3] alsa-mixer: autodetect the HDMI jack PCM device

[Arun Raghavan]

On Sun, 8 Oct 2017, at 10:18 PM, Tanu Kaskinen wrote:
> This removes the need to hardcode the PCM device index in the HDMI jack
> names. The hardcoded values don't work with the Intel HDMI LPE driver.
> 
> BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=100488
> ---
>  src/modules/alsa/alsa-mixer.c  | 53 
> --
>  src/modules/alsa/alsa-mixer.h  |  4 +-
>  src/modules/alsa/alsa-sink.c   |  2 +-
>  src/modules/alsa/alsa-source.c |  2 +-
>  .../alsa/mixer/paths/analog-output.conf.common |  4 ++
>  src/modules/alsa/mixer/paths/hdmi-output-0.conf|  3 +-
>  src/modules/alsa/mixer/paths/hdmi-output-1.conf|  3 +-
>  src/modules/alsa/mixer/paths/hdmi-output-2.conf|  3 +-
>  src/modules/alsa/mixer/paths/hdmi-output-3.conf|  3 +-
>  src/modules/alsa/mixer/paths/hdmi-output-4.conf|  3 +-
>  src/modules/alsa/mixer/paths/hdmi-output-5.conf|  3 +-
>  src/modules/alsa/mixer/paths/hdmi-output-6.conf|  3 +-
>  src/modules/alsa/mixer/paths/hdmi-output-7.conf|  3 +-
>  13 files changed, 73 insertions(+), 16 deletions(-)
> 
> diff --git a/src/modules/alsa/alsa-mixer.c b/src/modules/alsa/alsa-
> mixer.c
> index 02ab4a611..eaee7ea0a 100644
> --- a/src/modules/alsa/alsa-mixer.c
> +++ b/src/modules/alsa/alsa-mixer.c
> @@ -1812,12 +1812,31 @@ static int element_probe(pa_alsa_element *e, 
> snd_mixer_t *m) {
>  return 0;
>  }
>  
> -static int jack_probe(pa_alsa_jack *j, snd_mixer_t *m) {
> +static int jack_probe(pa_alsa_jack *j, pa_alsa_mapping *mapping, 
> snd_mixer_t *m) {
>  bool has_control;
>  
>  pa_assert(j);
>  pa_assert(j->path);
>  
> +if (j->append_pcm_to_name) {
> +char *new_name;
> +
> +if (!mapping) {
> +/* This could also be an assertion, because this should 
> never
> + * happen. At the time of writing, mapping can only be NULL 
> when
> + * module-alsa-sink/source synthesizes a path, and those
> + * synthesized paths never have any jacks, so jack_probe() 
> should
> + * never be called with a NULL mapping. */
> +pa_log("Jack %s: append_pcm_to_name is set, but mapping is 
> NULL. Can't use this jack.", j->name);
> +return -1;
> +}
> +
> +new_name = pa_sprintf_malloc("%s,pcm=%i Jack", j->name, 
> mapping->hw_device_index);
> +pa_xfree(j->alsa_name);
> +j->alsa_name = new_name;
> +j->append_pcm_to_name = false;

Series looks good to me. Just one question -- why do we reset 
append_pcm_to_name here? Presumably because jack_probe() is called multiple 
times on the jack? Or are you being defensive here?

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

Re: [pulseaudio-discuss] State of the WebRTC AudioProcessing library?

[Arun Raghavan]

Hey Tomaž

On Mon, 12 Mar 2018, at 2:58 PM, Tomaž Šolc wrote:
> Dear all,
> 
> I've been recently looking into echo cancellation with Pulse Audio. 
> Unfortunately, the current module-echo-cancel doesn't work well for my 
> use case. I've looked into how to improve it and found that the echo 
> canceling code in the WebRTC AudioProcessing library has been copied 
> from webrtc and hasn't been updated since 2016.
> 
> https://www.freedesktop.org/software/pulseaudio/webrtc-audio-processing/
> 
> On the other hand, it seems that audio processing code is very actively 
> developed in the webrtc upstream.
> 
> https://webrtc.googlesource.com/src/+log/master/modules/audio_processing
> 
> My question is about the state of WebRTC AudioProcessing library. Has it 
> been deprecated or are there any plans to keep updating the code from 
> upstream? I might spend some time trying to get the latest webrtc code 
> running in a Pulse Audio module. If I manage to update the library, 
> would you be interested in a patch?

I'm definitely up for updates to the library. The UPDATING.md file has some 
rudimentary instructions on what you need. I've got an intermediate update 
sitting on my laptop, you can find it at:

  https://github.com/ford-prefect/webrtc-audio-processing

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

Re: [pulseaudio-discuss] [PATCH] Fix memory leaks

[Arun Raghavan]

On Wed, 14 Mar 2018, at 11:58 AM, Jungsup Lee wrote:
> The returned string of the dbus_message_iter_get_signature() must be 
> freed with dbus_free().
> ---
>  src/modules/module-stream-restore.c | 8 +++-
>  src/pulsecore/dbus-util.c   | 8 +++-
>  2 files changed, 14 insertions(+), 2 deletions(-)
> 
> diff --git a/src/modules/module-stream-restore.c b/src/modules/module-
> stream-restore.c
> index 7ee53340..162d5fef 100644
> --- a/src/modules/module-stream-restore.c
> +++ b/src/modules/module-stream-restore.c
> @@ -346,14 +346,20 @@ static void dbus_entry_free(struct dbus_entry *de) 
> {
>  static int get_volume_arg(DBusConnection *conn, DBusMessage *msg, 
> DBusMessageIter *iter, pa_channel_map *map, pa_cvolume *vol) {
>  DBusMessageIter array_iter;
>  DBusMessageIter struct_iter;
> +char *signature;
>  
>  pa_assert(conn);
>  pa_assert(msg);
>  pa_assert(iter);
> -pa_assert(pa_streq(dbus_message_iter_get_signature(iter), "a(uu)"));
>  pa_assert(map);
>  pa_assert(vol);
>  
> +signature = dbus_message_iter_get_signature(iter);
> +pa_assert(pa_streq(signature, "a(uu)"));
> +
> +if (signature)
> +dbus_free(signature);
> +
>  pa_channel_map_init(map);
>  pa_cvolume_init(vol);
>  
> diff --git a/src/pulsecore/dbus-util.c b/src/pulsecore/dbus-util.c
> index 80e2866e..8053dacf 100644
> --- a/src/pulsecore/dbus-util.c
> +++ b/src/pulsecore/dbus-util.c
> @@ -735,6 +735,7 @@ void 
> pa_dbus_append_proplist_variant_dict_entry(DBusMessageIter *dict_iter, 
> cons
>  pa_proplist *pa_dbus_get_proplist_arg(DBusConnection *c, DBusMessage 
> *msg, DBusMessageIter *iter) {
>  DBusMessageIter dict_iter;
>  DBusMessageIter dict_entry_iter;
> +char *signature;
>  pa_proplist *proplist = NULL;
>  const char *key = NULL;
>  const uint8_t *value = NULL;
> @@ -743,7 +744,12 @@ pa_proplist 
> *pa_dbus_get_proplist_arg(DBusConnection *c, DBusMessage *msg, DBusM
>  pa_assert(c);
>  pa_assert(msg);
>  pa_assert(iter);
> -pa_assert(pa_streq(dbus_message_iter_get_signature(iter), 
> "a{say}"));
> +
> +signature = dbus_message_iter_get_signature(iter);
> +pa_assert(pa_streq(signature, "a{say}"));
> +
> +if (signature)
> +dbus_free(signature);
>  
>  proplist = pa_proplist_new();
>  
> -- 

Looks good. Would you also like to fix up src/pulsecore/protocol-dbus.c (seems 
like there may be more leaks there)?

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

[pulseaudio-discuss] [PATCH] core: Expose API to elevate a thread to realtime priority

[Arun Raghavan]

This should make it easier for clients to elevate their audio threads to
real time priority without having to dig through much through specific
system internals.
---
 src/modules/alsa/alsa-sink.c |   3 +-
 src/modules/alsa/alsa-source.c   |   3 +-
 src/modules/bluetooth/module-bluez5-device.c |   2 +-
 src/modules/jack/module-jack-sink.c  |   4 +-
 src/modules/jack/module-jack-source.c|   4 +-
 src/modules/macosx/module-coreaudio-device.c |   2 +-
 src/modules/module-combine-sink.c|   3 +-
 src/modules/module-solaris.c |   2 +-
 src/modules/module-waveout.c |   2 +-
 src/modules/oss/module-oss.c |   2 +-
 src/pulse/util.c | 176 +++
 src/pulse/util.h |   3 +
 src/pulsecore/core-util.c| 171 +-
 src/pulsecore/core-util.h|   1 -
 src/tests/lo-test-util.c |   2 +-
 src/tests/rtstutter.c|   2 +-
 16 files changed, 198 insertions(+), 184 deletions(-)

diff --git a/src/modules/alsa/alsa-sink.c b/src/modules/alsa/alsa-sink.c
index eb79a444a..ed9e0a51c 100644
--- a/src/modules/alsa/alsa-sink.c
+++ b/src/modules/alsa/alsa-sink.c
@@ -33,6 +33,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1780,7 +1781,7 @@ static void thread_func(void *userdata) {
 pa_log_debug("Thread starting up");
 
 if (u->core->realtime_scheduling)
-pa_make_realtime(u->core->realtime_priority);
+pa_thread_make_realtime(u->core->realtime_priority);
 
 pa_thread_mq_install(&u->thread_mq);
 
diff --git a/src/modules/alsa/alsa-source.c b/src/modules/alsa/alsa-source.c
index ca85968e6..31d5bb321 100644
--- a/src/modules/alsa/alsa-source.c
+++ b/src/modules/alsa/alsa-source.c
@@ -29,6 +29,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -1504,7 +1505,7 @@ static void thread_func(void *userdata) {
 pa_log_debug("Thread starting up");
 
 if (u->core->realtime_scheduling)
-pa_make_realtime(u->core->realtime_priority);
+pa_thread_make_realtime(u->core->realtime_priority);
 
 pa_thread_mq_install(&u->thread_mq);
 
diff --git a/src/modules/bluetooth/module-bluez5-device.c 
b/src/modules/bluetooth/module-bluez5-device.c
index dfae682d9..1944f3615 100644
--- a/src/modules/bluetooth/module-bluez5-device.c
+++ b/src/modules/bluetooth/module-bluez5-device.c
@@ -1428,7 +1428,7 @@ static void thread_func(void *userdata) {
 pa_log_debug("IO Thread starting up");
 
 if (u->core->realtime_scheduling)
-pa_make_realtime(u->core->realtime_priority);
+pa_thread_make_realtime(u->core->realtime_priority);
 
 pa_thread_mq_install(&u->thread_mq);
 
diff --git a/src/modules/jack/module-jack-sink.c 
b/src/modules/jack/module-jack-sink.c
index eb1d1b15b..a4be786cf 100644
--- a/src/modules/jack/module-jack-sink.c
+++ b/src/modules/jack/module-jack-sink.c
@@ -224,7 +224,7 @@ static void thread_func(void *userdata) {
 pa_log_debug("Thread starting up");
 
 if (u->core->realtime_scheduling)
-pa_make_realtime(u->core->realtime_priority);
+pa_thread_make_realtime(u->core->realtime_priority);
 
 pa_thread_mq_install(&u->thread_mq);
 
@@ -267,7 +267,7 @@ static void jack_init(void *arg) {
 pa_log_info("JACK thread starting up.");
 
 if (u->core->realtime_scheduling)
-pa_make_realtime(u->core->realtime_priority+4);
+pa_thread_make_realtime(u->core->realtime_priority+4);
 }
 
 /* JACK Callback: This is called when JACK kicks us */
diff --git a/src/modules/jack/module-jack-source.c 
b/src/modules/jack/module-jack-source.c
index 43cb0e15d..fa6896b1e 100644
--- a/src/modules/jack/module-jack-source.c
+++ b/src/modules/jack/module-jack-source.c
@@ -187,7 +187,7 @@ static void thread_func(void *userdata) {
 pa_log_debug("Thread starting up");
 
 if (u->core->realtime_scheduling)
-pa_make_realtime(u->core->realtime_priority);
+pa_thread_make_realtime(u->core->realtime_priority);
 
 pa_thread_mq_install(&u->thread_mq);
 
@@ -225,7 +225,7 @@ static void jack_init(void *arg) {
 pa_log_info("JACK thread starting up.");
 
 if (u->core->realtime_scheduling)
-pa_make_realtime(u->core->realtime_priority+4);
+pa_thread_make_realtime(u->core->realtime_priority+4);
 }
 
 static void jack_shutdown(void* arg) {
diff --git a/src/modules/macosx/module-coreaudio-device.c 
b/src/modules/macosx/module-coreaudio-device.c
index 149109d4f..b9dffb937 100644
--- a/src/modules/macosx/module-coreaudio-device.c
+++ b/src/modules/macosx/module-coreaudio-device.c
@@ -722,7 +722,7 @@ static void thread_func(void *userdata) {
 pa_log_debug("Thread starting up");
 
 if (u->module->core->realtime_scheduling)
-pa_make_realtime(u->module->core->realtime_priority);
+pa_thread_make_realti

Re: [pulseaudio-discuss] [paprefs][PATCH 0/9] Convert to GSettings

[Arun Raghavan]

On Tue, 17 Apr 2018, at 11:55 AM, Tanu Kaskinen wrote:
> Here are the paprefs patches for the GConf -> GSettings migration.
> Felipe's GTK3 patch is included as well, because I think the GTK2 stuff
> is being removed at the same time with GConf, at least in Debian.
> 
> I rebased Sylvain's and Felipe's patches on the current master, and
> those patches don't necessarily need to be reviewed because I already
> reviewed them.
> 
> Felipe Sateler (1):
>   Port from GTK2 to GTK3
> 
> Sylvain Baubeau (2):
>   Move from GConf to GSettings
>   Run gsettings-data-convert at startup if needed
> 
> Tanu Kaskinen (6):
>   build-sys: remove the gconf dependency
>   README: remove references to module-gconf
>   remove the GSettings schema file
>   rename "module" to "module-group" in GSettings schemas and paths
>   fix GSettings pkg-config dependency
>   run gsettings-data-convert unconditionally
> 
>  configure.ac|   6 +-
>  doc/README.html.in  |   8 +-
>  src/Makefile.am |   9 +-
>  src/paprefs.cc  | 427 
> 
>  src/paprefs.convert | 160 
>  src/paprefs.glade   | 224 +--
>  6 files changed, 509 insertions(+), 325 deletions(-)
>  create mode 100644 src/paprefs.convert
> 
> -- 

Patch set looks good to me.

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

Re: [pulseaudio-discuss] [paprefs][PATCH 0/2] Remaining gsettings patches for paprefs

[Arun Raghavan]

On Mon, 23 Apr 2018, at 6:57 PM, Tanu Kaskinen wrote:
> The first patch is new, it drops paprefs.convert, because pulseaudio
> does the gconf -> gsettings conversion.
> 
> The second patch had to be rebased, because it used to modify
> paprefs.convert. There are no changes in the patch compared to the
> previously sent (and reviewed) patch, except that the paprefs.convert
> changes have been removed.
> 
> Tanu Kaskinen (2):
>   remove paprefs.convert
>   rename "module" to "module-group" in GSettings schemas and paths
> 
>  src/Makefile.am |   5 +-
>  src/paprefs.cc  |  31 -
>  src/paprefs.convert | 160 
>  3 files changed, 17 insertions(+), 179 deletions(-)
>  delete mode 100644 src/paprefs.convert
> 
> -- 

Please go ahead and push these too.

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

Re: [pulseaudio-discuss] [PATCH] core: Expose API to elevate a thread to realtime priority

[Arun Raghavan]

On Sat, 21 Apr 2018, at 3:53 PM, Georg Chini wrote:
> On 21.04.2018 06:21, Arun Raghavan wrote:
> > This should make it easier for clients to elevate their audio threads to
> > real time priority without having to dig through much through specific
> > system internals.
> > ---
> >   src/modules/alsa/alsa-sink.c |   3 +-
> >   src/modules/alsa/alsa-source.c   |   3 +-
> >   src/modules/bluetooth/module-bluez5-device.c |   2 +-
> >   src/modules/jack/module-jack-sink.c  |   4 +-
> >   src/modules/jack/module-jack-source.c|   4 +-
> >   src/modules/macosx/module-coreaudio-device.c |   2 +-
> >   src/modules/module-combine-sink.c|   3 +-
> >   src/modules/module-solaris.c |   2 +-
> >   src/modules/module-waveout.c |   2 +-
> >   src/modules/oss/module-oss.c |   2 +-
> >   src/pulse/util.c | 176 
> > +++
> >   src/pulse/util.h |   3 +
> >   src/pulsecore/core-util.c| 171 
> > +-
> >   src/pulsecore/core-util.h|   1 -
> >   src/tests/lo-test-util.c |   2 +-
> >   src/tests/rtstutter.c|   2 +-
> >   16 files changed, 198 insertions(+), 184 deletions(-)
> >
> >
> > diff --git a/src/pulsecore/core-util.h b/src/pulsecore/core-util.h
> > index e28b6aa7c..32579739b 100644
> > --- a/src/pulsecore/core-util.h
> > +++ b/src/pulsecore/core-util.h
> > @@ -81,7 +81,6 @@ char *pa_strlcpy(char *b, const char *s, size_t l);
> >   
> >   char *pa_parent_dir(const char *fn);
> >   
> > -int pa_make_realtime(int rtprio);
> >   int pa_raise_priority(int nice_level);
> >   void pa_reset_priority(void);
> >   
> 
> Should pa_raise_priority() and pa_reset_priority() also be moved to util.c?
> I think, if a client can make a thread real time it should also be able to
> reset the priority to normal.
> Otherwise LGTM.

I didn't move those because it looked like they might not cover all the OSes 
that pa_make_realtime() did. I figured we could move that if there was a 
request for it (after first updating those).

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

[pulseaudio-discuss] [PATCH] core: Expose API to elevate a thread to realtime priority

[Arun Raghavan]

This should make it easier for clients to elevate their audio threads to
real time priority without having to dig through much through specific
system internals.
---
 src/map-file |   1 +
 src/modules/alsa/alsa-sink.c |   3 +-
 src/modules/alsa/alsa-source.c   |   3 +-
 src/modules/bluetooth/module-bluez5-device.c |   3 +-
 src/modules/jack/module-jack-sink.c  |   5 +-
 src/modules/jack/module-jack-source.c|   5 +-
 src/modules/macosx/module-coreaudio-device.c |   2 +-
 src/modules/module-combine-sink.c|   3 +-
 src/modules/module-solaris.c |   2 +-
 src/modules/module-waveout.c |   2 +-
 src/modules/oss/module-oss.c |   2 +-
 src/pulse/util.c | 176 +++
 src/pulse/util.h |   6 +
 src/pulsecore/core-util.c| 171 +-
 src/pulsecore/core-util.h|   1 -
 src/tests/lo-test-util.c |   2 +-
 src/tests/rtstutter.c|   2 +-
 17 files changed, 205 insertions(+), 184 deletions(-)

diff --git a/src/map-file b/src/map-file
index 9b6cba223..7c1216ea4 100644
--- a/src/map-file
+++ b/src/map-file
@@ -225,6 +225,7 @@ pa_mainloop_run;
 pa_mainloop_set_poll_func;
 pa_mainloop_wakeup;
 pa_msleep;
+pa_thread_make_realtime
 pa_operation_cancel;
 pa_operation_get_state;
 pa_operation_ref;
diff --git a/src/modules/alsa/alsa-sink.c b/src/modules/alsa/alsa-sink.c
index eb79a444a..ed9e0a51c 100644
--- a/src/modules/alsa/alsa-sink.c
+++ b/src/modules/alsa/alsa-sink.c
@@ -33,6 +33,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1780,7 +1781,7 @@ static void thread_func(void *userdata) {
 pa_log_debug("Thread starting up");
 
 if (u->core->realtime_scheduling)
-pa_make_realtime(u->core->realtime_priority);
+pa_thread_make_realtime(u->core->realtime_priority);
 
 pa_thread_mq_install(&u->thread_mq);
 
diff --git a/src/modules/alsa/alsa-source.c b/src/modules/alsa/alsa-source.c
index ca85968e6..31d5bb321 100644
--- a/src/modules/alsa/alsa-source.c
+++ b/src/modules/alsa/alsa-source.c
@@ -29,6 +29,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -1504,7 +1505,7 @@ static void thread_func(void *userdata) {
 pa_log_debug("Thread starting up");
 
 if (u->core->realtime_scheduling)
-pa_make_realtime(u->core->realtime_priority);
+pa_thread_make_realtime(u->core->realtime_priority);
 
 pa_thread_mq_install(&u->thread_mq);
 
diff --git a/src/modules/bluetooth/module-bluez5-device.c 
b/src/modules/bluetooth/module-bluez5-device.c
index dfae682d9..edabb9006 100644
--- a/src/modules/bluetooth/module-bluez5-device.c
+++ b/src/modules/bluetooth/module-bluez5-device.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -1428,7 +1429,7 @@ static void thread_func(void *userdata) {
 pa_log_debug("IO Thread starting up");
 
 if (u->core->realtime_scheduling)
-pa_make_realtime(u->core->realtime_priority);
+pa_thread_make_realtime(u->core->realtime_priority);
 
 pa_thread_mq_install(&u->thread_mq);
 
diff --git a/src/modules/jack/module-jack-sink.c 
b/src/modules/jack/module-jack-sink.c
index eb1d1b15b..effa0dd01 100644
--- a/src/modules/jack/module-jack-sink.c
+++ b/src/modules/jack/module-jack-sink.c
@@ -29,6 +29,7 @@
 
 #include 
 
+#include 
 #include 
 
 #include 
@@ -224,7 +225,7 @@ static void thread_func(void *userdata) {
 pa_log_debug("Thread starting up");
 
 if (u->core->realtime_scheduling)
-pa_make_realtime(u->core->realtime_priority);
+pa_thread_make_realtime(u->core->realtime_priority);
 
 pa_thread_mq_install(&u->thread_mq);
 
@@ -267,7 +268,7 @@ static void jack_init(void *arg) {
 pa_log_info("JACK thread starting up.");
 
 if (u->core->realtime_scheduling)
-pa_make_realtime(u->core->realtime_priority+4);
+pa_thread_make_realtime(u->core->realtime_priority+4);
 }
 
 /* JACK Callback: This is called when JACK kicks us */
diff --git a/src/modules/jack/module-jack-source.c 
b/src/modules/jack/module-jack-source.c
index 43cb0e15d..eaf2cd81c 100644
--- a/src/modules/jack/module-jack-source.c
+++ b/src/modules/jack/module-jack-source.c
@@ -29,6 +29,7 @@
 
 #include 
 
+#include 
 #include 
 
 #include 
@@ -187,7 +188,7 @@ static void thread_func(void *userdata) {
 pa_log_debug("Thread starting up");
 
 if (u->core->realtime_scheduling)
-pa_make_realtime(u->core->realtime_priority);
+pa_thread_make_realtime(u->core->realtime_priority);
 
 pa_thread_mq_install(&u->thread_mq);
 
@@ -225,7 +226,7 @@ static void jack_init(void *arg) {
 pa_log_info("JACK thread starting up.");
 
 if (u->core->realtime_scheduling)
-pa_make_realtime(u->core->realtime_priority+4);
+pa_thread_make_realtime(u

[pulseaudio-discuss] [PATCH] module-allow-passthrough: Don't crash if we can't find a sink

[Arun Raghavan]

module-allow-passthrough has a (necessary) hack to replicate the default
sink selection and format negotiation from sink-input.c. One thing that
got missed in this replication is the possibility that the sink input is
not compatible with the default sink. When this happen, we now exit
gracefully.

Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=105578
---
 src/modules/module-allow-passthrough.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/src/modules/module-allow-passthrough.c 
b/src/modules/module-allow-passthrough.c
index 16b421d79..f7c61559b 100644
--- a/src/modules/module-allow-passthrough.c
+++ b/src/modules/module-allow-passthrough.c
@@ -184,6 +184,12 @@ static pa_hook_result_t sink_input_new_cb(pa_core *core, 
pa_sink_input_new_data
 if (!new_data->format && new_data->nego_formats && 
!pa_idxset_isempty(new_data->nego_formats))
 new_data->format = 
pa_format_info_copy(pa_idxset_first(new_data->nego_formats, NULL));
 
+if (!new_data->format) {
+/* Sink doesn't support any requested format */
+pa_log_debug("Default sink does not match sink input requested 
formats");
+return PA_HOOK_OK;
+}
+
 if (pa_sink_input_new_data_is_passthrough(new_data))
 return new_passthrough_stream(u, core, new_data->sink, NULL);
 
-- 
2.17.0

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

[pulseaudio-discuss] [PATCH] PROTOCOL: Bump to version 33

[Arun Raghavan]

Required for the addition of new pa_encoding_t values.
---
 PROTOCOL | 7 +++
 configure.ac | 2 +-
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/PROTOCOL b/PROTOCOL
index 546998b78..8117d0043 100644
--- a/PROTOCOL
+++ b/PROTOCOL
@@ -420,6 +420,13 @@ memfd support only to 10.0+ clients.
 
 Check commit 451d1d676237c81 for further details.
 
+## v33, implemented by >= 13.0
+
+Added two values to the pa_encoding_t enum:
+
+PA_ENCODING_TRUEHD_IEC61937 := 7
+PA_ENCODING_DTSHD_IEC61937 := 8
+
  If you just changed the protocol, read this
 ## module-tunnel depends on the sink/source/sink-input/source-input protocol
 ## internals, so if you changed these, you might have broken module-tunnel.
diff --git a/configure.ac b/configure.ac
index 140e2c0e6..f5c993d9a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -40,7 +40,7 @@ AC_SUBST(PA_MINOR, pa_minor)
 AC_SUBST(PA_MAJORMINOR, pa_major.pa_minor)
 
 AC_SUBST(PA_API_VERSION, 12)
-AC_SUBST(PA_PROTOCOL_VERSION, 32)
+AC_SUBST(PA_PROTOCOL_VERSION, 33)
 
 # The stable ABI for client applications, for the version info x:y:z
 # always will hold y=z
-- 
2.17.0

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

Re: [pulseaudio-discuss] [RFC PATCH 2/2] alsa: add support for Dolby TrueHD and DTS-HD HBR passthrough

[Arun Raghavan]

On Wed, 6 Sep 2017, at 9:10 AM, Arun Raghavan wrote:
> 
> 
> On Tue, 5 Sep 2017, at 07:08 PM, Pierre-Louis Bossart wrote:
[...]
> > Sorry, I can't find your previous patch to replace 'update_rate' with 
> > 'reconfigure'. Was it shared?
> > Better yet, do you have a branch I could directly look at? I am drowning 
> > in emails.
> 
> Here you go --
> https://cgit.freedesktop.org/~arun/pulseaudio/log/?h=passthrough-hbr
> 
> You'll still need your patches adding truehd/dts-hd support on top of
> this.

I've upstreamed your TrueHD/DTS-HD patch. I've got the pavucontrol changes 
staged, but that depends on the protocol version bump.

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

Re: [pulseaudio-discuss] [PATCH] alsa-util: Set ALSA report_delay flag in pa_alsa_safe_delay()

[Arun Raghavan]

On Wed, 4 Apr 2018, at 12:49 PM, Takashi Iwai wrote:
> On Wed, 04 Apr 2018 08:45:41 +0200,
> Georg Chini wrote:
> > 
> > On 04.04.2018 08:01, Takashi Iwai wrote:
> > > On Wed, 04 Apr 2018 00:35:24 +0200,
> > > Pierre-Louis Bossart wrote:
> > >> On 4/2/18 3:14 PM, Georg Chini wrote:
> > >>> On 02.04.2018 21:35, Pierre-Louis Bossart wrote:
> > 
> >  On 04/02/2018 07:54 AM, Georg Chini wrote:
> > > The current code does not call 
> > > snd_pcm_status_set_audio_htstamp_config()
> > > to configure the way timestamps are updated in ALSA. This leads to
> > > incorrect time stamps in the status object returned by 
> > > snd_pcm_status(),
> > > so the computed latencies are wrong.
> > >
> > > This patch uses snd_pcm_status_set_audio_htstamp_config() to set the
> > > ALSA report_delay flag to 1 before the call to snd_pcm_status(). With
> > > this, time stamps are updated as expected.
> > > ---
> > >    src/modules/alsa/alsa-util.c | 7 +++
> > >    1 file changed, 7 insertions(+)
> > >
> > > diff --git a/src/modules/alsa/alsa-util.c 
> > > b/src/modules/alsa/alsa-util.c
> > > index 61fb4903..b91a0e98 100644
> > > --- a/src/modules/alsa/alsa-util.c
> > > +++ b/src/modules/alsa/alsa-util.c
> > > @@ -1187,6 +1187,7 @@ int pa_alsa_safe_delay(snd_pcm_t *pcm,
> > > snd_pcm_status_t *status, snd_pcm_sframes
> > >    size_t abs_k;
> > >    int err;
> > >    snd_pcm_sframes_t avail = 0;
> > > +    snd_pcm_audio_tstamp_config_t tstamp_config;
> > >      pa_assert(pcm);
> > >    pa_assert(delay);
> > > @@ -1200,6 +1201,12 @@ int pa_alsa_safe_delay(snd_pcm_t *pcm,
> > > snd_pcm_status_t *status, snd_pcm_sframes
> > >     * avail, delay and timestamp values in a single kernel call
> > > to improve
> > >     * timer-based scheduling */
> > >    +    /* The time stamp configuration needs to be set so that the
> > > + * ALSA code will use the internal delay reported by the driver 
> > > */
> > > +    tstamp_config.type_requested = 1; /* ALSA default time stamp
> > > type */
> > > +    tstamp_config.report_delay = 1;
> > > +    snd_pcm_status_set_audio_htstamp_config(status, &tstamp_config);
> > > +
> >  are you sure it's necessary or is this possibly a misunderstanding
> >  of what audio_tstamps are?
> > 
> >  this command is only for the audio timestamp, and to the best of my
> >  knowledge you are not using the results using one of the
> >  snd_pcm_status_get_audio_htstamp_* commands
> > 
> >  the typical usage (see alsa-lib/test/audio_time.c) is this:
> > 
> >       snd_pcm_status_set_audio_htstamp_config(status, 
> >  audio_tstamp_config);
> > 
> >       if ((err = snd_pcm_status(handle, status)) < 0) {
> >           printf("Stream status error: %s\n", snd_strerror(err));
> >           exit(0);
> >       }
> >       snd_pcm_status_get_trigger_htstamp(status, trigger_timestamp);
> >       snd_pcm_status_get_htstamp(status, timestamp);
> >       snd_pcm_status_get_audio_htstamp(status, audio_timestamp);
> >       snd_pcm_status_get_audio_htstamp_report(status, 
> >  audio_tstamp_report);
> > 
> >  if you are not using the _get_audio_hstamp() then the config has
> >  essentially no effect, and the delay is available separately in the
> >  status command as before.
> > 
> > >    if ((err = snd_pcm_status(pcm, status)) < 0)
> > >    return err;
> > >>> See this bug report, why it is needed:
> > >>>
> > >>> https://bugzilla.kernel.org/show_bug.cgi?id=199235
> > >>>
> > >>> It finally turned out that there was not a bug but just the flag 
> > >>> missing.
> > >>> We are using  snd_pcm_status_get_htstamp() with the time smoother
> > >>> to calculate sink/source latency.
> > >> Humm, that looks more like a bug in the fix (20e3f9 'ALSA: pcm: update
> > >> tstamp only in audio_tstamp changed'). I don't think we intended that
> > >> changes in the way the audio_tstamp is calculated (with or without
> > >> delay) would impact when the system timestamp is updated. I am pretty
> > >> sure we only wanted to update the timestamp when the hw_ptr changed
> > >> with this fix so as to go back to the traditional behavior before
> > >> kernel 4.1.
> > > The fact here is that hwptr still remains same but only the delay
> > > changes.  As the prior-4.1 traditional behavior, the timestamp isn't
> > > updated in such a case.  Before the commit, the timestamp is always
> > > updated no matter whether hwptr is updated or not, and it broke
> > > applications.
> > >
> > > So, the question is how we should look at the timestamp.  The fix is
> > > based on the assumption that tstamp is always coupled with
> > > audio_tstamp, where the latter calculation depends on the tstamp
> > > config flag.
> > >
> > > OTOH, if we take rather audio_tst

Re: [pulseaudio-discuss] [PATCH] core: Expose API to elevate a thread to realtime priority

[Arun Raghavan]

On Sat, 5 May 2018, at 7:37 PM, Tanu Kaskinen wrote:
> On Fri, 2018-05-04 at 21:01 +0530, Arun Raghavan wrote:
> > This should make it easier for clients to elevate their audio threads to
> > real time priority without having to dig through much through specific
> > system internals.
> > ---
> >  src/map-file |   1 +
> >  src/modules/alsa/alsa-sink.c |   3 +-
> >  src/modules/alsa/alsa-source.c   |   3 +-
> >  src/modules/bluetooth/module-bluez5-device.c |   3 +-
> >  src/modules/jack/module-jack-sink.c  |   5 +-
> >  src/modules/jack/module-jack-source.c|   5 +-
> >  src/modules/macosx/module-coreaudio-device.c |   2 +-
> >  src/modules/module-combine-sink.c|   3 +-
> >  src/modules/module-solaris.c |   2 +-
> >  src/modules/module-waveout.c |   2 +-
> >  src/modules/oss/module-oss.c |   2 +-
> >  src/pulse/util.c | 176 +++
> >  src/pulse/util.h |   6 +
> >  src/pulsecore/core-util.c| 171 +-
> >  src/pulsecore/core-util.h|   1 -
> >  src/tests/lo-test-util.c |   2 +-
> >  src/tests/rtstutter.c|   2 +-
> >  17 files changed, 205 insertions(+), 184 deletions(-)
> 
> The issues that I spotted seem to be fixed. Assuming that there are no
> other changes, ack from me. (I didn't do a full review, because Georg
> already did that.)

There were two or three more changes to add pulse/util.h in includes where I'd 
missed it, but that's the extent of it.

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

[pulseaudio-discuss] [PATCH] null-sink, null-source: Use realtime scheduling if possible

[Arun Raghavan]

We do this on other sink/source modules, and in general it makes sense
to do so here as well.
---
 src/modules/module-null-sink.c   | 4 
 src/modules/module-null-source.c | 4 
 2 files changed, 8 insertions(+)

diff --git a/src/modules/module-null-sink.c b/src/modules/module-null-sink.c
index 6cbe588de..fdab1121e 100644
--- a/src/modules/module-null-sink.c
+++ b/src/modules/module-null-sink.c
@@ -28,6 +28,7 @@
 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -206,6 +207,9 @@ static void thread_func(void *userdata) {
 
 pa_log_debug("Thread starting up");
 
+if (u->core->realtime_scheduling)
+pa_thread_make_realtime(u->core->realtime_priority);
+
 pa_thread_mq_install(&u->thread_mq);
 
 u->timestamp = pa_rtclock_now();
diff --git a/src/modules/module-null-source.c b/src/modules/module-null-source.c
index 0e4c8d2f2..251d0f523 100644
--- a/src/modules/module-null-source.c
+++ b/src/modules/module-null-source.c
@@ -29,6 +29,7 @@
 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -132,6 +133,9 @@ static void thread_func(void *userdata) {
 
 pa_log_debug("Thread starting up");
 
+if (u->core->realtime_scheduling)
+pa_thread_make_realtime(u->core->realtime_priority);
+
 pa_thread_mq_install(&u->thread_mq);
 
 u->timestamp = pa_rtclock_now();
-- 
2.17.0

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

Re: [pulseaudio-discuss] [PATCH] allow-passthrough: fix hook return value

[Arun Raghavan]

On Sat, 5 May 2018, at 7:52 PM, Tanu Kaskinen wrote:
> -PA_ERR_NOENTITY is not a valid pa_hook_result_t value.
> ---
>  src/modules/module-allow-passthrough.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/modules/module-allow-passthrough.c b/src/modules/
> module-allow-passthrough.c
> index 16b421d79..a882e78ea 100644
> --- a/src/modules/module-allow-passthrough.c
> +++ b/src/modules/module-allow-passthrough.c
> @@ -177,7 +177,7 @@ static pa_hook_result_t sink_input_new_cb(pa_core 
> *core, pa_sink_input_new_data
>   * format). */
>  if (!new_data->sink) {
>  pa_sink *sink = pa_namereg_get(core, NULL, PA_NAMEREG_SINK);
> -pa_return_val_if_fail(sink, -PA_ERR_NOENTITY);
> +pa_return_val_if_fail(sink, PA_HOOK_OK);
>  pa_sink_input_new_data_set_sink(new_data, sink, false, false);
>  }
>  
> -- 

Thanks, looks good.

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

Re: [pulseaudio-discuss] [PATCH] core-format: fix TrueHD and DTS-HD channel maps

[Arun Raghavan]

On Sat, 5 May 2018, at 6:31 PM, Tanu Kaskinen wrote:
> Since these formats use 8 channels, the channel map needs to be
> configured to 8 channels as well.
> ---
>  src/pulsecore/core-format.c | 22 +++---
>  1 file changed, 15 insertions(+), 7 deletions(-)
> 
> diff --git a/src/pulsecore/core-format.c b/src/pulsecore/core-format.c
> index c3db2678a..862a74b5d 100644
> --- a/src/pulsecore/core-format.c
> +++ b/src/pulsecore/core-format.c
> @@ -227,13 +227,21 @@ int pa_format_info_to_sample_spec_fake(const 
> pa_format_info *f, pa_sample_spec *
>  
>  ss->format = PA_SAMPLE_S16LE;
>  if ((f->encoding == PA_ENCODING_TRUEHD_IEC61937) ||
> - (f->encoding == PA_ENCODING_DTSHD_IEC61937))
> - ss->channels = 8;
> -else
> - ss->channels = 2;
> -
> -if (map)
> -pa_channel_map_init_stereo(map);
> +(f->encoding == PA_ENCODING_DTSHD_IEC61937)) {
> +ss->channels = 8;
> +if (map) {
> +/* We use the ALSA mapping, because most likely we will be using 
> an
> + * ALSA sink. This doesn't really matter anyway, though, because
> + * the channel map doesn't affect anything with passthrough
> + * streams. The channel map just needs to be consistent with the
> + * sample spec's channel count. */
> +pa_channel_map_init_auto(map, 8, PA_CHANNEL_MAP_ALSA);
> +}
> +} else {
> +ss->channels = 2;
> +if (map)
> +pa_channel_map_init_stereo(map);
> +}
>  
>  pa_return_val_if_fail(pa_format_info_get_prop_int(f, 
> PA_PROP_FORMAT_RATE, &rate) == 0, -PA_ERR_INVALID);
>  ss->rate = (uint32_t) rate;
> -- 

Thanks for the fix-up, looks good.

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

Re: [pulseaudio-discuss] [PATCH] alsa-util: Use time stamp config only for alsa versions >= 1.1.0

[Arun Raghavan]

On Tue, 15 May 2018, at 11:30 AM, Georg Chini wrote:
> The commit "alsa-util: Set ALSA report_delay flag in pa_alsa_safe_delay()"
> broke the build on ALSA versions below 1.1.0 because the time stamp
> configuration function was introduced in 1.1.0.
> 
> This patch makes the usage of snd_pcm_status_set_audio_htstamp_config()
> dependent on ALSA version.
> ---
>  src/modules/alsa/alsa-util.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/src/modules/alsa/alsa-util.c b/src/modules/alsa/alsa-util.c
> index b91a0e98..41134ea5 100644
> --- a/src/modules/alsa/alsa-util.c
> +++ b/src/modules/alsa/alsa-util.c
> @@ -1187,7 +1187,9 @@ int pa_alsa_safe_delay(snd_pcm_t *pcm, 
> snd_pcm_status_t *status, snd_pcm_sframes
>  size_t abs_k;
>  int err;
>  snd_pcm_sframes_t avail = 0;
> +#if (SND_LIB_VERSION >= ((1<<16)|(1<<8)|0)) /* API additions in 1.1.0 
> */
>  snd_pcm_audio_tstamp_config_t tstamp_config;
> +#endif
>  
>  pa_assert(pcm);
>  pa_assert(delay);
> @@ -1201,11 +1203,15 @@ int pa_alsa_safe_delay(snd_pcm_t *pcm, 
> snd_pcm_status_t *status, snd_pcm_sframes
>   * avail, delay and timestamp values in a single kernel call to 
> improve
>   * timer-based scheduling */
>  
> +#if (SND_LIB_VERSION >= ((1<<16)|(1<<8)|0)) /* API additions in 1.1.0 */
> +
>  /* The time stamp configuration needs to be set so that the
> - * ALSA code will use the internal delay reported by the driver */
> + * ALSA code will use the internal delay reported by the driver.
> + * The time stamp configuration was introduced in alsa version 1.1.0. */
>  tstamp_config.type_requested = 1; /* ALSA default time stamp type */
>  tstamp_config.report_delay = 1;
>  snd_pcm_status_set_audio_htstamp_config(status, &tstamp_config);
> +#endif
>  
>  if ((err = snd_pcm_status(pcm, status)) < 0)
>  return err;
> -- 

Looks good.

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

Re: [pulseaudio-discuss] [PATCH] alsa-util: Use time stamp config only for alsa versions >= 1.1.0

[Arun Raghavan]

On Wed, 16 May 2018, at 12:42 AM, Pierre-Louis Bossart wrote:
> On 5/15/18 8:12 AM, Arun Raghavan wrote:
> > On Tue, 15 May 2018, at 11:30 AM, Georg Chini wrote:
> >> The commit "alsa-util: Set ALSA report_delay flag in pa_alsa_safe_delay()"
> >> broke the build on ALSA versions below 1.1.0 because the time stamp
> >> configuration function was introduced in 1.1.0.
> >>
> >> This patch makes the usage of snd_pcm_status_set_audio_htstamp_config()
> >> dependent on ALSA version.
> >> ---
> >>   src/modules/alsa/alsa-util.c | 8 +++-
> >>   1 file changed, 7 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/src/modules/alsa/alsa-util.c b/src/modules/alsa/alsa-util.c
> >> index b91a0e98..41134ea5 100644
> >> --- a/src/modules/alsa/alsa-util.c
> >> +++ b/src/modules/alsa/alsa-util.c
> >> @@ -1187,7 +1187,9 @@ int pa_alsa_safe_delay(snd_pcm_t *pcm,
> >> snd_pcm_status_t *status, snd_pcm_sframes
> >>   size_t abs_k;
> >>   int err;
> >>   snd_pcm_sframes_t avail = 0;
> >> +#if (SND_LIB_VERSION >= ((1<<16)|(1<<8)|0)) /* API additions in 1.1.0
> >> */
> >>   snd_pcm_audio_tstamp_config_t tstamp_config;
> >> +#endif
> >>   
> >>   pa_assert(pcm);
> >>   pa_assert(delay);
> >> @@ -1201,11 +1203,15 @@ int pa_alsa_safe_delay(snd_pcm_t *pcm,
> >> snd_pcm_status_t *status, snd_pcm_sframes
> >>* avail, delay and timestamp values in a single kernel call to
> >> improve
> >>* timer-based scheduling */
> >>   
> >> +#if (SND_LIB_VERSION >= ((1<<16)|(1<<8)|0)) /* API additions in 1.1.0 */
> >> +
> >>   /* The time stamp configuration needs to be set so that the
> >> - * ALSA code will use the internal delay reported by the driver */
> >> + * ALSA code will use the internal delay reported by the driver.
> >> + * The time stamp configuration was introduced in alsa version 1.1.0. 
> >> */
> >>   tstamp_config.type_requested = 1; /* ALSA default time stamp type */
> >>   tstamp_config.report_delay = 1;
> >>   snd_pcm_status_set_audio_htstamp_config(status, &tstamp_config);
> >> +#endif
> >>   
> >>   if ((err = snd_pcm_status(pcm, status)) < 0)
> >>   return err;
> >> -- 
> > 
> > Looks good.
> 
> Takashi and I mentioned it's not quite right but what can I say...

I check with Georg before acking the original commit and his impression was 
that it was fine. Do we have consensus on eBay this should be?

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

[pulseaudio-discuss] [PATCH] build-sys: Update meson.build based on recent changes

[Arun Raghavan]

Bump the protocol version, and drop (commented out) references to BlueZ
4.
---
 meson.build | 2 +-
 src/modules/meson.build | 2 --
 2 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/meson.build b/meson.build
index f215ce366..9308aa9f8 100644
--- a/meson.build
+++ b/meson.build
@@ -12,7 +12,7 @@ pa_version_micro = version_split[2]
 pa_version_major_minor = pa_version_major + '.' + pa_version_minor
 
 pa_api_version = 12
-pa_protocol_version = 31
+pa_protocol_version = 33
 
 apiversion = '1.0'
 soversion = 0
diff --git a/src/modules/meson.build b/src/modules/meson.build
index 3d6b53fe8..339f6d013 100644
--- a/src/modules/meson.build
+++ b/src/modules/meson.build
@@ -6,8 +6,6 @@ all_modules = [
   [ 'module-augment-properties', 'module-augment-properties.c' ],
   [ 'module-bluetooth-discover', 'bluetooth/module-bluetooth-discover.c' ],
   [ 'module-bluetooth-policy', 'bluetooth/module-bluetooth-policy.c' ],
-#  [ 'module-bluez4-device', 'bluetooth/module-bluez4-device.c' ],
-#  [ 'module-bluez4-discover', 'bluetooth/module-bluez4-discover.c' ],
 #  [ 'module-bluez5-device', 'bluetooth/module-bluez5-device.c' ],
 #  [ 'module-bluez5-discover', 'bluetooth/module-bluez5-discover.c' ],
 #  [ 'module-bonjour-publish', 'macosx/module-bonjour-publish.c' ],
-- 
2.17.0

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

[pulseaudio-discuss] [PATCH 1/3] build-sys: Update meson.build based on recent changes

[Arun Raghavan]

Bump the protocol version, and drop (commented out) references to BlueZ
4.
---
 meson.build | 2 +-
 src/modules/meson.build | 2 --
 2 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/meson.build b/meson.build
index f215ce366..9308aa9f8 100644
--- a/meson.build
+++ b/meson.build
@@ -12,7 +12,7 @@ pa_version_micro = version_split[2]
 pa_version_major_minor = pa_version_major + '.' + pa_version_minor
 
 pa_api_version = 12
-pa_protocol_version = 31
+pa_protocol_version = 33
 
 apiversion = '1.0'
 soversion = 0
diff --git a/src/modules/meson.build b/src/modules/meson.build
index 3d6b53fe8..339f6d013 100644
--- a/src/modules/meson.build
+++ b/src/modules/meson.build
@@ -6,8 +6,6 @@ all_modules = [
   [ 'module-augment-properties', 'module-augment-properties.c' ],
   [ 'module-bluetooth-discover', 'bluetooth/module-bluetooth-discover.c' ],
   [ 'module-bluetooth-policy', 'bluetooth/module-bluetooth-policy.c' ],
-#  [ 'module-bluez4-device', 'bluetooth/module-bluez4-device.c' ],
-#  [ 'module-bluez4-discover', 'bluetooth/module-bluez4-discover.c' ],
 #  [ 'module-bluez5-device', 'bluetooth/module-bluez5-device.c' ],
 #  [ 'module-bluez5-discover', 'bluetooth/module-bluez5-discover.c' ],
 #  [ 'module-bonjour-publish', 'macosx/module-bonjour-publish.c' ],
-- 
2.17.0

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

[pulseaudio-discuss] [PATCH 3/3] build-sys: Add some missing header/function checks to meson build

[Arun Raghavan]

---
 meson.build | 4 
 1 file changed, 4 insertions(+)

diff --git a/meson.build b/meson.build
index 9308aa9f8..08a5fa9aa 100644
--- a/meson.build
+++ b/meson.build
@@ -57,6 +57,7 @@ cdata.set_quoted('DESKTOPFILEDIR', join_paths(datadir, 
'applications'))
 check_headers = [
   'arpa/inet.h',
   'cpuid.h',
+  'execinfo.h',
   'grp.h',
   'langinfo.h',
   'locale.h',
@@ -78,6 +79,7 @@ check_headers = [
   'sys/select.h',
   'sys/socket.h',
   'sys/un.h',
+  'sys/wait.h',
   'valgrind/memcheck.h',
   'xlocale.h',
 ]
@@ -104,6 +106,8 @@ check_functions = [
   'fork',
   'fstat',
   'getaddrinfo',
+  'getgrgid_r',
+  'getpwnam_r',
   'gettimeofday',
   'getuid',
   'lstat',
-- 
2.17.0

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

[pulseaudio-discuss] Minor update to meson build

[Arun Raghavan]

The following patches update the meson build based on recent autofoo
changes and clean up some warnings from missing checks.

-- Arun


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

[pulseaudio-discuss] [PATCH 2/3] build-sys: Drop ancient check for dbus_watch_get_unix_fd()

[Arun Raghavan]

This function was added shortly after dbus 1.1.0, and our minimum
required dbus version is greater than 1.4.
---
 configure.ac| 9 -
 src/modules/dbus/module-dbus-protocol.c | 8 
 src/pulsecore/dbus-util.c   | 8 
 3 files changed, 25 deletions(-)

diff --git a/configure.ac b/configure.ac
index 1a49c5e31..8d342010c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1013,15 +1013,6 @@ AS_IF([test "x$enable_dbus" != "xno"],
 AS_IF([test "x$enable_dbus" = "xyes" && test "x$HAVE_DBUS" = "x0"],
 [AC_MSG_ERROR([*** D-Bus not available or too old version])])
 
-AS_IF([test "x$HAVE_DBUS" = "x1"],
-[
-save_CFLAGS="$CFLAGS"; CFLAGS="$CFLAGS $DBUS_CFLAGS"
-save_LIBS="$LIBS"; LIBS="$LIBS $DBUS_LIBS"
-AC_CHECK_FUNCS(dbus_watch_get_unix_fd)
-CFLAGS="$save_CFLAGS"
-LIBS="$save_LIBS"
-])
-
 AC_SUBST(HAVE_DBUS)
 AM_CONDITIONAL([HAVE_DBUS], [test "x$HAVE_DBUS" = x1])
 AS_IF([test "x$HAVE_DBUS" = "x1"], AC_DEFINE([HAVE_DBUS], 1, [Have D-Bus.]))
diff --git a/src/modules/dbus/module-dbus-protocol.c 
b/src/modules/dbus/module-dbus-protocol.c
index 259eb9f09..8a83c7693 100644
--- a/src/modules/dbus/module-dbus-protocol.c
+++ b/src/modules/dbus/module-dbus-protocol.c
@@ -218,11 +218,7 @@ static void io_event_cb(pa_mainloop_api *mainloop, 
pa_io_event *e, int fd, pa_io
 unsigned int flags = 0;
 DBusWatch *watch = userdata;
 
-#ifdef HAVE_DBUS_WATCH_GET_UNIX_FD
 pa_assert(fd == dbus_watch_get_unix_fd(watch));
-#else
-pa_assert(fd == dbus_watch_get_fd(watch));
-#endif
 
 if (!dbus_watch_get_enabled(watch)) {
 pa_log_warn("Asked to handle disabled watch: %p %i", (void*) watch, 
fd);
@@ -289,11 +285,7 @@ static dbus_bool_t watch_add_cb(DBusWatch *watch, void 
*data) {
 
 ev = mainloop->io_new(
 mainloop,
-#ifdef HAVE_DBUS_WATCH_GET_UNIX_FD
 dbus_watch_get_unix_fd(watch),
-#else
-dbus_watch_get_fd(watch),
-#endif
 get_watch_flags(watch), io_event_cb, watch);
 
 dbus_watch_set_data(watch, ev, NULL);
diff --git a/src/pulsecore/dbus-util.c b/src/pulsecore/dbus-util.c
index d5d5f7e1d..7d550204e 100644
--- a/src/pulsecore/dbus-util.c
+++ b/src/pulsecore/dbus-util.c
@@ -100,11 +100,7 @@ static void handle_io_event(pa_mainloop_api *ea, 
pa_io_event *e, int fd, pa_io_e
 unsigned int flags = 0;
 DBusWatch *watch = userdata;
 
-#ifdef HAVE_DBUS_WATCH_GET_UNIX_FD
 pa_assert(fd == dbus_watch_get_unix_fd(watch));
-#else
-pa_assert(fd == dbus_watch_get_fd(watch));
-#endif
 
 if (!dbus_watch_get_enabled(watch)) {
 pa_log_warn("Asked to handle disabled watch: %p %i", (void*) watch, 
fd);
@@ -153,11 +149,7 @@ static dbus_bool_t add_watch(DBusWatch *watch, void *data) 
{
 
 ev = c->mainloop->io_new(
 c->mainloop,
-#ifdef HAVE_DBUS_WATCH_GET_UNIX_FD
 dbus_watch_get_unix_fd(watch),
-#else
-dbus_watch_get_fd(watch),
-#endif
 get_watch_flags(watch), handle_io_event, watch);
 
 dbus_watch_set_data(watch, ev, NULL);
-- 
2.17.0

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

[pulseaudio-discuss] [PATCH] sink-input, source-output: Don't remap volume for passthrough streams

[Arun Raghavan]

This fixes an assert when we try to restore the original volume map on
the synthesized (100%) volume of a passthrough stream.
---
 src/pulsecore/sink-input.c| 2 +-
 src/pulsecore/source-output.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/pulsecore/sink-input.c b/src/pulsecore/sink-input.c
index 5a55e93a5..ebe5cc957 100644
--- a/src/pulsecore/sink-input.c
+++ b/src/pulsecore/sink-input.c
@@ -403,7 +403,7 @@ int pa_sink_input_new(
 if (!data->volume_writable)
 data->save_volume = false;
 
-if (data->volume_is_set)
+if (data->volume_is_set && !pa_sink_input_new_data_is_passthrough(data))
 /* The original volume channel map may be different than the final
  * stream channel map, so remapping may be needed. */
 pa_cvolume_remap(&data->volume, &volume_map, &data->channel_map);
diff --git a/src/pulsecore/source-output.c b/src/pulsecore/source-output.c
index bcef51fdb..17f5da5e1 100644
--- a/src/pulsecore/source-output.c
+++ b/src/pulsecore/source-output.c
@@ -341,7 +341,7 @@ int pa_source_output_new(
 if (!data->volume_writable)
 data->save_volume = false;
 
-if (data->volume_is_set)
+if (data->volume_is_set && !pa_source_output_new_data_is_passthrough(data))
 /* The original volume channel map may be different than the final
  * stream channel map, so remapping may be needed. */
 pa_cvolume_remap(&data->volume, &volume_map, &data->channel_map);
-- 
2.17.0

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

[pulseaudio-discuss] (no subject)

[Arun Raghavan]

This adds support for reconfiguring channel count for sinks and sources.
Specically, this applies to passthrough formats, and is particularly of
use now while dealing with high bitrate formats. In the long run, we
will likely want to prefer automatic profile switching for the
passthrough use-cases.

The ALSA patch has one gotcha -- it breaks if frame_size doesn't exactly
divid hwbuf_size. I can't think of a clean fix for this. Suggestions are
welcome.

Cheers,
Arun


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

[pulseaudio-discuss] [PATCH 1/2] sink: Allow reconfigure to change the complete sample spec

[Arun Raghavan]

For the passthrough case, we allow the entire sink sample spec to be
changed in reconfigure. This will be needed for high bitrate formats.

Relatedly, we also restore the original spec on leaving passthrough
mode. We were getting away with not doing so in the past as, while
incorrect, not restoring the rate was not disastrous. With the ability
to change channel count, not restoring breaks the meaning of profiles
entirely. The saving and restoration logic is restricted to sink/source
reconfiguration code to allow it to be self-contained and easier to
reason about.

All this also applies to the sample spec. We don't actually explicitly
reconfigure the channel map at the moment, but since
pa_sink/source_reconfigure() can now change the channel count, it seems
to make sense to include the channel map along with that API change for
future use.
---
 src/pulsecore/sink-input.c| 29 ++
 src/pulsecore/sink.c  | 70 --
 src/pulsecore/sink.h  |  8 ++--
 src/pulsecore/source-output.c | 21 --
 src/pulsecore/source.c| 72 +--
 src/pulsecore/source.h|  8 ++--
 6 files changed, 167 insertions(+), 41 deletions(-)

diff --git a/src/pulsecore/sink-input.c b/src/pulsecore/sink-input.c
index ebe5cc957..c84ad2dda 100644
--- a/src/pulsecore/sink-input.c
+++ b/src/pulsecore/sink-input.c
@@ -416,9 +416,9 @@ int pa_sink_input_new(
 /* try to change sink rate. This is done before the FIXATE hook since
module-suspend-on-idle can resume a sink */
 
-pa_log_info("Trying to change sample rate");
-if (pa_sink_reconfigure(data->sink, &data->sample_spec, 
pa_sink_input_new_data_is_passthrough(data)) >= 0)
-pa_log_info("Rate changed to %u Hz", data->sink->sample_spec.rate);
+pa_log_info("Trying to change sample spec");
+if (pa_sink_reconfigure(data->sink, &data->sample_spec, NULL, 
pa_sink_input_new_data_is_passthrough(data), false) >= 0)
+pa_log_info("Spec changed to %u Hz, %d channels", 
data->sink->sample_spec.rate, data->sink->sample_spec.channels);
 }
 
 if (pa_sink_input_new_data_is_passthrough(data) &&
@@ -617,7 +617,7 @@ static void sink_input_set_state(pa_sink_input *i, 
pa_sink_input_state_t state)
 !pa_sample_spec_equal(&i->sample_spec, &i->sink->sample_spec)) {
 /* We were uncorked and the sink was not playing anything -- let's 
try
  * to update the sample rate to avoid resampling */
-pa_sink_reconfigure(i->sink, &i->sample_spec, 
pa_sink_input_is_passthrough(i));
+pa_sink_reconfigure(i->sink, &i->sample_spec, NULL, 
pa_sink_input_is_passthrough(i), false);
 }
 
 pa_assert_se(pa_asyncmsgq_send(i->sink->asyncmsgq, PA_MSGOBJECT(i), 
PA_SINK_INPUT_MESSAGE_SET_STATE, PA_UINT_TO_PTR(state), 0, NULL) == 0);
@@ -720,9 +720,16 @@ void pa_sink_input_unlink(pa_sink_input *i) {
 reset_callbacks(i);
 
 if (i->sink) {
-if (PA_SINK_IS_LINKED(pa_sink_get_state(i->sink)))
+if (PA_SINK_IS_LINKED(pa_sink_get_state(i->sink))) {
 pa_sink_update_status(i->sink);
 
+if (pa_sink_input_is_passthrough(i)) {
+pa_log_debug("Leaving passthrough, trying to restore previous 
configuration");
+if (pa_sink_reconfigure(i->sink, NULL, NULL, false, true) >= 0)
+pa_log_info("Spec changed to %u Hz, %d channels", 
i->sink->sample_spec.rate, i->sink->sample_spec.channels);
+}
+}
+
 i->sink = NULL;
 }
 
@@ -1738,6 +1745,12 @@ int pa_sink_input_start_move(pa_sink_input *i) {
 
 pa_sink_update_status(i->sink);
 
+if (pa_sink_input_is_passthrough(i)) {
+pa_log_debug("Leaving passthrough, trying to restore previous 
configuration");
+if (pa_sink_reconfigure(i->sink, NULL, NULL, false, true) >= 0)
+pa_log_info("Spec changed to %u Hz, %d channels", 
i->sink->sample_spec.rate, i->sink->sample_spec.channels);
+}
+
 PA_HASHMAP_FOREACH(v, i->volume_factor_sink_items, state)
 pa_cvolume_remap(&v->volume, &i->sink->channel_map, &i->channel_map);
 
@@ -1908,9 +1921,9 @@ int pa_sink_input_finish_move(pa_sink_input *i, pa_sink 
*dest, bool save) {
module-suspend-on-idle resumes destination sink with
SINK_INPUT_MOVE_FINISH hook */
 
-pa_log_info("Trying to change sample rate");
-if (pa_sink_reconfigure(dest, &i->sample_spec, 
pa_sink_input_is_passthrough(i)) >= 0)
-pa_log_info("Rate changed to %u Hz", dest->sample_spec.rate);
+pa_log_info("Trying to change sample spec");
+if (pa_sink_reconfigure(dest, &i->sample_spec, NULL, 
pa_sink_input_is_passthrough(i), false) >= 0)
+pa_log_info("Spec changed to %u Hz, %d channels", 
dest->sample_spec.rate, dest->sample_spec.channels);
 }
 
 if (i->moving)
diff --git a/src/pulsecore/sink.c b/src/pulsecore/s

[pulseaudio-discuss] [PATCH 2/2] alsa: Add support for channel reconfiguration

[Arun Raghavan]

This is needed for supporting high-bitrate formats in passthrough mode.
The alsa-source reconfiguration path is untested at the moment as I do
not have hardware that can support multiple channel configurations for
capture.

This patch is not complete, because setting a channel count that results
in a frame size that does not exactly divide the h/w buffer size results
in a failure during unsuspend() -- the buffer and period count that we
get are necessarily lower than the total buffer / period size.
---
 src/modules/alsa/alsa-sink.c   | 43 --
 src/modules/alsa/alsa-source.c | 43 --
 src/modules/alsa/alsa-util.c   | 38 ++
 src/modules/alsa/alsa-util.h   |  1 +
 4 files changed, 111 insertions(+), 14 deletions(-)

diff --git a/src/modules/alsa/alsa-sink.c b/src/modules/alsa/alsa-sink.c
index ed9e0a51c..56d4feafd 100644
--- a/src/modules/alsa/alsa-sink.c
+++ b/src/modules/alsa/alsa-sink.c
@@ -112,6 +112,7 @@ struct userdata {
 pa_cvolume hardware_volume;
 
 unsigned int *rates;
+unsigned int *channels;
 
 size_t
 frame_size,
@@ -1670,30 +1671,49 @@ static bool sink_set_formats(pa_sink *s, pa_idxset 
*formats) {
 return true;
 }
 
-static int sink_reconfigure_cb(pa_sink *s, pa_sample_spec *spec, bool 
passthrough) {
+static int sink_reconfigure_cb(pa_sink *s, pa_sample_spec *spec, 
pa_channel_map *map, bool passthrough) {
 struct userdata *u = s->userdata;
 int i;
-bool supported = false;
-
-/* FIXME: we only update rate for now */
+bool supported_rate = false, supported_channels = false;
 
 pa_assert(u);
 
 for (i = 0; u->rates[i]; i++) {
 if (u->rates[i] == spec->rate) {
-supported = true;
+supported_rate = true;
 break;
 }
 }
 
-if (!supported) {
+if (!supported_rate) {
 pa_log_info("Sink does not support sample rate of %d Hz", spec->rate);
 return -1;
 }
 
+for (i = 0; u->channels[i]; i++) {
+if (u->channels[i] == spec->channels) {
+supported_channels = true;
+break;
+}
+}
+
+if (!supported_channels) {
+pa_log_info("Sink does not support channels: %d", spec->channels);
+return -1;
+}
+
 if (!PA_SINK_IS_OPENED(s->state)) {
-pa_log_info("Updating rate for device %s, new rate is %d", 
u->device_name, spec->rate);
+pa_log_info("Updating rate and channels for device %s, %d Hz, %d 
channels", u->device_name, spec->rate, spec->channels);
+
 u->sink->sample_spec.rate = spec->rate;
+u->sink->sample_spec.channels = spec->channels;
+if (map)
+u->sink->channel_map = *map;
+else
+pa_channel_map_init_auto(&u->sink->channel_map, 
u->sink->sample_spec.channels, PA_CHANNEL_MAP_ALSA);
+
+u->frame_size = pa_frame_size(&u->sink->sample_spec);
+
 return 0;
 }
 
@@ -2345,6 +2365,12 @@ pa_sink *pa_alsa_sink_new(pa_module *m, pa_modargs *ma, 
const char*driver, pa_ca
 goto fail;
 }
 
+u->channels = pa_alsa_get_supported_channels(u->pcm_handle, ss.channels);
+if (!u->channels) {
+pa_log_error("Failed to find any supported sample rates.");
+goto fail;
+}
+
 /* ALSA might tweak the sample spec, so recalculate the frame size */
 frame_size = pa_frame_size(&ss);
 
@@ -2616,6 +2642,9 @@ static void userdata_free(struct userdata *u) {
 if (u->rates)
 pa_xfree(u->rates);
 
+if (u->channels)
+pa_xfree(u->channels);
+
 reserve_done(u);
 monitor_done(u);
 
diff --git a/src/modules/alsa/alsa-source.c b/src/modules/alsa/alsa-source.c
index 31d5bb321..fc8ddaf07 100644
--- a/src/modules/alsa/alsa-source.c
+++ b/src/modules/alsa/alsa-source.c
@@ -100,6 +100,7 @@ struct userdata {
 pa_cvolume hardware_volume;
 
 unsigned int *rates;
+unsigned int *channels;
 
 size_t
 frame_size,
@@ -1466,30 +1467,49 @@ static void 
source_update_requested_latency_cb(pa_source *s) {
 update_sw_params(u);
 }
 
-static int source_reconfigure_cb(pa_source *s, pa_sample_spec *spec, bool 
passthrough) {
+static int source_reconfigure_cb(pa_source *s, pa_sample_spec *spec, 
pa_channel_map *map, bool passthrough) {
 struct userdata *u = s->userdata;
 int i;
-bool supported = false;
-
-/* FIXME: we only update rate for now */
+bool supported_rate = false, supported_channels = false;
 
 pa_assert(u);
 
 for (i = 0; u->rates[i]; i++) {
 if (u->rates[i] == spec->rate) {
-supported = true;
+supported_rate = true;
 break;
 }
 }
 
-if (!supported) {
+if (!supported_rate) {
 pa_log_info("Source does not support sample rate of %d Hz", 
spec->rate);
 return -1;
 }
 
+for (i = 0; u->channels[i]; i++) {
+if (u->channels[i] == spec->channels) {
+suppor

[pulseaudio-discuss] [PATCH] format: Fix rate for HBR passthrough formats

[Arun Raghavan]

In high bitrate mode, we force 192kHz/8ch as the sample format, which is
the expectation for HBR formats (as that is what allows for the largest
possible packet size).
---
 src/pulsecore/core-format.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/pulsecore/core-format.c b/src/pulsecore/core-format.c
index 862a74b5d..096acc3a2 100644
--- a/src/pulsecore/core-format.c
+++ b/src/pulsecore/core-format.c
@@ -248,6 +248,9 @@ int pa_format_info_to_sample_spec_fake(const pa_format_info 
*f, pa_sample_spec *
 
 if (f->encoding == PA_ENCODING_EAC3_IEC61937)
 ss->rate *= 4;
+else if ((f->encoding == PA_ENCODING_TRUEHD_IEC61937) ||
+ (f->encoding == PA_ENCODING_DTSHD_IEC61937))
+ss->rate = 192000;
 
 return 0;
 }
-- 
2.17.0

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

Re: [pulseaudio-discuss] How to prevent certain applications from changing recording volume?

[Arun Raghavan]

On Wed, 23 May 2018, at 8:59 PM, Tanu Kaskinen wrote:
> On Wed, 2018-05-23 at 16:48 +0200, Sven-Hendrik Haase wrote:
> > It changes the device volume. I often have to use web-based conference
> > tools and apparently browsers like auto adjusting the microphone gain.
> > However, this annoys as it is perfectly calibrated for other applications
> > already. There is no way to stop these applications from adjusting the gain
> > and so I'd like to do this at a pulseaudio level.
> 
> Blocking individual operations such as volume adjustments based on the
> application or other criteria isn't currently supported. Wim Taymans
> has written patches for a generic access control infrastructure, but
> I'm not sure if and when those will get to upstream...
> 
> -- 

Might be worth looking for a way to disable AGC on the browser for this case.

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

Re: [pulseaudio-discuss] [PATCH] format: Fix rate for HBR passthrough formats

[Arun Raghavan]

On Tue, 22 May 2018, at 4:32 PM, Alexander E. Patrakov wrote:
> There is some Microsoft documentation that contradicts this code.
> 
> https://msdn.microsoft.com/en-us/library/windows/desktop/dd316761(v=vs.85).aspx
> 
> """
> Dolby TrueHD (MAT)
> 
> Dolby TrueHD content is transmitted over IEC 60958 at 176.4 kHz / 8
> channels (requiring an IEC 60958 frame rate of 705.6 kHz) for content
> sample rates of 44.1, 88.2 and 176.4 kHz, and 192 kHz / 8 channels
> (requiring an IEC 60958 frame rate of 768 kHz) for content sample
> rates of 48, 96 and 192 kHz.
> """

Based on Peter's input in a private thread, seems this is not the case on Linux:

https://github.com/xbmc/xbmc/blob/master/xbmc/cores/AudioEngine/Sinks/AESinkALSA.cpp#L135
https://github.com/xbmc/xbmc/blob/master/xbmc/cores/AudioEngine/Sinks/AESinkALSA.cpp#L486

Cheers,
Arun
 
> 2018-05-22 12:13 GMT+08:00 Arun Raghavan :
> > In high bitrate mode, we force 192kHz/8ch as the sample format, which is
> > the expectation for HBR formats (as that is what allows for the largest
> > possible packet size).
> > ---
> >  src/pulsecore/core-format.c | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/src/pulsecore/core-format.c b/src/pulsecore/core-format.c
> > index 862a74b5d..096acc3a2 100644
> > --- a/src/pulsecore/core-format.c
> > +++ b/src/pulsecore/core-format.c
> > @@ -248,6 +248,9 @@ int pa_format_info_to_sample_spec_fake(const 
> > pa_format_info *f, pa_sample_spec *
> >
> >  if (f->encoding == PA_ENCODING_EAC3_IEC61937)
> >  ss->rate *= 4;
> > +else if ((f->encoding == PA_ENCODING_TRUEHD_IEC61937) ||
> > + (f->encoding == PA_ENCODING_DTSHD_IEC61937))
> > +ss->rate = 192000;
> >
> >  return 0;
> >  }
> > --
> > 2.17.0
> >
> > ___
> > pulseaudio-discuss mailing list
> > pulseaudio-discuss@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
> 
> 
> 
> -- 
> Alexander E. Patrakov
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

[pulseaudio-discuss] [PATCH] format: Expose pa_format_info convenience getters in API

[Arun Raghavan]

We move over helper functions to get rate, channels, channel map and
sample format (if PCM) in the public API, so users of the extended API
are more easily able to pull out these values from pa_format_info.
---
 src/map-file|  4 ++
 src/pulse/format.c  | 89 +
 src/pulse/format.h  | 16 +++
 src/pulsecore/core-format.c | 89 -
 src/pulsecore/core-format.h | 20 -
 5 files changed, 109 insertions(+), 109 deletions(-)

diff --git a/src/map-file b/src/map-file
index 902ce2fd9..aaa1a424f 100644
--- a/src/map-file
+++ b/src/map-file
@@ -177,12 +177,16 @@ pa_format_info_copy;
 pa_format_info_free;
 pa_format_info_from_string;
 pa_format_info_from_sample_spec;
+pa_format_info_get_channel_map;
+pa_format_info_get_channels;
 pa_format_info_get_prop_type;
 pa_format_info_get_prop_int;
 pa_format_info_get_prop_int_range;
 pa_format_info_get_prop_int_array;
 pa_format_info_get_prop_string;
 pa_format_info_get_prop_string_array;
+pa_format_info_get_rate;
+pa_format_info_get_sample_format;
 pa_format_info_free_string_array;
 pa_format_info_is_compatible;
 pa_format_info_is_pcm;
diff --git a/src/pulse/format.c b/src/pulse/format.c
index 07b4420e7..2e90821b9 100644
--- a/src/pulse/format.c
+++ b/src/pulse/format.c
@@ -515,6 +515,95 @@ void pa_format_info_free_string_array(char **values, int 
n_values) {
 pa_xfree(values);
 }
 
+int pa_format_info_get_sample_format(const pa_format_info *f, 
pa_sample_format_t *sf) {
+int r;
+char *sf_str;
+pa_sample_format_t sf_local;
+
+pa_assert(f);
+pa_assert(sf);
+
+r = pa_format_info_get_prop_string(f, PA_PROP_FORMAT_SAMPLE_FORMAT, 
&sf_str);
+if (r < 0)
+return r;
+
+sf_local = pa_parse_sample_format(sf_str);
+pa_xfree(sf_str);
+
+if (!pa_sample_format_valid(sf_local)) {
+pa_log_debug("Invalid sample format.");
+return -PA_ERR_INVALID;
+}
+
+*sf = sf_local;
+
+return 0;
+}
+
+int pa_format_info_get_rate(const pa_format_info *f, uint32_t *rate) {
+int r;
+int rate_local;
+
+pa_assert(f);
+pa_assert(rate);
+
+r = pa_format_info_get_prop_int(f, PA_PROP_FORMAT_RATE, &rate_local);
+if (r < 0)
+return r;
+
+if (!pa_sample_rate_valid(rate_local)) {
+pa_log_debug("Invalid sample rate: %i", rate_local);
+return -PA_ERR_INVALID;
+}
+
+*rate = rate_local;
+
+return 0;
+}
+
+int pa_format_info_get_channels(const pa_format_info *f, uint8_t *channels) {
+int r;
+int channels_local;
+
+pa_assert(f);
+pa_assert(channels);
+
+r = pa_format_info_get_prop_int(f, PA_PROP_FORMAT_CHANNELS, 
&channels_local);
+if (r < 0)
+return r;
+
+if (!pa_channels_valid(channels_local)) {
+pa_log_debug("Invalid channel count: %i", channels_local);
+return -PA_ERR_INVALID;
+}
+
+*channels = channels_local;
+
+return 0;
+}
+
+int pa_format_info_get_channel_map(const pa_format_info *f, pa_channel_map 
*map) {
+int r;
+char *map_str;
+
+pa_assert(f);
+pa_assert(map);
+
+r = pa_format_info_get_prop_string(f, PA_PROP_FORMAT_CHANNEL_MAP, 
&map_str);
+if (r < 0)
+return r;
+
+map = pa_channel_map_parse(map, map_str);
+pa_xfree(map_str);
+
+if (!map) {
+pa_log_debug("Failed to parse channel map.");
+return -PA_ERR_INVALID;
+}
+
+return 0;
+}
+
 void pa_format_info_set_sample_format(pa_format_info *f, pa_sample_format_t 
sf) {
 pa_format_info_set_prop_string(f, PA_PROP_FORMAT_SAMPLE_FORMAT, 
pa_sample_format_to_string(sf));
 }
diff --git a/src/pulse/format.h b/src/pulse/format.h
index 584032fb6..812454b9c 100644
--- a/src/pulse/format.h
+++ b/src/pulse/format.h
@@ -213,6 +213,22 @@ int pa_format_info_get_prop_string_array(const 
pa_format_info *f, const char *ke
 /** Frees a string array returned by \ref 
pa_format_info_get_prop_string_array. \since 2.0 */
 void pa_format_info_free_string_array(char **values, int n_values);
 
+/** Gets the sample format stored in the format info. Returns a negative error 
code on failure. If the sample format property is
+ * not set at all, returns a negative integer. \since 13.0 */
+int pa_format_info_get_sample_format(const pa_format_info *f, 
pa_sample_format_t *sf);
+
+/** Gets the sample rate stored in the format info. Returns a negative error 
code on failure. If the sample rate property is not
+ * set at all, returns a negative integer. \since 13.0 */
+int pa_format_info_get_rate(const pa_format_info *f, uint32_t *rate);
+
+/** Gets the channel count stored in the format info. Returns a negative error 
code on failure. If the channels property is not
+ * set at all, returns a negative integer. \since 13.0 */
+int pa_format_info_get_channels(const pa_format_info *f, uint8_t *channels);
+
+/** Gets the channel map stored in the format info. Returns a negative error 
code on failure. If the channel map prop

Re: [pulseaudio-discuss] [PATCH] sink-input, source-output: Don't remap volume for passthrough streams

[Arun Raghavan]

On Wed, 30 May 2018, at 10:20 PM, Tanu Kaskinen wrote:
> On Sun, 2018-05-20 at 11:35 +0530, Arun Raghavan wrote:
> > This fixes an assert when we try to restore the original volume map on
> > the synthesized (100%) volume of a passthrough stream.
> > ---
> >  src/pulsecore/sink-input.c| 2 +-
> >  src/pulsecore/source-output.c | 2 +-
> >  2 files changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/src/pulsecore/sink-input.c b/src/pulsecore/sink-input.c
> > index 5a55e93a5..ebe5cc957 100644
> > --- a/src/pulsecore/sink-input.c
> > +++ b/src/pulsecore/sink-input.c
> > @@ -403,7 +403,7 @@ int pa_sink_input_new(
> >  if (!data->volume_writable)
> >  data->save_volume = false;
> >  
> > -if (data->volume_is_set)
> > +if (data->volume_is_set && 
> > !pa_sink_input_new_data_is_passthrough(data))
> >  /* The original volume channel map may be different than the final
> >   * stream channel map, so remapping may be needed. */
> >  pa_cvolume_remap(&data->volume, &volume_map, &data->channel_map);
> > diff --git a/src/pulsecore/source-output.c b/src/pulsecore/source-output.c
> > index bcef51fdb..17f5da5e1 100644
> > --- a/src/pulsecore/source-output.c
> > +++ b/src/pulsecore/source-output.c
> > @@ -341,7 +341,7 @@ int pa_source_output_new(
> >  if (!data->volume_writable)
> >  data->save_volume = false;
> >  
> > -if (data->volume_is_set)
> > +if (data->volume_is_set && 
> > !pa_source_output_new_data_is_passthrough(data))
> >  /* The original volume channel map may be different than the final
> >   * stream channel map, so remapping may be needed. */
> >  pa_cvolume_remap(&data->volume, &volume_map, &data->channel_map);
> 
> I already sent a patch for this:
> https://patchwork.freedesktop.org/patch/220793/
> 
> Our patches are slightly different. Both result in the right behaviour
> as far as I can tell. Your patch has the benefit that it does fewer
> changes, my patch on the other hand is more logical in that the
> condition on which volume_map is initialized and the condition on which
> the remapping is done are the same. With your patch volume_map is
> unnecessarily initialized with passthrough PCM streams, but the
> remapping is (correctly) skipped for those streams.

I like your patch better, ack on it from me.

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

Re: [pulseaudio-discuss] [PATCH] alsa-mixer: make the mono mapping a fallback only

[Arun Raghavan]

On Fri, 8 Jun 2018, at 2:09 AM, Tanu Kaskinen wrote:
> On Thu, 2018-06-07 at 17:17 +0200, Georg Chini wrote:
> > On 01.06.2018 10:24, Tanu Kaskinen wrote:
> > > If a sound card doesn't have the "front" device defined for it, we have
> > > to use the "hw" device for stereo. Not so long ago, the analog-stereo
> > > mapping had "hw:%f" in its device-strings and everything worked great,
> > > except that it caused trouble with the Intel HDMI LPE driver that uses
> > > the first "hw" device for HDMI, and we were incorrectly detecting it as
> > > an analog device. That problem was fixed in commit ea3ebd09, which
> > > removed "hw:%f" from analog-stereo and added a new stereo fallback
> > > mapping for "hw".
> > > 
> > > Now the problem is that if a sound card doesn't have the "front" device
> > > defined for it, and it supports both mono and stereo, only the mono
> > > mapping is used, because the stereo mapping is only a fallback. This
> > > patch makes the mono mapping a fallback too, so the mono mapping is used
> > > only if there's absolutely nothing else that works.
> > > 
> > > This can cause trouble at least in theory. Maybe someone actually wants
> > > to use mono output on a card that supports both mono and stereo. But
> > > that seems quite unlikely.
> > > ---
> > >   src/modules/alsa/alsa-mixer.c  |  1 +
> > >   .../alsa/mixer/profile-sets/default.conf   | 18 ++
> > >   2 files changed, 11 insertions(+), 8 deletions(-)
> > > 
> > 
> > Looks good to me. I don't mind having it in 12.0, but let Arun have
> > the last word.
> > 
> > BTW, when are we going to release 12.0? I have not heard any
> > complaints yet.
> 
> Next week seems possible. Hopefully Arun can comment on this patch.
> 
> -- 

From a risk perspective, if there are no or barely any complaints around this, 
I would rather ship 12.0 now and push to next.

Otoh, if that's not the case, I'm okay to merge this to master.

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

Re: [pulseaudio-discuss] [announce] Rust bindings!

[Arun Raghavan]

On Wed, 13 Jun 2018, at 12:59 PM, Tanu Kaskinen wrote:
> On Tue, 2018-06-12 at 19:03 +0100, jnq...@gmail.com wrote:
> > On Tue, 2018-06-12 at 11:22 +0300, Tanu Kaskinen wrote:
> > > On Mon, 2018-05-28 at 19:37 +0100, jnq...@gmail.com wrote:
> > > > Hi everyone!
> > > > 
> > > > Back in February I released 'binding' and 'sys' crates for using
> > > > pulseaudio from Rust code. I had intended to make an announcement
> > > > here
> > > > at the time, but I failed to do so, so I'm doing it now.
> > > > 
> > > > fyi, the 'sys' crates provide a simple description of the C
> > > > interface;
> > > > The 'binding' crates take this further, providing a cleaner/safer
> > > > Rust
> > > > interface.
> > > > 
> > > > I have provided separate crates for each PA system library (per
> > > > Rust
> > > > guidelines for 'sys' crates), thus totalling six in all:
> > > > 
> > > > [binding crates]
> > > >  - libpulse-binding: https://crates.io/crates/libpulse-binding
> > > >  - libpulse-simple-binding: https://crates.io/crates/libpulse-simpl
> > > > e-bi
> > > > nding
> > > >  - libpulse-mainloop-glib-binding: https://crates.io/crates/libpuls
> > > > e-gl
> > > > ib-binding
> > > > [sys crates]
> > > >  - libpulse-sys: https://crates.io/crates/libpulse-sys
> > > >  - libpulse-simple-sys: https://crates.io/crates/libpulse-simple-sy
> > > > s
> > > >  - libpulse-mainloop-glib-sys: https://crates.io/crates/libpulse-ma
> > > > inlo
> > > > op-glib-sys
> > > > 
> > > > The 'binding' crates include plenty of documentation (taken from
> > > > the C
> > > > API). This can be built locally of course (cargo doc), but is also
> > > > available online at docs.rs, example: https://docs.rs/libpulse-bind
> > > > ing/
> > > > 
> > > > Long term I hope that the owners of the PA project itself would
> > > > like to
> > > > take over ownership and maintenance. Even longer term hopefully we
> > > > will
> > > > see PA itself converting to Rust - fyi the PA projects has my full
> > > > consent to use this work of mine in converting PA itself.
> > > 
> > > Cool, thanks for the bindings! I'm afraid you'll have to keep
> > > maintaining the bindings yourself for the foreseeable future - I
> > > don't
> > > really want to take more work for myself at this point (I can of
> > > course
> > > only talk only for myself, but I don't expect the other maintainers
> > > to
> > > be enthusiastically adopting the bindings either). That said,
> > > converting PA to Rust might very well be a good idea. From what I've
> > > heard about combining Rust with C, such conversion could be done
> > > gradually.
> > 
> > Ok no problem :)
> > 
> > I am very glad to hear that you are open to a Rust conversion. I'm very
> > busy at the moment, but I have given a little thought to it over the
> > past few days; perhaps I will try to tackle it at some point.
> 
> No hurry :) Note that I can't alone make the decision to start
> converting to Rust. Not everyone might have as good perception of the
> language as me (and that perception isn't based on actually trying to
> use the language), and not everyone might want to learn it. Arun and
> Georg, how do you feel about the prospect of gradually converting the
> codebase to Rust some day?

I'm 100% behind it. :)

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

Re: [pulseaudio-discuss] Bluetooth aptX codec

[Arun Raghavan]

On Sun, 17 Jun 2018, at 4:01 AM, Pali Rohár wrote:
> Hi! As you may know lot of bluetooth headsets support not only SBC, but
> also aptX codec. And new version of ffmpeg (4.0) has native aptX and
> aptX HD encoder and decoder. AptX codec itself is proprietary, but
> ffmpeg has clean-room implementation based on expired patent. What about
> adding support for aptX via ffmpeg into pulseaudio?
> 
> -- 

I'd actually like to delete the SBC code and replace it with a generic 
GStreamer bin. That would allow us to be codec agnostic, and support any of the 
codecs that are supported by GStreamer (which includes those that ffmpeg 
provides).

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

Re: [pulseaudio-discuss] Bluetooth aptX codec

[Arun Raghavan]

On Wed, 20 Jun 2018, at 9:05 PM, Jan Alexander Steffens wrote:
> On Mon, Jun 18, 2018, 09:42 Pali Rohár  wrote:
> 
> > On Sunday 17 June 2018 23:48:42 Arun Raghavan wrote:
> > > On Sun, 17 Jun 2018, at 4:01 AM, Pali Rohár wrote:
> > > > Hi! As you may know lot of bluetooth headsets support not only SBC, but
> > > > also aptX codec. And new version of ffmpeg (4.0) has native aptX and
> > > > aptX HD encoder and decoder. AptX codec itself is proprietary, but
> > > > ffmpeg has clean-room implementation based on expired patent. What
> > about
> > > > adding support for aptX via ffmpeg into pulseaudio?
> > > >
> > > > --
> > >
> > > I'd actually like to delete the SBC code and replace it with a generic
> > GStreamer bin. That would allow us to be codec agnostic, and support any of
> > the codecs that are supported by GStreamer (which includes those that
> > ffmpeg provides).
> >
> > This does not sound like a good idea. The only two relevant bluetooth
> > codecs for most people are SBC and aptX.
> >
> 
> Don't forget AAC. I've seen this one a lot in devices meant for use with
> iPhones, which apparently don't have aptX. GStreamer has a lot of encoders
> for it so this shouldn't be a problem unless it's some strange AAC variant.
> 
> There's also LDAC but I haven't seen it on a device yet.

Right, there are multiple codecs that we can support, and we should not tie 
ourselves to a specific implementation. For this reason, and more generally, 
I'd like to have PulseAudio not have to deal with any codec implementations at 
all (nor even RTP, if we can help it), hence my preference to use something 
generic in the form of GStreamer.

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

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

[Arun Raghavan]

On Thu, 21 Jun 2018, at 2:54 AM, 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:

Thank you for all the work on this, Tanu!

I've now cherry-picked next onto master and pushed it out. There were a bunch 
of conflicts that I think I got right, but if anyone wants to double-check, 
that would be great (the state change bits and a bunch of  translations during 
the BlueZ 4 removal were the big ones).

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

[pulseaudio-discuss] [PATCH] build-sys: Drop symlinking the generated README

[Arun Raghavan]

Doesn't really work with srcdir != builddir, and we shouldn't really be
messing with files in srcdir anyway.
---
 Makefile.am | 2 --
 1 file changed, 2 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index 30b014c..f1100e3 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -30,9 +30,7 @@ MAINTAINERCLEANFILES=README
 noinst_DATA = README
 
 README:
-   rm -f README
$(MAKE) -C doc README
-   cd $(srcdir) && ln -s doc/README README
 
 homepage: all dist
test -d $$HOME/homepage/private
-- 
2.17.1

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

Re: [pulseaudio-discuss] Bluetooth aptX codec

[Arun Raghavan]

On Thu, 21 Jun 2018, at 4:32 PM, Pali Rohár wrote:
> On Thursday 21 June 2018 05:45:39 Arun Raghavan wrote:
> > On Wed, 20 Jun 2018, at 9:05 PM, Jan Alexander Steffens wrote:
> > > On Mon, Jun 18, 2018, 09:42 Pali Rohár  wrote:
> > > 
> > > > On Sunday 17 June 2018 23:48:42 Arun Raghavan wrote:
> > > > > On Sun, 17 Jun 2018, at 4:01 AM, Pali Rohár wrote:
> > > > > > Hi! As you may know lot of bluetooth headsets support not only SBC, 
> > > > > > but
> > > > > > also aptX codec. And new version of ffmpeg (4.0) has native aptX and
> > > > > > aptX HD encoder and decoder. AptX codec itself is proprietary, but
> > > > > > ffmpeg has clean-room implementation based on expired patent. What
> > > > about
> > > > > > adding support for aptX via ffmpeg into pulseaudio?
> > > > > >
> > > > > > --
> > > > >
> > > > > I'd actually like to delete the SBC code and replace it with a generic
> > > > GStreamer bin. That would allow us to be codec agnostic, and support 
> > > > any of
> > > > the codecs that are supported by GStreamer (which includes those that
> > > > ffmpeg provides).
> > > >
> > > > This does not sound like a good idea. The only two relevant bluetooth
> > > > codecs for most people are SBC and aptX.
> > > >
> > > 
> > > Don't forget AAC. I've seen this one a lot in devices meant for use with
> > > iPhones, which apparently don't have aptX. GStreamer has a lot of encoders
> > > for it so this shouldn't be a problem unless it's some strange AAC 
> > > variant.
> > > 
> > > There's also LDAC but I haven't seen it on a device yet.
> > 
> > Right, there are multiple codecs that we can support, and we should not tie 
> > ourselves to a specific implementation. For this reason, and more 
> > generally, I'd like to have PulseAudio not have to deal with any codec 
> > implementations at all (nor even RTP, if we can help it), hence my 
> > preference to use something generic in the form of GStreamer.
> 
> This is a good idea to let external service to do codec-specific
> functions... I agree that it simplify pulseaudio code and other things
> (like proving new codec by external library -- if properly implemented),
> but in bluetooth context we should look at questions:
> 
> 1) Has gstreamer support for SBC codec?
> 
> 2) Has gstreamer support for aptX codec?
> 
> These are two major codecs supported by bluetooth headsets.
> 
> Answer is: NO
> (SBC is now provided in the "bad" set which is not pre-installed by
> gstreamer)

Pre-installed doesn't mean much tbh. It is easy enough for packages to depend 
on it.

> So gstreamer in current state is not very useful for pulseaudio.

Writing a plugin around an existing decoder is pretty trivial. As is exposing 
libav/ffmpeg codecs.

> Important are also MPEG1/2 (which are defined as optional by A2DP)
> and also AAC and LDAC which Jan wrote. But gstreamer has again only
> plugins in "bad" and "ugly" sets for them; nothing preinstalled by
> default.

Again, -bad doesn't mean much in the current day (historically it was a staging 
ground). -ugly is for codecs that are known to be patent-encumbered (and how 
that's made available is up to packagers).

> To have working bluetooth support in pulseadio, pulseaudio needs to use
> external library for encoding which *always* provides support for SBC.
> And not only if user manually installs some special plugin for 3rd party
> library. (And not only SBC, but also those other aptX, MPEG1/2, AAC and
> LDAC codecs)

So I continue to disagree. Using a generic framework and letting other parts of 
the system select the codec implementation is what makes sense for the widest 
set of use-cases (this also allows products to ship their own implementations 
of a codec without changing the PulseAudio code).

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

Re: [pulseaudio-discuss] inserting filter module into PA-ofono-bluez system

[Arun Raghavan]

On Thu, 5 Jul 2018, at 12:39 PM, d...@rivaretica.com wrote:
> We have a relatively stable working setup behaving like a Bluetooth 
> headset (PA 11.1 + ofono 1.21 + bluez).
> 
> When we try to insert a filter module (for example the original 
> module-virtual-sink.c) by simply loading the module, after few seconds 
> the module changes from "state: RUNNING" to "state: CORKED". Server log 
> output at level 4 is not saying much. The effect on the audio stream 
> during the few seconds of working varies from nothing (if using the 
> original module-virtual-sink.c) to clicking noise (if copy from src to 
> dst is omitted.)
> 
> Is there anything special with this setup that prevents sample virtual 
> sink module from stable running ?

The default configuration that PulseAudio ships with loads 
module-suspend-on-idle which suspends all sinks if there is no stream connected 
(not counting filter sink connections).

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

Re: [pulseaudio-discuss] Planning 12.1

[Arun Raghavan]

On Tue, 10 Jul 2018, at 8:16 PM, Georg Chini wrote:
> On 10.07.2018 14:03, Tanu Kaskinen wrote:
> > Hi all,
> >
> > A few things broke in PulseAudio 12.0: switching bluetooth profile from
> > off to a2dp started crashing, module-ladspa-sink didn't find any
> > plugins any more and module-pipe-sink became unusable in the system
> > mode due to stricter file permissions. These issues have now been
> > fixed, so I propose that we release 12.1 with the following patches:
> >
> >  switch-on-port-available: ignore bluetooth cards
> >  ladspa-sink: fix search path
> >  pipe-sink, pipe-source: fix file permissions
> >
> > Is there anything else that should go in the bugfix release?
> >
> > If nothing surprising pops up, I can do the release this week (maybe
> > even tomorrow).
> >
> Looks OK from my side.

Nothing to add from my side. Will trawl through bug reports in case, but if I 
don't say anything, assume I didn't find anything.

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

Re: [pulseaudio-discuss] Bluetooth aptX codec

[Arun Raghavan]

On Sun, 8 Jul 2018, at 12:14 AM, Pali Rohár wrote:
> On Sunday 08 July 2018 01:44:39 Alexander E. Patrakov wrote:
> > сб, 7 июл. 2018 г. в 19:08, Pali Rohár :
> > >
> > > On Saturday 07 July 2018 09:39:53 Arun Raghavan wrote:
> > > > > This is a good idea to let external service to do codec-specific
> > > > > functions... I agree that it simplify pulseaudio code and other things
> > > > > (like proving new codec by external library -- if properly 
> > > > > implemented),
> > > > > but in bluetooth context we should look at questions:
> > > > >
> > > > > 1) Has gstreamer support for SBC codec?
> > > > >
> > > > > 2) Has gstreamer support for aptX codec?
> > > > >
> > > > > These are two major codecs supported by bluetooth headsets.
> > > > >
> > > > > Answer is: NO
> > > > > (SBC is now provided in the "bad" set which is not pre-installed by
> > > > > gstreamer)
> > > >
> > > > Pre-installed doesn't mean much tbh. It is easy enough for packages to 
> > > > depend on it.
> > >
> > > Can pulseaudio build process enforce it?

Does not need to, that can be taken care of at packaging time, and potentially 
at module load.

> > > > > So gstreamer in current state is not very useful for pulseaudio.
> > > >
> > > > Writing a plugin around an existing decoder is pretty trivial. As is 
> > > > exposing libav/ffmpeg codecs.
> > > >
> > > > > Important are also MPEG1/2 (which are defined as optional by A2DP)
> > > > > and also AAC and LDAC which Jan wrote. But gstreamer has again only
> > > > > plugins in "bad" and "ugly" sets for them; nothing preinstalled by
> > > > > default.
> > > >
> > > > Again, -bad doesn't mean much in the current day (historically it was a 
> > > > staging ground). -ugly is for codecs that are known to be 
> > > > patent-encumbered (and how that's made available is up to packagers).
> > >
> > > Still more distributions does not compile ffmpeg with all codecs due to
> > > patents problems.
> > >
> > > So there is a high chance that we end up in situation that pulseaudio
> > > would not be able to encode audio into codec X (even pulseaudio declare
> > > that it support) and user would not be able to do nothing as his
> > > distribution does not enabled codec X at compile time. It could be
> > > really a legal problem or problem because packager forgot to enable it
> > > or because he think that it could be a problem and rather disabled it.
> > >
> > > The only option to prevent such situation is compile time check. Like
> > > now pulseaudio does not compile bluetooth support when sbc codec is not
> > > available. And this check should be there even after moving to
> > > ffmpeg/gstreamer/whatever. So is this check possible to write in
> > > autoconf for that ffmpeg/gstreamer/whatever?
> > 
> > I disagree here. Speaking here as an author of a patented codec (DTS)
> > implementation that is well supported by PulseAudio ;)
> 
> But this is something different. DTS is not mandatory and devices in
> more cases can work without it (via PCM). But in bluetooth is SBC codec
> mandatory and must be always supported. And there are no license
> problems with SBC for A2DP bluetooth.

This is a package problem, and can be addressed with either load-time arguments 
for what is supported, or by probing.

[...]
> > 1. It is unwise to use ffmpeg because it can be compiled improperly
> > and is difficult to replace in this case.
> 
> Yes, this is the main problem which I'm pointing. Also I do not know if
> ffmpeg has support for (mandatory) SBC codec...
> 
> Now you can either: 1) compile pulseaudio with bluetooth support and
> bluetooth will work always (because it links to system sbc codec
> library) or 2) compile pulseaudio without bluetooth support (and it
> would not work). And for 1) dynamic linking ensure that needed codec
> (sbc) is present/installed as primary dependency.
> 
> > 2. GStreamer can, in theory, wrap the needed libraries, and does
> > support third-party plugins, but does not properly encapsulate the
> > "give me packets ready to send via bluez" part.
> 
> And until this is supported by external library (ffmpeg, gstreamer,
> whatever), pulseaudio needs to implement it itself.
> 
> And encapsulating encoded data for b

Re: [pulseaudio-discuss] [PATCH paprefs] .gitignore: add build

[Arun Raghavan]

On Sat, 21 Jul 2018, at 10:14 PM, Tanu Kaskinen wrote:
> With meson the build directory is always chosen manually, so it can be
> named anything, but in practice "build" is the usual name. Let's add
> that to .gitignore to keep the repository status clean after building.
> ---
>  .gitignore | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/.gitignore b/.gitignore
> index b6ba14d..3aa7349 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -4,6 +4,7 @@ Makefile
>  Makefile.in
>  README
>  aclocal.m4
> +build
>  *.cache
>  compile
>  config.guess
> -- 

Looks good to me. Do you mind me also adding this to PulseAudio?

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

[pulseaudio-discuss] [PATCH] gitignore: Ignore build* directories

[Arun Raghavan]

From: Arun Raghavan 

We already had build-aux, might as well generalise for build directories
we create for autotools out-of-tree builds and anything meson-based.
---
 .gitignore | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.gitignore b/.gitignore
index ef145bbba..21a667e4d 100644
--- a/.gitignore
+++ b/.gitignore
@@ -2,7 +2,7 @@
 .version
 .*.swp
 ABOUT-NLS
-build-aux
+build*
 *~
 *.tar.gz
 *.pc
-- 
2.17.1

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

[pulseaudio-discuss] Moving to GitLab

[Arun Raghavan]

Hi folks,
The freedesktop admins have now started helping projects move to GitLab 
(http://gitlab.freedesktop.org/) on a pilot basis. I'm quite excited about this 
as it would mean a better way to track patches, as well as a more familiar 
interface for new contributors coming from the Github world.

The choices are to move piecemeal (git + merge requests first, bugs later), or 
just do it all at one shot. I favour the latter, in the spirit of absorbing all 
the migration pain at one shot. This is probably a good time in the release 
cycle to do this as well. There's a tracker bug for getting this done at:

  https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/49

Thoughts? Questions?

As a first step, I would request everyone with commit access to set up your 
account and populate your key(s).

Cheers,
Arun

p.s.: Once this is done, I also want to move our CI over.
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

[pulseaudio-discuss] [ANNOUNCE] WebRTC AudioProcessing v0.3.1

[Arun Raghavan]

Hi folks,
I've made a minor release of webrtc-audio-processing. This just includes a 
bunch of pending build fixes that were sitting in git (a big thank you to all 
the contributors, particularly Nicolas).

The release is at:

http://freedesktop.org/software/pulseaudio/webrtc-audio-processing/webrtc-audio-processing-0.3.1.tar.xz
SHA256: a0fdd938fd85272d67e81572c5a4d9e200a0c104753cb3c209ded175ce3c5dbf

Changes:

Release 0.3.1


Lots of build fixes for various platforms.

 git shortlog ----

Arun Raghavan (1):
  build: Update version to 0.3.1

Mirko Vogt (1):
  build: Fix configure option '--with-ns-mode'

Nicolas Dufresne (13):
  Add missing windows specific headers
  build: Add cerbero gnustl support for Android
  build: Don't blindly link to pthread
  build: Add required define for Windows
  build: Properly select the right system wrappers
  build: Define MSVC _WIN32 so we can build on mingw
  Add missing windows conditions variable
  build: Protect against unsupported CPU types
  osx: Fix type OS_FLAGS instead of OS_CFLAGS
  build: Sync defines and libs with build.gn
  build: Use -no-undefined to support both clang and gcc
  build: Re-add pthread linking on linux
  build: Add ARM 64bit support

Thomas Petazzoni (2):
  build: fix architecture detection
  doc: file invalid reference to pulseaudio mailing list
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

[pulseaudio-discuss] Updating review policy for trivial patches

[Arun Raghavan]

Hi folks,
Given limited review bandwidth, we're moving to a discretionary skipping of 
review of trivial patches (yes, trivial is subjective, but hopefully not _too_ 
subjective :) ).

I believe that anything that gets missed in these cases can be picked up by 
those of us reviewing pulseaudio-commits.

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

Re: [pulseaudio-discuss] [PATCH paprefs 0/8] Remove autotools and update README

[Arun Raghavan]

On Wed, 25 Jul 2018, at 7:20 PM, Tanu Kaskinen wrote:
> The README patches are the same that I submitted earlier with a couple
> of changes: the news section now mentions that autotools has been
> replaced with meson, and one commit message needed tweaking now that
> we've had a couple of PulseAudio releases after 12.0.
> 
> Tanu Kaskinen (8):
>   remove the autotools build system
>   README: remove the copyright notice
>   README: add "Bug Reports" and "Contributing Code" sections
>   README: remove the "Acknowledgements" section
>   README: add a news item for the upcoming release
>   README: remove reference to an ancient Debian version
>   README: clarify the PulseAudio version requirement
>   README: remove the page footer
> 
>  .gitignore | 28 --
>  Makefile.am| 61 --
>  autogen.sh | 24 
>  bootstrap.sh   | 67 -
>  configure.ac   | 93 --
>  doc/.gitignore |  2 -
>  doc/README.html.in | 35 +
>  po/.gitignore  | 13 ---
>  src/.gitignore |  2 -
>  src/Makefile.am| 42 -
>  10 files changed, 17 insertions(+), 350 deletions(-)
>  delete mode 100644 Makefile.am
>  delete mode 100755 autogen.sh
>  delete mode 100755 bootstrap.sh
>  delete mode 100644 configure.ac
>  delete mode 100644 doc/.gitignore
>  delete mode 100644 po/.gitignore
>  delete mode 100644 src/.gitignore
>  delete mode 100644 src/Makefile.am
> 
> -- 

Looks good to me.

Packagers, now is the time to scream if you have objections!

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

Re: [pulseaudio-discuss] Moving to GitLab

[Arun Raghavan]

On Wed, 25 Jul 2018, at 5:25 PM, Arun Raghavan wrote:
> Hi folks,
> The freedesktop admins have now started helping projects move to GitLab 
> (http://gitlab.freedesktop.org/) on a pilot basis. I'm quite excited 
> about this as it would mean a better way to track patches, as well as a 
> more familiar interface for new contributors coming from the Github 
> world.
> 
> The choices are to move piecemeal (git + merge requests first, bugs 
> later), or just do it all at one shot. I favour the latter, in the 
> spirit of absorbing all the migration pain at one shot. This is probably 
> a good time in the release cycle to do this as well. There's a tracker 
> bug for getting this done at:
> 
>   https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/49
> 
> Thoughts? Questions?
> 
> As a first step, I would request everyone with commit access to set up 
> your account and populate your key(s).

We're moving ahead with this. Subscribe to the bug above to keep track of 
progress, and I'll send out an update as the big changes happen.

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

Re: [pulseaudio-discuss] Bluetooth aptX codec

[Arun Raghavan]

On Sat, 28 Jul 2018, at 9:01 PM, Pali Rohár wrote:
> On Monday 23 July 2018 18:42:52 Arun Raghavan wrote:
> > On Sun, 8 Jul 2018, at 12:14 AM, Pali Rohár wrote:
> > > On Sunday 08 July 2018 01:44:39 Alexander E. Patrakov wrote:
> > > > сб, 7 июл. 2018 г. в 19:08, Pali Rohár :
> > > > >
> > > > > On Saturday 07 July 2018 09:39:53 Arun Raghavan wrote:
> > > > > > Pre-installed doesn't mean much tbh. It is easy enough for packages 
> > > > > > to depend on it.
> > > > >
> > > > > Can pulseaudio build process enforce it?
> > 
> > Does not need to, that can be taken care of at packaging time, and 
> > potentially at module load.
> 
> Ok, I would ask differently: Can pulseaudio at packaging time enforce it?

That depends on the packaging system, but broadly the answer is yes.

> > > > 2. GStreamer can, in theory, wrap the needed libraries, and does
> > > > support third-party plugins, but does not properly encapsulate the
> > > > "give me packets ready to send via bluez" part.
> > > 
> > > And until this is supported by external library (ffmpeg, gstreamer,
> > > whatever), pulseaudio needs to implement it itself.
> > > 
> > > And encapsulating encoded data for bluez is not enough. It is needed
> > > also to negotiate codec selection with bluez and codec parameters (which
> > > are codec specific).
> > 
> > GStreamer has RTP payloading for sbc, mp3 and aac, so that can easily be 
> > used (and again, less codec-specific stuff that needs to be in PA).
> 
> But it does not solve above problem when it is needed to do A2DP codec
> selection and negotiation.

I don't get what you mean here.

> > > In previous email I wrote about idea to move that codec stuff into bluez
> > > itself as bluez code already handles it for android.
> > > 
> > > > >
> > > > > > > To have working bluetooth support in pulseadio, pulseaudio needs 
> > > > > > > to use
> > > > > > > external library for encoding which *always* provides support for 
> > > > > > > SBC.
> > > > > > > And not only if user manually installs some special plugin for 
> > > > > > > 3rd party
> > > > > > > library. (And not only SBC, but also those other aptX, MPEG1/2, 
> > > > > > > AAC and
> > > > > > > LDAC codecs)
> > > > > >
> > > > > > So I continue to disagree. Using a generic framework and letting 
> > > > > > other parts of the system select the codec implementation is what 
> > > > > > makes sense for the widest set of use-cases (this also allows 
> > > > > > products to ship their own implementations of a codec without 
> > > > > > changing the PulseAudio code).
> > > > >
> > > > > Still this is not enough for bluetooth codec. For specific codec you
> > > > > need to create bluez dbus endpoint with codec specific parameters. 
> > > > > Plus
> > > > > implement select and set methods to decide on codec parameters between
> > > > > pulseaudio and bluetooth headset. And finally to send encoded data you
> > > > > need to know how to send them. To which endpoint, how header looks 
> > > > > like
> > > > > etc... Some codecs needs to wrap data into RTP (e.g. SBC), some must 
> > > > > not
> > > > > have RTP (e.g. aptX). And after that comes data from codec encoder
> > > > > function.
> > > > >
> > > > > So is there any library which all above support? I have not find
> > > > > anything. Nor ffmpeg nor gstreamer.
> > > > >
> > > > > Which means that pulseaudio cannot delegate codec selection, codec
> > > > > initialization and codec encoding to some external library (yet).
> > 
> > At least for SBC and presumably AAC, this is all possible with GStreamer
> 
> No, it is not possible -- or at least I have not found any way how. I
> spend more time with it and Gstreamer does not support it. If you still
> think that it is possible, post a gstreamer code or link how to do that.

Look at the rtpsbcpay/rtpsbcdepay elements, for example.

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

Re: [pulseaudio-discuss] Bluetooth aptX codec

[Arun Raghavan]

On Mon, 30 Jul 2018, at 12:42 PM, Pali Rohár wrote:
[...]
> I looked and there is absolutely nothing about A2DP codec parameter
> selections. So really does not help.

Okay, I feel like this conversation has been us talking past each other, so let 
me try to summarise what I'm saying more clearly:

1. The BlueZ modules will, possibly based on modargs, expose a set of supported 
codecs. Yes, that includes codec parameters, the knowledge of which the 
endpoint needs to have. If you have ideas for making this modular, I'm open to 
suggestions.

2. For the specific process of RTP payload/depayload and selection of a codec 
implementation for encode/decode, I believe we should construct and use a 
GStreamer bin, so as to not have to offload that choice to the system 
integrator rather than having to make that choice in PulseAudio. I feel 
strongly enough about not linking to specific codec implementations that any 
approach that does that is a NACK from me. I realise we already have this for 
SBC, but I do not want to add any more.

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

Re: [pulseaudio-discuss] Moving to GitLab

[Arun Raghavan]

On Fri, 27 Jul 2018, at 6:43 PM, Arun Raghavan wrote:
> On Wed, 25 Jul 2018, at 5:25 PM, Arun Raghavan wrote:
> > Hi folks,
> > The freedesktop admins have now started helping projects move to GitLab 
> > (http://gitlab.freedesktop.org/) on a pilot basis. I'm quite excited 
> > about this as it would mean a better way to track patches, as well as a 
> > more familiar interface for new contributors coming from the Github 
> > world.
> > 
> > The choices are to move piecemeal (git + merge requests first, bugs 
> > later), or just do it all at one shot. I favour the latter, in the 
> > spirit of absorbing all the migration pain at one shot. This is probably 
> > a good time in the release cycle to do this as well. There's a tracker 
> > bug for getting this done at:
> > 
> >   https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/49
> > 
> > Thoughts? Questions?
> > 
> > As a first step, I would request everyone with commit access to set up 
> > your account and populate your key(s).
> 
> We're moving ahead with this. Subscribe to the bug above to keep track 
> of progress, and I'll send out an update as the big changes happen.

And this is done!

The organisation is at: https://gitlab.freedesktop.org/pulseaudio

Existing open bugs have been migrated, and new issues should be filed against 
the relevant project (for example 
https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues)

We are also transitioning from patches sent to the mailing list to MRs (merge 
requests). The simple description of the workflow is that you create a fork 
using the GitLab UI, create a branch, push your changes, and then get back to 
the web UI which will let you create a merge request from your fork/branch. 
(more details at 
https://docs.gitlab.com/ee/gitlab-basics/add-merge-request.html)

That's it. Please chime in if you have questions/comments.

Cheers,
Arun

p.s.: My heartfelt thanks to Daniel Stone and the freedesktop.org admin team 
for the super quick migration.
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Bluetooth aptX codec

[Arun Raghavan]

On Mon, 30 Jul 2018, at 5:14 PM, Pali Rohár wrote:
> On Monday 30 July 2018 17:04:55 Arun Raghavan wrote:
> > On Mon, 30 Jul 2018, at 12:42 PM, Pali Rohár wrote:
> > [...]
> > > I looked and there is absolutely nothing about A2DP codec parameter
> > > selections. So really does not help.
> > 
> > Okay, I feel like this conversation has been us talking past each other, so 
> > let me try to summarise what I'm saying more clearly:
> > 
> > 1. The BlueZ modules will, possibly based on modargs, expose a set of 
> > supported codecs. Yes, that includes codec parameters, the knowledge of 
> > which the endpoint needs to have. If you have ideas for making this 
> > modular, I'm open to suggestions.
> > 
> > 2. For the specific process of RTP payload/depayload and selection of a 
> > codec implementation for encode/decode, I believe we should construct and 
> > use a GStreamer bin, so as to not have to offload that choice to the system 
> > integrator rather than having to make that choice in PulseAudio. I feel 
> > strongly enough about not linking to specific codec implementations that 
> > any approach that does that is a NACK from me. I realise we already have 
> > this for SBC, but I do not want to add any more.
> 
> Look at my last (v2) patch series for aptX. Here I created some
> modularisation of codecs and addition of another codecs would be easier.

Will do. Note that I'm not just talk about modularity w.r.t. codecs, but also 
codec implementations.

> I have not used Gstreamer as it does not help me -- it does not provide
> module for A2DP codec negotiation (it is not static list of parameters
> as you imagine, but negotiation function) nor it does not support aptX
> codec.

That's still not problematic from a GStreamer perspective. It is possible to 
set up parameters via caps if needed after the negotiation stage. And wrapping 
your library in a GStreamer plugin would be a trivial effort.

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

Re: [pulseaudio-discuss] Moving to GitLab

[Arun Raghavan]

On Mon, 30 Jul 2018, at 5:20 PM, Arun Raghavan wrote:
> On Fri, 27 Jul 2018, at 6:43 PM, Arun Raghavan wrote:
> > On Wed, 25 Jul 2018, at 5:25 PM, Arun Raghavan wrote:
> > > Hi folks,
> > > The freedesktop admins have now started helping projects move to GitLab 
> > > (http://gitlab.freedesktop.org/) on a pilot basis. I'm quite excited 
> > > about this as it would mean a better way to track patches, as well as a 
> > > more familiar interface for new contributors coming from the Github 
> > > world.
> > > 
> > > The choices are to move piecemeal (git + merge requests first, bugs 
> > > later), or just do it all at one shot. I favour the latter, in the 
> > > spirit of absorbing all the migration pain at one shot. This is probably 
> > > a good time in the release cycle to do this as well. There's a tracker 
> > > bug for getting this done at:
> > > 
> > >   https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/49
> > > 
> > > Thoughts? Questions?
> > > 
> > > As a first step, I would request everyone with commit access to set up 
> > > your account and populate your key(s).
> > 
> > We're moving ahead with this. Subscribe to the bug above to keep track 
> > of progress, and I'll send out an update as the big changes happen.
> 
> And this is done!
> 
> The organisation is at: https://gitlab.freedesktop.org/pulseaudio
> 
> Existing open bugs have been migrated, and new issues should be filed 
> against the relevant project (for example 
> https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues)
> 
> We are also transitioning from patches sent to the mailing list to MRs 
> (merge requests). The simple description of the workflow is that you 
> create a fork using the GitLab UI, create a branch, push your changes, 
> and then get back to the web UI which will let you create a merge 
> request from your fork/branch. (more details at 
> https://docs.gitlab.com/ee/gitlab-basics/add-merge-request.html)
> 
> That's it. Please chime in if you have questions/comments.

Please note that while pulseaudio-commits will continue to get commit emails, 
pulseaudio-bugs will no longer be functional. You can just go and to the GitLab 
UI and "Watch" the PulseAudio group (or any repo / issue within it) to get the 
same effeect.

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

Re: [pulseaudio-discuss] [PATCH v2 1/2] Modular API for Bluetooth A2DP codec

[Arun Raghavan]

On Sat, 28 Jul 2018, at 9:04 PM, Pali Rohár wrote:
> Move current SBC codec implementation into separate source file and use
> this new API for providing all needed functionality for Bluetooth A2DP.
> 
> Both bluez5-util and module-bluez5-device are changed to use this new
> modular codec API.
> ---
>  src/Makefile.am  |   9 +-
>  src/modules/bluetooth/a2dp-codecs.h  |   5 +-
>  src/modules/bluetooth/bluez5-util.c  | 331 +--
>  src/modules/bluetooth/bluez5-util.h  |  10 +-
>  src/modules/bluetooth/module-bluez5-device.c | 487 ++
>  src/modules/bluetooth/pa-a2dp-codec-sbc.c| 579 
> +++
>  src/modules/bluetooth/pa-a2dp-codec.h|  40 ++
>  7 files changed, 851 insertions(+), 610 deletions(-)
>  create mode 100644 src/modules/bluetooth/pa-a2dp-codec-sbc.c
>  create mode 100644 src/modules/bluetooth/pa-a2dp-codec.h
> 
> diff --git a/src/Makefile.am b/src/Makefile.am
> index f62e7d5c4..411b9e5e5 100644
> --- a/src/Makefile.am
> +++ b/src/Makefile.am
> @@ -2117,6 +2117,7 @@ module_bluetooth_discover_la_CFLAGS = $(AM_CFLAGS) 
> -DPA_MODULE_NAME=module_bluet
>  libbluez5_util_la_SOURCES = \
>   modules/bluetooth/bluez5-util.c \
>   modules/bluetooth/bluez5-util.h \
> + modules/bluetooth/pa-a2dp-codec.h \
>   modules/bluetooth/a2dp-codecs.h
>  if HAVE_BLUEZ_5_OFONO_HEADSET
>  libbluez5_util_la_SOURCES += \
> @@ -2131,6 +2132,10 @@ libbluez5_util_la_LDFLAGS = -avoid-version
>  libbluez5_util_la_LIBADD = $(MODULE_LIBADD) $(DBUS_LIBS)
>  libbluez5_util_la_CFLAGS = $(AM_CFLAGS) $(DBUS_CFLAGS)
>  
> +libbluez5_util_la_SOURCES += modules/bluetooth/pa-a2dp-codec-sbc.c
> +libbluez5_util_la_LIBADD += $(SBC_LIBS)
> +libbluez5_util_la_CFLAGS += $(SBC_CFLAGS)
> +
>  module_bluez5_discover_la_SOURCES = modules/bluetooth/module-bluez5-
> discover.c
>  module_bluez5_discover_la_LDFLAGS = $(MODULE_LDFLAGS)
>  module_bluez5_discover_la_LIBADD = $(MODULE_LIBADD) $(DBUS_LIBS) 
> libbluez5-util.la
> @@ -2138,8 +2143,8 @@ module_bluez5_discover_la_CFLAGS = $(AM_CFLAGS) $
> (DBUS_CFLAGS) -DPA_MODULE_NAME=
>  
>  module_bluez5_device_la_SOURCES = modules/bluetooth/module-bluez5-
> device.c
>  module_bluez5_device_la_LDFLAGS = $(MODULE_LDFLAGS)
> -module_bluez5_device_la_LIBADD = $(MODULE_LIBADD) $(SBC_LIBS) 
> libbluez5-util.la
> -module_bluez5_device_la_CFLAGS = $(AM_CFLAGS) $(SBC_CFLAGS) -
> DPA_MODULE_NAME=module_bluez5_device
> +module_bluez5_device_la_LIBADD = $(MODULE_LIBADD) libbluez5-util.la
> +module_bluez5_device_la_CFLAGS = $(AM_CFLAGS) -
> DPA_MODULE_NAME=module_bluez5_device
>  
>  # Apple Airtunes/RAOP
>  module_raop_sink_la_SOURCES = modules/raop/module-raop-sink.c
> diff --git a/src/modules/bluetooth/a2dp-codecs.h b/src/modules/
> bluetooth/a2dp-codecs.h
> index 8afcfcb24..004975586 100644
> --- a/src/modules/bluetooth/a2dp-codecs.h
> +++ b/src/modules/bluetooth/a2dp-codecs.h
> @@ -47,6 +47,9 @@
>  #define SBC_ALLOCATION_SNR   (1 << 1)
>  #define SBC_ALLOCATION_LOUDNESS  1
>  
> +#define SBC_MIN_BITPOOL 2
> +#define SBC_MAX_BITPOOL 64
> +
>  #define MPEG_CHANNEL_MODE_MONO   (1 << 3)
>  #define MPEG_CHANNEL_MODE_DUAL_CHANNEL   (1 << 2)
>  #define MPEG_CHANNEL_MODE_STEREO (1 << 1)
> @@ -63,8 +66,6 @@
>  #define MPEG_SAMPLING_FREQ_44100 (1 << 1)
>  #define MPEG_SAMPLING_FREQ_48000 1
>  
> -#define MAX_BITPOOL 64
> -#define MIN_BITPOOL 2
>  
>  #if __BYTE_ORDER == __LITTLE_ENDIAN
>  
> diff --git a/src/modules/bluetooth/bluez5-util.c b/src/modules/
> bluetooth/bluez5-util.c
> index 2d8337317..9c4e3367b 100644
> --- a/src/modules/bluetooth/bluez5-util.c
> +++ b/src/modules/bluetooth/bluez5-util.c
> @@ -2,6 +2,7 @@
>This file is part of PulseAudio.
>  
>Copyright 2008-2013 João Paulo Rechi Vita
> +  Copyrigth 2018  Pali Rohár 
>  
>PulseAudio is free software; you can redistribute it and/or modify
>it under the terms of the GNU Lesser General Public License as
> @@ -33,7 +34,7 @@
>  #include 
>  #include 
>  
> -#include "a2dp-codecs.h"
> +#include "pa-a2dp-codec.h"
>  
>  #include "bluez5-util.h"
>  
> @@ -48,8 +49,8 @@
>  
>  #define BLUEZ_ERROR_NOT_SUPPORTED "org.bluez.Error.NotSupported"
>  
> -#define A2DP_SOURCE_ENDPOINT "/MediaEndpoint/A2DPSource"
> -#define A2DP_SINK_ENDPOINT "/MediaEndpoint/A2DPSink"
> +#define A2DP_SOURCE_SBC_ENDPOINT "/MediaEndpoint/A2DPSourceSBC"
> +#define A2DP_SINK_SBC_ENDPOINT "/MediaEndpoint/A2DPSinkSBC"
>  
>  #define ENDPOINT_INTROSPECT_XML 
> \
>  DBUS_INTROSPECT_1_0_XML_DOCTYPE_DECL_NODE   
> \
> @@ -170,9 +171,9 @@ static const char 
> *transport_state_to_string(pa_bluetooth_transport_state_t stat
>  
>  static bool device_supports_profile(pa_bluetooth_device *device, 
> pa_bluetooth_profile_t profile) {
>  switch (profile) {
> -case PA_BLUETOOTH_PROFILE_A2DP_SINK:
> +case P

Re: [pulseaudio-discuss] [PATCH v2 0/2] Bluetooth A2DP aptX codec support

[Arun Raghavan]

On Fri, 3 Aug 2018, at 7:13 PM, ValdikSS wrote:
> On 03.08.2018 16:32, Pali Rohár wrote:
> > On Friday 03 August 2018 16:22:05 ValdikSS wrote:
> >> Doesn't work for me with Intel 7260 Bluetooth 4.0 and RealForce OverDrive 
> >> D1.
> >>
> >> When I connect headphones and change Pulseaudio profile from "Off" to 
> >> "High Fidelity SBC playback (a2dp sink)", everything works as expected 
> >> with SBC.
> >> Profile does not switch if I choose "High Fidelity aptX playback (a2dp 
> >> sink)" when SBC profile is already active, log message:
> >>
> >> W: [pulseaudio] module-bluez5-device.c: Refused to switch profile to 
> >> a2dp_aptx_sink: Not connected
> > Profile switching does not work -- bluez does not provide API for it.
> >
> > Codec is chosen by bluez and headset when doing handshake. Try to
> > initialize A2DP connection from computer, not from headset. Then bluez
> > should choose aptX codec in case your headset supports it.
> 
> Works now:
>   AVDTP: Set Configuration (0x03) Command (0x00) type 0x00 label 10 nosp 0
>     ACP SEID: 5
>     INT SEID: 1
>     Service Category: Media Transport (0x01)
>     Service Category: Media Codec (0x07)
>   Media Type: Audio (0x00)
>   Media Codec: Non-A2DP (0xff)
>     Vendor ID: APT Licensing Ltd. (0x004f)
>     Vendor Specific Codec ID: aptX (0x0001)
>   Frequency: 44100 (0x20)
>   Channel Mode: Stereo (0x02)
> 
> >
> >> When I try to switch to aptX profile from "off" profile, pulseaudio 
> >> crashes:
> >>
> >> E: [pulseaudio] module-bluez5-device.c: Assertion '!u->thread' failed at 
> >> modules/bluetooth/module-bluez5-device.c:1491, function start_thread(). 
> >> Aborting.
> > Try:
> >
> > $ pactl unload-module module-bluetooth-policy
> >
> > Seems that policy module needs to be fixed for new aptx profiles.
> 
> That works, thanks.
> 
> >
> >> Thread 1 "pulseaudio" received signal SIGABRT, Aborted.
> >> 0x744edfeb in raise () from /lib64/libc.so.6
> >> (gdb) bt
> >> #0  0x744edfeb in raise () from /lib64/libc.so.6
> >> #1  0x744d85c1 in abort () from /lib64/libc.so.6
> >> #2  0x7fff7f3dab45 in start_thread (u=u@entry=0x5593d640) at 
> >> modules/bluetooth/module-bluez5-device.c:1491
> >> #3  0x7fff7f3dd263 in set_profile_cb (c=, 
> >> new_profile=0x559251a0) at 
> >> modules/bluetooth/module-bluez5-device.c:1859
> >> #4  0x77b5148e in pa_card_set_profile (c=c@entry=0x558e4c20, 
> >> profile=profile@entry=0x559251a0, save=save@entry=true) at 
> >> pulsecore/card.c:318
> >> #5  0x7fffe0a0362d in command_set_card_profile (pd=, 
> >> command=, tag=127, t=, userdata= >> out>) at pulsecore/protocol-native.c:4728
> >> #6  0x76d83813 in pa_pdispatch_run (pd=0x55a2e4b0, 
> >> packet=packet@entry=0x558a3020, 
> >> ancil_data=ancil_data@entry=0x55975bf8, 
> >> userdata=userdata@entry=0x558bebf0) at pulsecore/pdispatch.c:346
> >> #7  0x7fffe0a0bee9 in pstream_packet_callback (p=0x55975960, 
> >> packet=0x558a3020, ancil_data=0x55975bf8, userdata=0x558bebf0) 
> >> at pulsecore/protocol-native.c:4951
> >> #8  0x76d8629d in do_read (p=p@entry=0x55975960, 
> >> re=re@entry=0x55975b28) at pulsecore/pstream.c:1012
> >> #9  0x76d890eb in do_pstream_read_write (p=0x55975960) at 
> >> pulsecore/pstream.c:248
> >> #10 0x76d8949d in srb_callback (srb=0x558b0660, 
> >> userdata=0x55975960) at pulsecore/pstream.c:287
> >> #11 0x76d89d2a in srbchannel_rwloop (sr=0x558b0660) at 
> >> pulsecore/srbchannel.c:190
> >> #12 0x778fc8a8 in dispatch_pollfds (m=0x5576f120) at 
> >> pulse/mainloop.c:140
> >> #13 pa_mainloop_dispatch (m=m@entry=0x5576f120) at pulse/mainloop.c:898
> >> #14 0x778fcb80 in pa_mainloop_iterate (m=0x5576f120, 
> >> block=, retval=0x7fffdc18) at pulse/mainloop.c:929
> >> #15 0x778fcc20 in pa_mainloop_run (m=0x5576f120, 
> >> retval=0x7fffdc18) at pulse/mainloop.c:945
> >> #16 0xb0c9 in main (argc=, argv= >> out>) at daemon/main.c:1144
> >>
> >>
> >> I haven't installed any patches for bluez itself. Should I? If yes, which 
> >> exactly?
> > There are no bluez patches.
> >
> >> I moved libopenaptx to autotools and made Fedora .spec file for openaptx, 
> >> are you interested in autotools support for libopenaptx, should I create a 
> >> pull request to your repository?
> > Nope, I'm not interested to use autohell, simple Makefile for simple
> > library is enough :-) Basically I see no reason for conversion to tool
> > which then just generate Makefile back.
> 
> I don't like autotools either, but it make packaging much easier since 
> all distros support autotools packaging almost automatically. It also 
> handles shared/static libraries, libtool, different paths and cross-
> compilation with just configure flags.
> It would be maintenance burden to package library with a simpl

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

[Arun Raghavan]

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"
+- NOCONFIGURE=1 ./bootstrap.sh
+- mkdir build
+- cd build
+- ../configure --localstatedir=/var
+- make
+- make check
+- make check-daemon
+- make distcheck
+- 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 \
+gettext \
+git-core \
+libasound2-dev \
+libasyncns-dev \
+libatomic-ops-dev \
+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
+
+# 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
+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

___
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

[Arun Raghavan]

On Thu, 23 Aug 2018, at 6:29 PM, Felipe Sateler wrote:
> 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)

Sure, can do.

> > +- 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.

I'm okay to add that in if you have suggestions for a sensible list (imo this 
can come as a second step).

> > +- 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.

Jobs require artifacts to be passed around, so it's a bit of a pain. I think 
the additional work is worth it for now, as distcheck caught the bug that I 
fixed in the last commit.

> > +- 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).

I'll just add make in for now.

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

It got dropped as a dep with 57e3ccaf51f714eec8ca29005c3cc4fde456e84e.
 
> > +git-core \
> > +libasound2-dev \
> > +libasyncns-dev \
> > +libatomic-ops-dev \
> >
> 
> This is not necessary because gcc has atomic builtins.

Fair enough.

> > +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.

We don't depend on libsystemd, just systemd.

> > +
> > +# 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.

Shouldn't matter as it's about the same (and more clear in some sense).

> > +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
> >

Thanks for the review. I'll update the MR based on this and let's continue 
there.

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

[pulseaudio-discuss] Gitlab CI

[Arun Raghavan]

Hey folks,
I've now pushed and enabled CI for our gitlab instance. This  runs in an Ubuntu 
18.04-based docker image, Dockerfile is in scripts/. For now the image  is 
manually uploaded onto our fd.o docker registry, but it would be good to have 
that be automatically updated when the Dockerfile changes via CI.

I'm not removing the Travis yml yet, but am going to disable the Travis build 
as it is currently broken (because of old Ubuntu).

Fixes for the Travis build welcome (or better yet, for having Gitlab CI build 
with clang and push to Coverity, which are the only feature deltas).

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

Re: [pulseaudio-discuss] [PATCH v2 1/2] Modular API for Bluetooth A2DP codec

[Arun Raghavan]

On Tue, 4 Sep 2018, at 2:14 PM, Tanu Kaskinen wrote:
> Hi Pali!
> 
> Thanks a lot for working on this! Arun has been strongly advocating
> using GStreamer, and I don't know if his position is that "AptX must be
> implemented with GStreamer or not implemented at all". I hope not. To
> me the library choice is not important. Using libopenaptx directly
> doesn't prevent us from switching to GStreamer later if someone writes
> the code.

A couple of notes. Firstly, I really do appreciate all the work that Pali has 
put into this (it is clearly a lot).

Secondly, while I am dead against adding a codec as a dep, once we get things 
in shape where this is the only issue, I volunteer to help with the GStreamer 
bits so as to not block this.

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

[pulseaudio-discuss] Adopting a Code of Conduct

[Arun Raghavan]

Hi everyone,
This has been on my mind for a while, and seeing the freedesktop.org and Linux 
kernel projects finally take it up, I'd like for us to adopt a code of conduct 
as well.

The wording in the Contributor Covenant (https://www.contributor-covenant.org/) 
seems to be succinct but thorough in summarising what I'd like our code of 
conduct to be (i.e. "be excellent to each other"), while also laying out 
explicitly who can be approached for specific issues and also explicitly who is 
responsible of making the community a fostering and welcoming space (namely, 
the maintainers).

I'll send out an MR for this in a bit, but thought I'd kick off a thread for 
discussion if needed.

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

Re: [pulseaudio-discuss] Bluetooth A2DP aptX codec quality

[Arun Raghavan]

On Wed, 12 Sep 2018, at 4:12 PM, Pali Rohár wrote:
> Hello!
> 
> I would like to let you know that Serge from soundexpert.org did in last
> month some research on aptX and its quality. Detailed article is on the
> following website, specially see parts added around "August 2018":
> 
> http://soundexpert.org/news/-/blogs/audio-quality-of-bluetooth-aptx
> 
> 
> Conclusions:
> 
> aptX codec used in BT applications is no better than SBC@328. Despite
> slightly lower algorithmic delay of aptX both SBC and aptX codecs
> provide the same 100-150ms latency in real-life BT applications.
> 
> If you hear the difference between SBC and aptX in some BT product,
> there can be only two explanations - placebo effect or using SBC in
> Middle or Low Quality modes.
> 
> AptX is just a copper-less overpriced audio cable.
> 
> aptX HD is high-bitrate version of aptX. It has clearly noticeable
> increase in sound quality (not dramatic though taking into account the
> increase in bitrate)
> 
> 
> And it just confirms my own testing. Whatever I did I was not able to
> either hear or see difference between aptX and SBC encoded-->decoded
> audio.
> 
> I had discussion with Serge and there are some ideas which Linux
> Bluetooth A2DP software could supports:
> 
> 1) Allow user to specify SBC codec quality. In most cases, including
> pulseaudio, SBC quality is chosen either to middle or low, not to
> maximum bitpool. In some cases SBC at high quality can provide better
> quality as aptX and more important -- SBC is supported by all headsets.
> 
> 2) Show user current SBC codec quality. So user would know what was
> chosen and what should expect. I was told that Windows's Toshiba
> bluetooth stack has support for this indication.
> 
> 3) In some cases SBC SNR bit allocation method can provide better
> quality as SBC loudness method.

Thanks for sharing, this is very interesting.

> So then I could ask question:
> 
> 1) What to do with aptX? It is really useful for users to have it in
> Linux & pulseaudio? Because it looks like that the only thing which it
> has better is lower latency. But can pulseaudio on Linux system really
> achieve it?

What would prevent us from doing so?

> 2) Should we rather look at increasing quality of SBC codec in
> pulseaudio? And if yes, how should be quality of SBC configured? Via
> profiles? Or to invent some new protocol options? Can we increase
> default SBC bitpool allocation?

My preference is to not expose things to the user but try to move towards 

> 3) If aptX is decided as useless, what about aptX HD codec? aptX HD
> codec is supported by less products (currently I do not own any), but
> this one may provide better quality as SBC according to that research.

Right, could still be worth it indeed.

> PS: That aptX research is the first and the only one about which I know.
> All other information about quality or other details which I found on
> internet are just marking informations.

In general, it seems the work to support other codecs could still be valuable 
for AAC and maybe in the future, LDAC? Is anyone aware of a similar comparison 
for the either of these codecs?

AAC is still interesting for passthrough media, of course (I hope to have more 
on the ability to support that in coming weeks/months). Any objective 
information on LDAC would be interesting too.

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

[pulseaudio-discuss] avoid-resampling -> avoid-processing

[Arun Raghavan]

Hello,
I'm thinking that we should change the avoid resampling flag on sinks to 
instead be avoid processing -- the idea being that we try not just to 
reconfigure to a given sample rate, but for the entire sample spec (and 
eventually channel map as well, once the reconfiguration patches are updated to 
address Tanu's comments).

The rationale is that I'd like to avoid having one more aspect of 
configuration, and the use-case to avoid resampling almost certainly applies to 
at least bit depth (16 <-> 24, usually) at least, and at that point, why not 
everything.

We could provide more fine-grained control 
(avoid-resampling/-remapping/-conversion/-channel-mix), but I don't see the 
benefit of this, so I figure a more overarching option is more likely to be 
useful.

Would be nice to hear people's thoughts on this.

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

Re: [pulseaudio-discuss] avoid-resampling -> avoid-processing

[Arun Raghavan]

On Fri, 21 Sep 2018, at 4:33 PM, Sangchul Lee wrote:
> > I'm thinking that we should change the avoid resampling flag on sinks to 
> > instead be avoid processing -- the idea being that we try not just to 
> > reconfigure to a given sample rate, but for the entire sample spec (and 
> > eventually channel map as well, once the reconfiguration patches are 
> > updated to address Tanu's comments).
> >
> > The rationale is that I'd like to avoid having one more aspect of 
> > configuration, and the use-case to avoid resampling almost certainly 
> > applies to at least bit depth (16 <-> 24, usually) at least, and at that 
> > point, why not everything.
> >
> > We could provide more fine-grained control 
> > (avoid-resampling/-remapping/-conversion/-channel-mix), but I don't see the 
> > benefit of this, so I figure a more overarching option is more likely to be 
> > useful.
> 
> I agree with that. Although the pending patches(sorry to tanu, I'll
> update soon that with applying your last comments :)) address
> bit-depth within enabling 'avoid-resampling' option, I also think
> changing the name to any other one is better than now.
> (avoid-processing, avoid-resampler, or another one).

One question -- in avoid-resampling mode, we have a lower bound on the sample 
rate (as the lowest of default and alternate sample rate). Should we do the 
same thing for channels, or let the channel count be as low as 1 if the media 
is so configured?

I have a mild leaning towards the latter as a sanity check.

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

Re: [pulseaudio-discuss] avoid-resampling -> avoid-processing

[Arun Raghavan]

On Fri, 21 Sep 2018, at 6:47 PM, Arun Raghavan wrote:
> On Fri, 21 Sep 2018, at 4:33 PM, Sangchul Lee wrote:
> > > I'm thinking that we should change the avoid resampling flag on sinks to 
> > > instead be avoid processing -- the idea being that we try not just to 
> > > reconfigure to a given sample rate, but for the entire sample spec (and 
> > > eventually channel map as well, once the reconfiguration patches are 
> > > updated to address Tanu's comments).
> > >
> > > The rationale is that I'd like to avoid having one more aspect of 
> > > configuration, and the use-case to avoid resampling almost certainly 
> > > applies to at least bit depth (16 <-> 24, usually) at least, and at that 
> > > point, why not everything.
> > >
> > > We could provide more fine-grained control 
> > > (avoid-resampling/-remapping/-conversion/-channel-mix), but I don't see 
> > > the benefit of this, so I figure a more overarching option is more likely 
> > > to be useful.
> > 
> > I agree with that. Although the pending patches(sorry to tanu, I'll
> > update soon that with applying your last comments :)) address
> > bit-depth within enabling 'avoid-resampling' option, I also think
> > changing the name to any other one is better than now.
> > (avoid-processing, avoid-resampler, or another one).
> 
> One question -- in avoid-resampling mode, we have a lower bound on the 
> sample rate (as the lowest of default and alternate sample rate). Should 
> we do the same thing for channels, or let the channel count be as low as 
> 1 if the media is so configured?
> 
> I have a mild leaning towards the latter as a sanity check.

Rethinking this, I think we should have a lower-bound defined by the 
sample-spec as a whole.

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

Re: [pulseaudio-discuss] Suggestions on how to support avoid-resampling on PulseEffects

[Arun Raghavan]

On Sat, 22 Sep 2018, at 10:03 PM, wellington wallace wrote:
> Hi PA developers!
> 
> As you can see here https://github.com/wwmm/pulseeffects/issues/288 there
> are users that would like to have avoid-resampling supported in
> PulseEffects(and I would like it too). But honestly I am out of good ideas
> about how to do this. At this moment I am using null sinks to do the audio
> routing and there is a Gstreamer pipeline that records from it. I can
> change the format and rate of the GStreamer pipiline to the ones used by
> the audio application being processed but as I can't do the same to the
> null sink it would be pointless. The resampling would happen anyway.
> 
> At this moment the only way I see to support avoid-resampling would be to
> reload the null sink with the new rate and format. But this is really
> annoying because as soon as I kill the null sink Pulseaudio will move the
> audio application back to the default device. It is not impossible to deal
> with this. But it may require major changes in the code.
> 
> Is reloading the null sink the only way to deal with this? It crossed my
> mind to try to make a custom null sink that could change these parameters
> on the fly. But besides the fact that Arch Linux packages do not have
> Pulseaudio developement headers I don't even know if it is possible to make
> any null sink that would accept this.

I have patches in the queue to enable reconfiguration for module-null-sink. 
https://gitlab.freedesktop.org/pulseaudio/pulseaudio/merge_requests/14

Should be easy enough to add a modarg like we have for ALSA to make it also 
just request support at module load time.

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

Re: [pulseaudio-discuss] Suggestions on how to support avoid-resampling on PulseEffects

[Arun Raghavan]

On Sun, 23 Sep 2018, at 6:57 AM, wellington wallace wrote:
> On Sat, Sep 22, 2018 at 9:17 PM Arun Raghavan  wrote:
> 
> >
> >
> > On Sat, 22 Sep 2018, at 10:03 PM, wellington wallace wrote:
> > > Hi PA developers!
> > >
> > > As you can see here https://github.com/wwmm/pulseeffects/issues/288
> > there
> > > are users that would like to have avoid-resampling supported in
> > > PulseEffects(and I would like it too). But honestly I am out of good
> > ideas
> > > about how to do this. At this moment I am using null sinks to do the
> > audio
> > > routing and there is a Gstreamer pipeline that records from it. I can
> > > change the format and rate of the GStreamer pipiline to the ones used by
> > > the audio application being processed but as I can't do the same to the
> > > null sink it would be pointless. The resampling would happen anyway.
> > >
> > > At this moment the only way I see to support avoid-resampling would be to
> > > reload the null sink with the new rate and format. But this is really
> > > annoying because as soon as I kill the null sink Pulseaudio will move the
> > > audio application back to the default device. It is not impossible to
> > deal
> > > with this. But it may require major changes in the code.
> > >
> > > Is reloading the null sink the only way to deal with this? It crossed my
> > > mind to try to make a custom null sink that could change these parameters
> > > on the fly. But besides the fact that Arch Linux packages do not have
> > > Pulseaudio developement headers I don't even know if it is possible to
> > make
> > > any null sink that would accept this.
> >
> > I have patches in the queue to enable reconfiguration for
> > module-null-sink.
> > https://gitlab.freedesktop.org/pulseaudio/pulseaudio/merge_requests/14
> >
> > Should be easy enough to add a modarg like we have for ALSA to make it
> > also just request support at module load time.
> >
> > -- Arun
> >
> 
> Hi Arun! These are very good news! So is the null sink going to
> automatically update its rate like it happens with the sound card sink when
> avoid-resampling is enabled? Or will it be necessary to take action using
> the libpulse api? Based on what I could understand of alsa-sink code it
> seems the first option. Assuming this to be the case is the sampling rate
> update going to trigger the "sink changed" event?
> 
> An automatic reconfiguration would welcome. This way I can focus only on
> the GStreamer pipeline and I wouldn't have different code paths for
> different Pulseaudio versions.

It's the latter. I don't think we emit a sink-changed, but we should.

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

Re: [pulseaudio-discuss] avoid-resampling -> avoid-processing

[Arun Raghavan]

On Wed, 26 Sep 2018, at 5:15 PM, Sangchul Lee wrote:
> > >
> > > We could provide more fine-grained control (avoid-resampling/-
> > > remapping/-conversion/-channel-mix), but I don't see the benefit of
> > > this, so I figure a more overarching option is more likely to be
> > > useful.
> > >
> > > Would be nice to hear people's thoughts on this.
> >
> > Having an "avoid-processing" option is a good idea. I'm not sure what
> > your proposal is for the old "avoid-resampling" option in daemon.conf.
> > I'd like to keep that separate, so that it only affects sample rate
> > conversion.
> 
> I understood the backward compatibility you said. Do I need to modify
> the patch expanding bit-depth("Consider sample format for
> avoid-resampling/passthrough") with the new 'avoid-processing' option?
> (I might upload a patch to the gitlab next time.)

I've got a bunch of  changes waiting on top of hte existing passthrough test 
MR. You probably should work off that. I've got the changes at 
https://gitlab.freedesktop.org/arun/pulseaudio/tree/reconfigure

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

Re: [pulseaudio-discuss] can rewindings in the null sink produce noises in programs recording its monitor?

[Arun Raghavan]

On Tue, 9 Oct 2018, at 1:57 PM, Tanu Kaskinen wrote:
> On Sat, 2018-10-06 at 15:29 -0300, wellington wallace wrote:
> > Hi! PulseEffects developer here again.
> > 
> > Like the title says I'd like to know if rewinds can cause crackling noises
> > when we are recording from a null sink monitor.
> 
> Yes it can: 
> https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/304
> 
> > In PulseEffecs I use the
> > plugin pulsesrc from GStreamer to record the null sink monitor and whenever
> > there is a change in the null sink volume or in the volume of a sink input
> > playing to the null sink I can here noises. Looking at Pulseaudio's logs I
> > can see lines with:
> > 
> > [null-sink] module-null-sink.c: Requested to rewind 3528 bytes.
> > [null-sink] sink.c: Processing rewind...
> > [null-sink] sink-input.c: Have to rewind 2840 bytes on render memblockq.
> > [null-sink] sink-input.c: Have to rewind 1420 bytes on implementor.
> > [null-sink] source.c: Processing rewind...
> > [null-sink] module-null-sink.c: Rewound 2840 bytes.
> > [pulseaudio] module-stream-restore.c: Storing volume/mute/device for stream
> > sink-input-by-media-role:music.
> > [pulseaudio] protocol-native.c: Client spotify changes volume of sink input
> > Spotify.
> > 
> > whenever the application volume is changed. At the same time they are shown
> > I can hear cracklings. So it seems related. I noticed that forcing pulsesrc
> > to use lower latencies help but do not fix the problem. Changing volumes
> > with pulsesrc latency-time parameter set to 1000 us produces less noises
> > than when it is set to 1 us.
> > 
> > I tried my best to see if there is anything I can do on my side to remove
> > this noise I found nothing. Is that how things are or is there anything
> > that can be done to remove this noises?
> 
> This is how things are. It would be great if someone would have a hard
> look at the monitor source rewinding code and see what goes wrong
> there.

I'd love it if someone beat me to it, but I think we need some unit testing for 
this.

In general, I've been trying to add some high-level utilities to allow us to 
write such tests easily, and we need to extend this to do a lot more:

  
https://gitlab.freedesktop.org/pulseaudio/pulseaudio/tree/master/src/tests/lo-test-util.h
  
https://gitlab.freedesktop.org/arun/pulseaudio/blob/reconfigure/src/tests/test-util.h

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

Re: [pulseaudio-discuss] avoid-resampling -> avoid-processing

[Arun Raghavan]

On Thu, 27 Sep 2018, at 11:13 AM, Sangchul Lee wrote:
> 2018년 9월 27일 (목) 오후 12:30, Arun Raghavan 님이 작성:
> >
> > On Wed, 26 Sep 2018, at 5:15 PM, Sangchul Lee wrote:
> > > > >
> > > > > We could provide more fine-grained control (avoid-resampling/-
> > > > > remapping/-conversion/-channel-mix), but I don't see the benefit of
> > > > > this, so I figure a more overarching option is more likely to be
> > > > > useful.
> > > > >
> > > > > Would be nice to hear people's thoughts on this.
> > > >
> > > > Having an "avoid-processing" option is a good idea. I'm not sure what
> > > > your proposal is for the old "avoid-resampling" option in daemon.conf.
> > > > I'd like to keep that separate, so that it only affects sample rate
> > > > conversion.
> > >
> > > I understood the backward compatibility you said. Do I need to modify
> > > the patch expanding bit-depth("Consider sample format for
> > > avoid-resampling/passthrough") with the new 'avoid-processing' option?
> > > (I might upload a patch to the gitlab next time.)
> >
> > I've got a bunch of  changes waiting on top of hte existing passthrough 
> > test MR. You probably should work off that. I've got the changes at 
> > https://gitlab.freedesktop.org/arun/pulseaudio/tree/reconfigure
> 
> I checked commits on your local branch including replacing the option
> name. It will be great to have the previous option with some logs for
> guide according to the "The next best alternative" of tanu's opinion.
> 
> And for now, I'll share V3 of "Consider sample format.." patch without
> changing the name via email soon.

I've implemented this feedback, some automated tests, and other review comments 
in:

  https://gitlab.freedesktop.org/pulseaudio/pulseaudio/merge_requests/24

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

Re: [pulseaudio-discuss] avoid-resampling -> avoid-processing

[Arun Raghavan]

On Fri, 26 Oct 2018, at 11:07 AM, Sangchul Lee wrote:
> 2018년 10월 25일 (목) 오후 11:34, Tanu Kaskinen 님이 작성:
> >
> > On Mon, 2018-10-15 at 09:59 +0530, Arun Raghavan wrote:
> > >
> > > On Thu, 27 Sep 2018, at 11:13 AM, Sangchul Lee wrote:
> > > > 2018년 9월 27일 (목) 오후 12:30, Arun Raghavan 님이 작성:
> > > > > On Wed, 26 Sep 2018, at 5:15 PM, Sangchul Lee wrote:
> > > > > > > > We could provide more fine-grained control (avoid-resampling/-
> > > > > > > > remapping/-conversion/-channel-mix), but I don't see the 
> > > > > > > > benefit of
> > > > > > > > this, so I figure a more overarching option is more likely to be
> > > > > > > > useful.
> > > > > > > >
> > > > > > > > Would be nice to hear people's thoughts on this.
> > > > > > >
> > > > > > > Having an "avoid-processing" option is a good idea. I'm not sure 
> > > > > > > what
> > > > > > > your proposal is for the old "avoid-resampling" option in 
> > > > > > > daemon.conf.
> > > > > > > I'd like to keep that separate, so that it only affects sample 
> > > > > > > rate
> > > > > > > conversion.
> > > > > >
> > > > > > I understood the backward compatibility you said. Do I need to 
> > > > > > modify
> > > > > > the patch expanding bit-depth("Consider sample format for
> > > > > > avoid-resampling/passthrough") with the new 'avoid-processing' 
> > > > > > option?
> > > > > > (I might upload a patch to the gitlab next time.)
> > > > >
> > > > > I've got a bunch of  changes waiting on top of hte existing 
> > > > > passthrough test MR. You probably should work off that. I've got the 
> > > > > changes at 
> > > > > https://gitlab.freedesktop.org/arun/pulseaudio/tree/reconfigure
> > > >
> > > > I checked commits on your local branch including replacing the option
> > > > name. It will be great to have the previous option with some logs for
> > > > guide according to the "The next best alternative" of tanu's opinion.
> > > >
> > > > And for now, I'll share V3 of "Consider sample format.." patch without
> > > > changing the name via email soon.
> > >
> > > I've implemented this feedback, some automated tests, and other review 
> > > comments in:
> > >
> > >   https://gitlab.freedesktop.org/pulseaudio/pulseaudio/merge_requests/24
> >
> > It's a bit unclear to me what the relationship between this MR and
> > "[PATCH v3] alsa-sink/source, sink, source: Consider sample format for
> > avoid-resampling/passthrough" is. Do you two have a common
> > understanding about which should be reviewed first?
> 
> This single patch is the last commit of my patch series for expanding
> 'avoid-' functionalities including checking with supported sample
> formats/rates and resetting hw param. And I think it is still needed
> even if the arun's MR which is wider rage - function parameter
> extension, channel-map things, renaming and null-sink modification -
> is merged. So I'd like to ask you to review this patch first(I think
> it is almost done..) and then rebase arun's MR 'if possible'.

I'm happy to rebase my work on top of this.

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

[pulseaudio-discuss] Revisiting 5.1/7.1 channel positions

[Arun Raghavan]

Hey folks,
I've written up a quick analysis of the channel positions we currently support, 
and what I think makes sense:

  
https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/merge_requests/55#note_85318

The summary is that "Rear Left/Right" is currently being used in place of what 
should be "Left/Right Surround", and we do not have any channel  position 
between that position and "Rear Center", which is needed for common 7.1 
configurations (what would be "Rear Left/Right Surround").

To add to this, the PulseAudio channelmap header is incorrect in that we say 
that "Side Left/Right" should correspond to Dolby "Surround Left/Right" when 
they are separate (they are further forward than "Surround Left/Right". Yhis 
can be corrected easily enough as it's just a documentation comment.

My proposal is to add a "Rear Left/Right of Center" position to represent the 
missing positions. At the ALSA level, it would correspond to RLC/RRC.

Any comments?

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

Re: [pulseaudio-discuss] Revisiting 5.1/7.1 channel positions

[Arun Raghavan]

On Wed, 5 Dec 2018, at 3:59 PM, Tanu Kaskinen wrote:
> On Wed, 2018-12-05 at 15:08 +0530, Arun Raghavan wrote:
> > Hey folks,
> > I've written up a quick analysis of the channel positions we
> > currently support, and what I think makes sense:
> > 
> >   
> > https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/merge_requests/55#note_85318
> > 
> > The summary is that "Rear Left/Right" is currently being used in
> > place of what should be "Left/Right Surround", and we do not have any
> > channel  position between that position and "Rear Center", which is
> > needed for common 7.1 configurations (what would be "Rear Left/Right
> > Surround").
> > 
> > To add to this, the PulseAudio channelmap header is incorrect in that
> > we say that "Side Left/Right" should correspond to Dolby "Surround
> > Left/Right" when they are separate (they are further forward than
> > "Surround Left/Right". Yhis can be corrected easily enough as it's
> > just a documentation comment.
> > 
> > My proposal is to add a "Rear Left/Right of Center" position to
> > represent the missing positions. At the ALSA level, it would
> > correspond to RLC/RRC.
> > 
> > Any comments?
> 
> If I understood correctly, you're proposing that we should have three
> surround channel pairs (side, surround and rear) instead of two (side
> and rear). What practical problem would this solve?
> 
> I'm aware of the problem that some 5.1 streams use side and some use
> rear in their channel map specification (I don't know if there's any
> good reason for this), and up until very recently we didn't handle the
> side case properly. However, Alexander fixed this:
> https://gitlab.freedesktop.org/pulseaudio/pulseaudio/commit/73156649e76ac4000931990edcdcb3be31aade7b

In this case, the problem is that rear left/right means different things based 
on the content.

For 5.1 content, you will use FL, FR, FC, RL, RR, LFE.

Now when you add 2 more channels for 7.1 content, those are supposed to be 
further *behind* the 2 surround channels of 5.1, but we do not have such 
channels. Which means we need to represent 7.1 content as FL, FR, FC, SL, SR, 
RL, RR, LFE.

So Rear Left/Right means different things based on the content, rather than 
have a somewhat fixed notion. This is illustrated in:

  https://www.dolby.com/us/en/guide/dolby-atmos-speaker-setup/5-1-2-setups.html
  https://www.dolby.com/us/en/guide/dolby-atmos-speaker-setup/7-1-2-setups.html

Also, notionally, for Dolby/DTS side left/right is a distinct set of channels 
from surround left/right, though I'm not aware of whether content that provides 
individual streams for those two sets of channel exists (see page 82 of 
https://www.etsi.org/deliver/etsi_ts/102100_102199/102114/01.05.01_60/ts_102114v010501p.pdf).

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

Re: [pulseaudio-discuss] Revisiting 5.1/7.1 channel positions

[Arun Raghavan]

On Wed, 5 Dec 2018, at 5:26 PM, Tanu Kaskinen wrote:
> On Wed, 2018-12-05 at 16:39 +0530, Arun Raghavan wrote:
> > On Wed, 5 Dec 2018, at 3:59 PM, Tanu Kaskinen wrote:
> > > On Wed, 2018-12-05 at 15:08 +0530, Arun Raghavan wrote:
> > > > Hey folks,
> > > > I've written up a quick analysis of the channel positions we
> > > > currently support, and what I think makes sense:
> > > > 
> > > >   
> > > > https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/merge_requests/55#note_85318
> > > > 
> > > > The summary is that "Rear Left/Right" is currently being used in
> > > > place of what should be "Left/Right Surround", and we do not have any
> > > > channel  position between that position and "Rear Center", which is
> > > > needed for common 7.1 configurations (what would be "Rear Left/Right
> > > > Surround").
> > > > 
> > > > To add to this, the PulseAudio channelmap header is incorrect in that
> > > > we say that "Side Left/Right" should correspond to Dolby "Surround
> > > > Left/Right" when they are separate (they are further forward than
> > > > "Surround Left/Right". Yhis can be corrected easily enough as it's
> > > > just a documentation comment.
> > > > 
> > > > My proposal is to add a "Rear Left/Right of Center" position to
> > > > represent the missing positions. At the ALSA level, it would
> > > > correspond to RLC/RRC.
> > > > 
> > > > Any comments?
> > > 
> > > If I understood correctly, you're proposing that we should have three
> > > surround channel pairs (side, surround and rear) instead of two (side
> > > and rear). What practical problem would this solve?
> > > 
> > > I'm aware of the problem that some 5.1 streams use side and some use
> > > rear in their channel map specification (I don't know if there's any
> > > good reason for this), and up until very recently we didn't handle the
> > > side case properly. However, Alexander fixed this:
> > > https://gitlab.freedesktop.org/pulseaudio/pulseaudio/commit/73156649e76ac4000931990edcdcb3be31aade7b
> > 
> > In this case, the problem is that rear left/right means different
> > things based on the content.
> > 
> > For 5.1 content, you will use FL, FR, FC, RL, RR, LFE.
> > 
> > Now when you add 2 more channels for 7.1 content, those are supposed
> > to be further *behind* the 2 surround channels of 5.1, but we do not
> > have such channels. Which means we need to represent 7.1 content as
> > FL, FR, FC, SL, SR, RL, RR, LFE.
> > 
> > So Rear Left/Right means different things based on the content,
> > rather than have a somewhat fixed notion. This is illustrated in:
> > 
> >   
> > https://www.dolby.com/us/en/guide/dolby-atmos-speaker-setup/5-1-2-setups.html
> >   
> > https://www.dolby.com/us/en/guide/dolby-atmos-speaker-setup/7-1-2-setups.html
> 
> According to those illustrations, 5.1 surround channels are exactly the
> same thing as 7.1 side channels (based on the suggested 90-110 degree
> angle). So it would be logical to simply always use the side channels
> instead of the rear channels with 5.1, no need for introducing any new
> channel positions. Then there would be no ambiguity.
> 
> Clients for some reason sometimes use the side channels and sometimes
> the rear channels with 5.1 content. If that indicates a bug, the bug is
> in the clients (well, also in our 5.1 sink channel maps, because we use
> rear instead of side).

At this point, that "bug" is so ubiquitous, I don't think we can really change 
the fact that rear left/right really means surround left/right.

> > Also, notionally, for Dolby/DTS side left/right is a distinct set of
> > channels from surround left/right, though I'm not aware of whether
> > content that provides individual streams for those two sets of
> > channel exists (see page 82 of 
> > https://www.etsi.org/deliver/etsi_ts/102100_102199/102114/01.05.01_60/ts_102114v010501p.pdf
> > ).
> 
> That pdf defines these things:
> "surround on side", angle 90 degrees
> "surround on side in rear", angle 110 degrees
> "surround in rear", angle 150 degrees
> 
> The Dolby illustrations have just one pair of speakers for 90-110
> degrees in both 5.1 and 7.1 configurations, so to satisfy the ETSI
> table, a new channel wouldn't be needed further behind what we 

Re: [pulseaudio-discuss] [PATCH v5 0/7] New API for Bluetooth A2DP codecs

[Arun Raghavan]

On Fri, 25 Jan 2019, at 3:19 PM, Tanu Kaskinen wrote:
> On Sat, 2019-01-19 at 18:11 +0100, Pali Rohár wrote:
> > This is 5th version of my patch series for modular A2DP codec API and
> > aptX support. The only change for v5 is support for switching codecs.
> > 
> > This patch series provides new modular API for Bluetooth A2DP codecs,
> > clean up module-bluez5-device and bluez5-util to be codec independent
> > and convert SBC codec into this new API for A2DP codecs. Also it adds
> > support for aptX, aptX HD and FastStream A2DP codecs.
> > 
> > New codec API is designed in way, that for adding new codec is not
> > needed to touch bluez5-util nor module-bluez5-device files. Whole
> > codec registration is done in a2dp-codec-util.c file, without need
> > to update any header file.
> > 
> > Some A2DP codecs are bidirectional and support backchannel for
> > microphone voice. This new A2DP codec API fully supports this feature
> > and module-bluez5-device was extended to support microphone voice source
> > for codecs which declares such support. FastStream is such codec.
> > 
> > For every A2DP codec is created card profile. When using bluez patches
> > from https://marc.info/?l=linux-bluetooth&m=154696260401673&w=2 then
> > only those profiles codec profiles are created which are supported
> > by remote headset/endpoint.
> 
> As discussed before, I don't think the codec configuration should be
> exposed via card profiles. There is need for being able to say "switch
> to A2DP" without specifying the codec.

I strongly agree with this. Separate profiles for each codec is simply not the 
way to go -- it's horrible for usability.

> It's unclear how priority of the codecs (and their parameter
> permutations) should be configured, but it seems quite clear that a
> "set codec" operation on a specific card would be useful. If the "set
> codec" operation is separate from "set profile" operation, then you no
> doubt will ask how to implement the client API for this new operation,
> and I don't have a very good answer.
> 
> Georg Chini has been working on a new messaging API, which would be a
> good fit for this, but that's stalled (I don't remember if it's waiting
> for review or a new version of the patches). If you don't want to be
> blocked by that, the alternative is to add new "get bluetooth card
> info" and "set bluetooth card a2dp codec" commands to the core protocol
> (the card info command would be for enumerating the available codecs),
> or to add the commands via a new "protocol extension" similar to what
> module-stream-restore, module-device-restore and module-device-manager
> do. I would be fine with either approach.
> 
> Adding new commands to the core protocol would be somewhat simpler, but
> I'm not sure other maintainers are ok with adding bluetooth specific
> functionality to the core protocol.

I don't think adding this to the core is necessarily the best option, but I 
think this is a separate problem.

The current patchset should, imo, just take a priority-ordered list of codecs 
as a modarg and use that (we can choose some default if it is not specified, 
also ideally based on what codecs are supported on the system -- as I've 
suggested before, I don't want us to depend on the codec implementation, but I 
can help deal with that as a separate step).

So the modarg approach gives us a static configuration option for people who 
care about this setting immediately, with a sensible default for most of our 
users who will not. How we can make this runtime configurable can be figured 
out separately (for example, with Georg's on-going work).

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

Re: [pulseaudio-discuss] [PATCH v5 0/7] New API for Bluetooth A2DP codecs

[Arun Raghavan]

On Sat, 26 Jan 2019, at 2:15 PM, Pali Rohár wrote:
> On Saturday 26 January 2019 07:39:54 Arun Raghavan wrote:
> > On Fri, 25 Jan 2019, at 3:19 PM, Tanu Kaskinen wrote:
> > > On Sat, 2019-01-19 at 18:11 +0100, Pali Rohár wrote:
> > > > This is 5th version of my patch series for modular A2DP codec API and
> > > > aptX support. The only change for v5 is support for switching codecs.
> > > > 
> > > > This patch series provides new modular API for Bluetooth A2DP codecs,
> > > > clean up module-bluez5-device and bluez5-util to be codec independent
> > > > and convert SBC codec into this new API for A2DP codecs. Also it adds
> > > > support for aptX, aptX HD and FastStream A2DP codecs.
> > > > 
> > > > New codec API is designed in way, that for adding new codec is not
> > > > needed to touch bluez5-util nor module-bluez5-device files. Whole
> > > > codec registration is done in a2dp-codec-util.c file, without need
> > > > to update any header file.
> > > > 
> > > > Some A2DP codecs are bidirectional and support backchannel for
> > > > microphone voice. This new A2DP codec API fully supports this feature
> > > > and module-bluez5-device was extended to support microphone voice source
> > > > for codecs which declares such support. FastStream is such codec.
> > > > 
> > > > For every A2DP codec is created card profile. When using bluez patches
> > > > from https://marc.info/?l=linux-bluetooth&m=154696260401673&w=2 then
> > > > only those profiles codec profiles are created which are supported
> > > > by remote headset/endpoint.
> > > 
> > > As discussed before, I don't think the codec configuration should be
> > > exposed via card profiles. There is need for being able to say "switch
> > > to A2DP" without specifying the codec.
> > 
> > I strongly agree with this. Separate profiles for each codec is simply not 
> > the way to go -- it's horrible for usability.
> 
> Why it is horrible?
> 
> I think horrible is when you need to introduce a new API into pulseaudio
> core for adding ability for switching to codec which supports
> microphone.
> 
> Same for having hardcoded priority list of codecs somewhere in config
> file or in module argument.
> 
> It would mean that switching to codec with microphone support cannot be
> done in existing GUI tools and it is needed to edit config file or
> re-load bluetooth module. This is horrible.

Perhaps my phrasing was a bit harsh, apologies if you found it so.

Having users to through a drop-down list for codec selection is unfriendly from 
a UX perspective was what I was getting at. For me this is a non-starter. For 
most people, this is configuration they don't and shouldn't care about. We 
should have sensible defaults and they should just work.

For people who do care, you're right, this is a gap in what PulseAudio 
currently supports. While we discuss a solution, a modarg allows us to take the 
existing work forward, especially since that configuration is only one 
independent part of whole.

I do not follow what you mean about codec with a microphone. If you mean A2DP 
source+sink at the same time with one of these codecs, I think this is not 
common enough to make everything else user unfriendly  and we can still try to 
find a way to enable it that doesn't require codec selection via profiles.

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

Re: [pulseaudio-discuss] plan/timeline for a release

[Arun Raghavan]

On Wed, 5 Jun 2019, at 7:29 PM, Pali Rohár wrote:
> On Wednesday 05 June 2019 09:57:01 Georg Chini wrote:
> > On 04.06.19 19:42, Tanu Kaskinen wrote:
> > > On Fri, 2019-05-31 at 16:59 +0300, Kai Vehmanen wrote:
> > > > Hi all,
> > > > 
> > > > I've been testing pulse with the new Intel SOF [1] audio drivers (that 
> > > > are
> > > > going to 5.2 kernel).
> > > > 
> > > > In my tests, e.g. system suspend/stress tests work much better on latest
> > > > master of pulseaudio, compared to test with latest released Pulseaudio.
> > > > 
> > > > At least this patch in PA master has a big improvement:
> > > > "alsa: Improve resume logic after alsa suspend"
> > > > https://gitlab.freedesktop.org/pulseaudio/pulseaudio/commit/f7b3537bbf9a6916ee3fd72a82025519b4c346f5
> > > > 
> > > > With that introduction, any plans for an official Pulseaudio release 
> > > > this
> > > > year? It seems there are many patches in master (like the above) and 
> > > > time
> > > > has passed since 12.2.
> > > > 
> > > > [1] https://thesofproject.github.io/
> > > There are no concrete plans at the moment, but we certainly should make
> > > a release this year (preferably two). According to the usual process we
> > > should have started preparing the release last October, but somehow
> > > that didn't happen... The reason I didn't push for a release last fall
> > > was that there's a certain feature that I secretly wanted to get in
> > > first, and that's still not done. There hasn't been much pressure from
> > > other people either.
> > > 
> > > I think we could freeze master now. I don't want to block the release
> > > waiting for any features, such as the A2DP codec stuff. Arun, Georg,
> > > what are your thoughts?
> > > 
> > I'd like to have the messaging patches in the upcoming release.
> > It should not be too much work to review them and I think I fixed
> > all issues you found during your last review (except one that you
> > can probably fix easily when pushing the patches).
> > Otherwise I would be fine with freezing master and preparing
> > a new release. Do we have any blocker bugs?
> 
> I would like to see reviewed and merged first 5 patches in my bluetooth
> series. Those are just fixes of current code, not new A2DP codecs.

I hoping we could get some of those codec changes in before the release and 
held of suggesting a freeze earlier, but it since slipped my mind and I think 
we should in fact make a release soon.

I suggest we timebox this -- what we are able to confidently review and get in 
over the next 2 weeks makes to go into master before the freeze, the rest we 
can push to next as it's ready, for 14.0 and ideally we'll go back to your 
shorter release cycle for it so it's not a very long wait.

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