Re: [pulseaudio-discuss] [PATCH] sink, source: Rework reconfiguration logic to apply to more than rate
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
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
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
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
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
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
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
--- 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
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
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
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
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
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
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
(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
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
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
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
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
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
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
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
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
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?
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
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
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
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
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
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
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
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
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
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()
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
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
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
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
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
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
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
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
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
--- 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
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()
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
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)
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
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
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
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?
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
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
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
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
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!
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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?
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
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
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
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
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
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
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
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
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