Re: [pulseaudio-discuss] ignore_dB for a specific device

[Tanu Kaskinen]

On Fri, 2019-07-12 at 12:36 +, john terragon wrote:
>  Thanks for the suggestion.
> However, after I sent the email to the list, I realized that using
> ignore_dB causes another problem.
>  It solves the mute/unmute problem but then the volume cannot be
> adjusted any longer. The volume slide moves as I use volup and
> voldown buttons but the volume does not actually change.
> Any idea?

Does this problem only affect the volup and voldown buttons, or does
changing the volume in pavucontrol also have no effect?

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

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

Re: [pulseaudio-discuss] ignore_dB for a specific device

[Tanu Kaskinen]

On Wed, 2019-07-10 at 21:03 +, john terragon wrote:
> Hi
> If I mute a particular card when the volume is below 35%, the volume
> drops to 0 and it's not restored when the card is unmuted.The problem
> is solved by adding
> load-module module-udev-detect ignore_dB=1to default.pa.Since it's
> only one particular card that behaves like this, I was wondering if
> it's possible to set ignore_dB=1 only for that card, instead of
> having it set for all cards in the system.

If you can live without automatic sound card detection, you can comment
out module-udev-detect and load the necessary module-alsa-card
instances manually. You can do the loading in default.pa if you have
the USB sound card plugged in all the time (I assume this is a USB
sound card), or alternatively you can manually use "pactl load-module"
when plugging in the device.

module-alsa-card takes the device_id= argument, which is either the
alsa card index or the alsa card name. Since the index can change, it's
better to use the card name. The card name can be seen in
/proc/asound/cards. For example, I have these cards:

 0 [PCH]: HDA-Intel - HDA Intel PCH
  HDA Intel PCH at 0xd112c000 irq 126
 1 [iTwo   ]: USB-Audio - PreSonus AudioBox iTwo
  PreSonus PreSonus AudioBox iTwo at usb-:00:14.0-6.4, 
high speed

The name to use with the device_id argument would in my case be "PCH"
or "iTwo" (the string between the square brackets).

There's currently no support for disabling ignore_dB for a single card
when using module-udev-detect.

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

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

Re: [pulseaudio-discuss] pulseaudio master is frozen

[Tanu Kaskinen]

On Thu, 2019-07-11 at 09:42 +0200, Pali Rohár wrote:
> On Friday 05 July 2019 15:05:08 Pali Rohár wrote:
> > On Tuesday 02 July 2019 08:56:08 Pali Rohár wrote:
> > > On Tuesday 02 July 2019 08:56:29 Tanu Kaskinen wrote:
> > > > On Mon, 2019-07-01 at 11:29 +0530, Arun Raghavan wrote:
> > > > > Hi folks,
> > > > > As we were discussing, 13.0 is a bit overdue, so we're freezing
> > > > > master now. Release tracker issue is at:
> > > > > 
> > > > >   https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/174
> > > > > 
> > > > > Just as a refresher, this means we will not be landing any new
> > > > > features to master without an explicit exception, and only critical
> > > > > bug fixes should land outside of those changes.
> > > > > 
> > > > > We used to keep a temporary 'next' branch for the times where the
> > > > > freeze cycle went longer and we didn't want to hold reviewed patches
> > > > > back. This may not be necessary any more with the Gitlab merge
> > > > > request system
> > > > > 
> > > > > We have discussed an exception for Pali's initial A2DP fixes,
> > > > > Russell's info script, and the fixes for the pending bug on the
> > > > > tracker relating to detecting when we are running in a VM.
> > > > 
> > > > I had a look at where we are with Pali's patches, and it seems that the
> > > > patches that we really want are reviewed, and there were some
> > > > improvements requested. Therefore this part is currently blocked on
> > > > waiting for new patch versions.
> > > > 
> > > > Pali, do you have fixes for the first three (or even just the first
> > > > two) patches? These:
> > > >  * bluetooth: Fix A2DP codec API to provide information about data
> > > > buffer
> > > >  * bluetooth: Fix usage of RTP structures in SBC codec
> > > >  * bluetooth: Implement reading SO_TIMESTAMP for A2DP source
> > > 
> > > Yes, I have fixes for all these patches. Just I need to squash commits,
> > > properly test them and prepare via format-patch. I guess that tomorrow
> > > evening I should have time for it.
> > 
> > Sorry for delay. Now I sent new version of patches to ML.
> 
> Hi! Would you look at updated patches?

Yes, that's the top priority for me, so I'll do it as I find time
between replying to mailing list and gitlab messages (which seems to
take the bulk of my time).

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

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

Re: [pulseaudio-discuss] [PATCH v2 4/8] core: move sink-inputs conditionally when update default_sink

[Tanu Kaskinen]

On Fri, 2019-07-05 at 11:14 +0200, Georg Chini wrote:
> On 05.07.19 09:56, Tanu Kaskinen wrote:
> > On Tue, 2019-07-02 at 10:25 +0200, Georg Chini wrote:
> > > On 02.07.19 06:49, Tanu Kaskinen wrote:
> > > > On Mon, 2019-07-01 at 08:48 +0200, Georg Chini wrote:
> > > > > On 01.07.19 08:03, Georg Chini wrote:
> > > > > > On 01.07.19 07:08, Tanu Kaskinen wrote:
> > > > > > > On Sun, 2019-06-30 at 13:52 +0200, Georg Chini wrote:
> > > > > > > > On 17.01.19 07:53, Hui Wang wrote:
> > > > > > > > > When the default sink changes, the streams from the old 
> > > > > > > > > default sink
> > > > > > > > > should be moved to the new default sink, unless the 
> > > > > > > > > preferred_sink
> > > > > > > > > string is set to the old default sink and the active port of 
> > > > > > > > > the old
> > > > > > > > > default sink is not unavailable
> > > > > > > > >  +
> > > > > > > > > +void pa_sink_move_streams_to_default_sink(pa_core *core, 
> > > > > > > > > pa_sink
> > > > > > > > > *old_sink, bool from_user) {
> > > > > > > > > +pa_sink_input *i;
> > > > > > > > > +uint32_t idx;
> > > > > > > > > +bool old_sink_is_unavailable;
> > > > > > > > Does this not give a warning about using uninitialized 
> > > > > > > > variables?
> > > > > > > > > +
> > > > > > > > > +pa_assert(core);
> > > > > > > > > +pa_assert(old_sink);
> > > > > > > > > +
> > > > > > > > > +if (old_sink == core->default_sink)
> > > > > > > > > +return;
> > > > > > > > > +
> > > > > > > > > +if (old_sink->active_port && 
> > > > > > > > > old_sink->active_port->available
> > > > > > > > > == PA_AVAILABLE_NO)
> > > > > > > > > +old_sink_is_unavailable = true;
> > > > > > > > This is not sufficient to determine if the old sink is still 
> > > > > > > > available.
> > > > > > > > There are sinks
> > > > > > > > that do not have ports (null-sink, virtual sinks). I think you 
> > > > > > > > will
> > > > > > > > need
> > > > > > > > another boolean
> > > > > > > > argument to the function which indicates availability of the 
> > > > > > > > old sink.
> > > > > > > The definition of an unavailable sink is that its active port is
> > > > > > > unavailable. I don't know what kind of sinks you're thinking about
> > > > > > > here, maybe virtual sinks that are on top of an unavailable 
> > > > > > > hardware
> > > > > > > sink? There are many places where we check the availability of a 
> > > > > > > sink
> > > > > > > this way, and I don't think it makes sense to be different here.
> > > > > > I don't understand. Virtual sinks don't have ports. So checking only
> > > > > > sinks that have an active port excludes all sinks that don't have
> > > > > > ports like the null-sink and virtual sinks. Following your 
> > > > > > definition
> > > > > > above, those sinks are never available.
> > > > You have it reversed: following my definition above, those sinks are
> > > > always available.
> > > Right, sorry. (I seem to be reading things wrong quite often
> > > the last few weeks ... I'll do my best to be more thorough in
> > > the future.)
> > > > > Checking the code, only alsa, bluetooth and raop sinks define ports 
> > > > > and
> > > > > the "many places" you are referring to are compare_sinks() and
> > > > > compare_sources() in core.c and a check in module-switch-on-connect,
> > > > > which is used to determine the availability of the default sink.
> > > > At least module-stream-restore checks device availability too (although
> > > > probably not anymore after this

Re: [pulseaudio-discuss] [PATCH v2 4/8] core: move sink-inputs conditionally when update default_sink

[Tanu Kaskinen]

On Fri, 2019-07-05 at 10:57 +0200, Georg Chini wrote:
> On 05.07.19 09:41, Tanu Kaskinen wrote:
> > On Tue, 2019-07-02 at 09:08 +0200, Georg Chini wrote:
> > > On 02.07.19 08:43, Tanu Kaskinen wrote:
> > > > On Mon, 2019-07-01 at 08:03 +0200, Georg Chini wrote:
> > > > > On 01.07.19 07:08, Tanu Kaskinen wrote:
> > > > > > On Sun, 2019-06-30 at 13:52 +0200, Georg Chini wrote:
> > > > > > > On 17.01.19 07:53, Hui Wang wrote:
> > > > > > > > When the default sink changes, the streams from the old default 
> > > > > > > > sink
> > > > > > > > should be moved to the new default sink, unless the 
> > > > > > > > preferred_sink
> > > > > > > > string is set to the old default sink and the active port of 
> > > > > > > > the old
> > > > > > > > default sink is not unavailable
> > > > > > > > 
> > > > > > > > 
> > > > > > > >  
> > > > > > > >  static pa_hook_result_t sink_put_hook_callback(pa_core *c, 
> > > > > > > > pa_sink *sink, void* userdata) {
> > > > > > > > -pa_sink_input *i;
> > > > > > > > -uint32_t idx;
> > > > > > > > -pa_sink *old_default_sink;
> > > > > > > >  const char *s;
> > > > > > > >  struct userdata *u = userdata;
> > > > > > > >  
> > > > > > > > @@ -88,7 +85,7 @@ static pa_hook_result_t 
> > > > > > > > sink_put_hook_callback(pa_core *c, pa_sink *sink, void*
> > > > > > > >  
> > > > > > > >  /* No default sink, nothing to move away, just set the 
> > > > > > > > new default */
> > > > > > > >  if (!c->default_sink) {
> > > > > > > > -pa_core_set_configured_default_sink(c, sink->name);
> > > > > > > > +pa_core_set_configured_default_sink(c, sink->name, 
> > > > > > > > false);
> > > > > > > >  return PA_HOOK_OK;
> > > > > > > >  }
> > > > > > > >  
> > > > > > > > @@ -103,28 +100,8 @@ static pa_hook_result_t 
> > > > > > > > sink_put_hook_callback(pa_core *c, pa_sink *sink, void*
> > > > > > > >  return PA_HOOK_OK;
> > > > > > > >  }
> > > > > > > >  
> > > > > > > > -old_default_sink = c->default_sink;
> > > > > > > > -
> > > > > > > >  /* Actually do the switch to the new sink */
> > > > > > > > -pa_core_set_configured_default_sink(c, sink->name);
> > > > > > > > -
> > > > > > > > -/* Now move all old inputs over */
> > > > > > > > -if (pa_idxset_size(old_default_sink->inputs) <= 0) {
> > > > > > > > -pa_log_debug("No sink inputs to move away.");
> > > > > > > > -return PA_HOOK_OK;
> > > > > > > > -}
> > > > > > > > -
> > > > > > > > -PA_IDXSET_FOREACH(i, old_default_sink->inputs, idx) {
> > > > > > > > -if (pa_safe_streq(i->sink->name, i->preferred_sink) || 
> > > > > > > > !PA_SINK_INPUT_IS_LINKED(i->state))
> > > > > > > > -continue;
> > > > > > > > -
> > > > > > > > -if (pa_sink_input_move_to(i, sink, false) < 0)
> > > > > > > > -pa_log_info("Failed to move sink input %u \"%s\" 
> > > > > > > > to %s.", i->index,
> > > > > > > > -
> > > > > > > > pa_strnull(pa_proplist_gets(i->proplist, 
> > > > > > > > PA_PROP_APPLICATION_NAME)), sink->name);
> > > > > > > > -else
> > > > > > > > -pa_log_info("Successfully moved sink input %u 
> > > > > > > > \"%s\" to %s.", i->index,
> > > > > > > > -  

Re: [pulseaudio-discuss] [PATCH v2 4/8] core: move sink-inputs conditionally when update default_sink

[Tanu Kaskinen]

On Tue, 2019-07-02 at 10:25 +0200, Georg Chini wrote:
> On 02.07.19 06:49, Tanu Kaskinen wrote:
> > On Mon, 2019-07-01 at 08:48 +0200, Georg Chini wrote:
> > > On 01.07.19 08:03, Georg Chini wrote:
> > > > On 01.07.19 07:08, Tanu Kaskinen wrote:
> > > > > On Sun, 2019-06-30 at 13:52 +0200, Georg Chini wrote:
> > > > > > On 17.01.19 07:53, Hui Wang wrote:
> > > > > > > When the default sink changes, the streams from the old default 
> > > > > > > sink
> > > > > > > should be moved to the new default sink, unless the preferred_sink
> > > > > > > string is set to the old default sink and the active port of the 
> > > > > > > old
> > > > > > > default sink is not unavailable
> > > > > > > +
> > > > > > > +void pa_sink_move_streams_to_default_sink(pa_core *core, pa_sink
> > > > > > > *old_sink, bool from_user) {
> > > > > > > +pa_sink_input *i;
> > > > > > > +uint32_t idx;
> > > > > > > +bool old_sink_is_unavailable;
> > > > > > Does this not give a warning about using uninitialized variables?
> > > > > > > +
> > > > > > > +pa_assert(core);
> > > > > > > +pa_assert(old_sink);
> > > > > > > +
> > > > > > > +if (old_sink == core->default_sink)
> > > > > > > +return;
> > > > > > > +
> > > > > > > +if (old_sink->active_port && old_sink->active_port->available
> > > > > > > == PA_AVAILABLE_NO)
> > > > > > > +old_sink_is_unavailable = true;
> > > > > > This is not sufficient to determine if the old sink is still 
> > > > > > available.
> > > > > > There are sinks
> > > > > > that do not have ports (null-sink, virtual sinks). I think you will
> > > > > > need
> > > > > > another boolean
> > > > > > argument to the function which indicates availability of the old 
> > > > > > sink.
> > > > > The definition of an unavailable sink is that its active port is
> > > > > unavailable. I don't know what kind of sinks you're thinking about
> > > > > here, maybe virtual sinks that are on top of an unavailable hardware
> > > > > sink? There are many places where we check the availability of a sink
> > > > > this way, and I don't think it makes sense to be different here.
> > > > I don't understand. Virtual sinks don't have ports. So checking only
> > > > sinks that have an active port excludes all sinks that don't have
> > > > ports like the null-sink and virtual sinks. Following your definition
> > > > above, those sinks are never available.
> > You have it reversed: following my definition above, those sinks are
> > always available.
> Right, sorry. (I seem to be reading things wrong quite often
> the last few weeks ... I'll do my best to be more thorough in
> the future.)
> > > Checking the code, only alsa, bluetooth and raop sinks define ports and
> > > the "many places" you are referring to are compare_sinks() and
> > > compare_sources() in core.c and a check in module-switch-on-connect,
> > > which is used to determine the availability of the default sink.
> > At least module-stream-restore checks device availability too (although
> > probably not anymore after this patch set, because module-stream-
> > restore won't do the routing directly anymore, it will just restore the
> > preferred_sink variable, which can be done regardless of the sink
> > availability).
> > 
> > Extending the hardware sink availability to filter sinks probably makes
> > sense, but I think that's a topic for a separate patch (or patches).
> > 
> > You suggested an extra flag for pa_sink_move_streams_to_default_sink(),
> > which seems unnecessary to me. The function can in any case figure out
> > the availability by itself (possibly using a helper function
> > pa_sink_is_available() that can handle filter sinks too).
> > 
> I think some additional check is still needed at least for 
> s->unlink_requested
> because when a sink is going to be unlinked and the function is called from
> pa_sink_unlink() in patch 7, there may be nothing else that indicates 
> that the
> sink is going to be removed. When I proposed an addit

Re: [pulseaudio-discuss] [PATCH v2 4/8] core: move sink-inputs conditionally when update default_sink

[Tanu Kaskinen]

On Tue, 2019-07-02 at 09:08 +0200, Georg Chini wrote:
> On 02.07.19 08:43, Tanu Kaskinen wrote:
> > On Mon, 2019-07-01 at 08:03 +0200, Georg Chini wrote:
> > > On 01.07.19 07:08, Tanu Kaskinen wrote:
> > > > On Sun, 2019-06-30 at 13:52 +0200, Georg Chini wrote:
> > > > > On 17.01.19 07:53, Hui Wang wrote:
> > > > > > When the default sink changes, the streams from the old default sink
> > > > > > should be moved to the new default sink, unless the preferred_sink
> > > > > > string is set to the old default sink and the active port of the old
> > > > > > default sink is not unavailable
> > > > > > 
> > > > > > Signed-off-by: Hui Wang 
> > > > > > ---
> > > > > > src/modules/dbus/iface-core.c   |  2 +-
> > > > > > src/modules/module-default-device-restore.c |  2 +-
> > > > > > src/modules/module-switch-on-connect.c  | 27 
> > > > > > ++--
> > > > > > src/pulsecore/cli-command.c |  2 +-
> > > > > > src/pulsecore/core.c| 10 --
> > > > > > src/pulsecore/core.h|  4 +--
> > > > > > src/pulsecore/device-port.c |  2 +-
> > > > > > src/pulsecore/protocol-native.c |  2 +-
> > > > > > src/pulsecore/sink.c| 35 
> > > > > > +++--
> > > > > > src/pulsecore/sink.h|  6 
> > > > > > 10 files changed, 54 insertions(+), 38 deletions(-)
> > > > > > 
> > > > > > diff --git a/src/modules/dbus/iface-core.c 
> > > > > > b/src/modules/dbus/iface-core.c
> > > > > > index 5229c0467..9763480d2 100644
> > > > > > --- a/src/modules/dbus/iface-core.c
> > > > > > +++ b/src/modules/dbus/iface-core.c
> > > > > > @@ -721,7 +721,7 @@ static void 
> > > > > > handle_set_fallback_sink(DBusConnection *conn, DBusMessage *msg, DBu
> > > > > > return;
> > > > > > }
> > > > > > 
> > > > > > -pa_core_set_configured_default_sink(c->core, 
> > > > > > pa_dbusiface_device_get_sink(fallback_sink)->name);
> > > > > > +pa_core_set_configured_default_sink(c->core, 
> > > > > > pa_dbusiface_device_get_sink(fallback_sink)->name, true);
> > > > > > 
> > > > > > pa_dbus_send_empty_reply(conn, msg);
> > > > > > }
> > > > > > diff --git a/src/modules/module-default-device-restore.c 
> > > > > > b/src/modules/module-default-device-restore.c
> > > > > > index c4dbad99f..33e74c071 100644
> > > > > > --- a/src/modules/module-default-device-restore.c
> > > > > > +++ b/src/modules/module-default-device-restore.c
> > > > > > @@ -69,7 +69,7 @@ static void load(struct userdata *u) {
> > > > > > pa_log_warn("Invalid sink name: %s", ln);
> > > > > > else {
> > > > > > pa_log_info("Restoring default sink '%s'.", ln);
> > > > > > -pa_core_set_configured_default_sink(u->core, ln);
> > > > > > +pa_core_set_configured_default_sink(u->core, ln, 
> > > > > > false);
> > > > > > }
> > > > > > 
> > > > > > } else if (errno != ENOENT)
> > > > > > diff --git a/src/modules/module-switch-on-connect.c 
> > > > > > b/src/modules/module-switch-on-connect.c
> > > > > > index f0cb29a7c..3ceac8b4f 100644
> > > > > > --- a/src/modules/module-switch-on-connect.c
> > > > > > +++ b/src/modules/module-switch-on-connect.c
> > > > > > @@ -54,9 +54,6 @@ struct userdata {
> > > > > > };
> > > > > > 
> > > > > > static pa_hook_result_t sink_put_hook_callback(pa_core *c, 
> > > > > > pa_sink *sink, void* userdata) {
> > > > > > -pa_sink_input *i;
> > > > > > -uint32_t idx;
> > > > > > -pa_sink *old_default_sink;
> > &g

Re: [pulseaudio-discuss] [PATCH v2 4/8] core: move sink-inputs conditionally when update default_sink

[Tanu Kaskinen]

On Mon, 2019-07-01 at 08:03 +0200, Georg Chini wrote:
> On 01.07.19 07:08, Tanu Kaskinen wrote:
> > On Sun, 2019-06-30 at 13:52 +0200, Georg Chini wrote:
> > > On 17.01.19 07:53, Hui Wang wrote:
> > > > When the default sink changes, the streams from the old default sink
> > > > should be moved to the new default sink, unless the preferred_sink
> > > > string is set to the old default sink and the active port of the old
> > > > default sink is not unavailable
> > > > 
> > > > Signed-off-by: Hui Wang 
> > > > ---
> > > >src/modules/dbus/iface-core.c   |  2 +-
> > > >src/modules/module-default-device-restore.c |  2 +-
> > > >src/modules/module-switch-on-connect.c  | 27 ++--
> > > >src/pulsecore/cli-command.c |  2 +-
> > > >src/pulsecore/core.c| 10 --
> > > >src/pulsecore/core.h|  4 +--
> > > >src/pulsecore/device-port.c |  2 +-
> > > >src/pulsecore/protocol-native.c |  2 +-
> > > >src/pulsecore/sink.c| 35 
> > > > +++--
> > > >src/pulsecore/sink.h|  6 
> > > >10 files changed, 54 insertions(+), 38 deletions(-)
> > > > 
> > > > diff --git a/src/modules/dbus/iface-core.c 
> > > > b/src/modules/dbus/iface-core.c
> > > > index 5229c0467..9763480d2 100644
> > > > --- a/src/modules/dbus/iface-core.c
> > > > +++ b/src/modules/dbus/iface-core.c
> > > > @@ -721,7 +721,7 @@ static void handle_set_fallback_sink(DBusConnection 
> > > > *conn, DBusMessage *msg, DBu
> > > >return;
> > > >}
> > > >
> > > > -pa_core_set_configured_default_sink(c->core, 
> > > > pa_dbusiface_device_get_sink(fallback_sink)->name);
> > > > +pa_core_set_configured_default_sink(c->core, 
> > > > pa_dbusiface_device_get_sink(fallback_sink)->name, true);
> > > >
> > > >pa_dbus_send_empty_reply(conn, msg);
> > > >}
> > > > diff --git a/src/modules/module-default-device-restore.c 
> > > > b/src/modules/module-default-device-restore.c
> > > > index c4dbad99f..33e74c071 100644
> > > > --- a/src/modules/module-default-device-restore.c
> > > > +++ b/src/modules/module-default-device-restore.c
> > > > @@ -69,7 +69,7 @@ static void load(struct userdata *u) {
> > > >pa_log_warn("Invalid sink name: %s", ln);
> > > >else {
> > > >pa_log_info("Restoring default sink '%s'.", ln);
> > > > -pa_core_set_configured_default_sink(u->core, ln);
> > > > +pa_core_set_configured_default_sink(u->core, ln, false);
> > > >}
> > > >
> > > >} else if (errno != ENOENT)
> > > > diff --git a/src/modules/module-switch-on-connect.c 
> > > > b/src/modules/module-switch-on-connect.c
> > > > index f0cb29a7c..3ceac8b4f 100644
> > > > --- a/src/modules/module-switch-on-connect.c
> > > > +++ b/src/modules/module-switch-on-connect.c
> > > > @@ -54,9 +54,6 @@ struct userdata {
> > > >};
> > > >
> > > >static pa_hook_result_t sink_put_hook_callback(pa_core *c, pa_sink 
> > > > *sink, void* userdata) {
> > > > -pa_sink_input *i;
> > > > -uint32_t idx;
> > > > -pa_sink *old_default_sink;
> > > >const char *s;
> > > >struct userdata *u = userdata;
> > > >
> > > > @@ -88,7 +85,7 @@ static pa_hook_result_t 
> > > > sink_put_hook_callback(pa_core *c, pa_sink *sink, void*
> > > >
> > > >/* No default sink, nothing to move away, just set the new 
> > > > default */
> > > >if (!c->default_sink) {
> > > > -pa_core_set_configured_default_sink(c, sink->name);
> > > > +pa_core_set_configured_default_sink(c, sink->name, false);
> > > >return PA_HOOK_OK;
> > > >}
> > > >
> > > > @@ -103,28 +100,8 @@ static pa_hook_result_t 
> > > > sink_put_hook_callback(pa_core *c, pa_sink *sink, void*
> > >

Re: [pulseaudio-discuss] [PATCH] bluetooth: Fix crash when disabling Bluetooth adapter

[Tanu Kaskinen]

On Wed, 2019-06-19 at 11:09 +0200, Frédéric Danis wrote:
> This crash occurs when PA is connected to a phone through the oFono
> backend.
> When disabling the Bluetooth adapter, pa_bluetooth_device is removed before
> hf_audio_card. Both keep refs on pa_bluetooth_transport. Those removal will
> call pa_bluetooth_transport_free() from device_free() (bluez5-util.c) and
> hf_audio_card_free() (backend-ofono.c).
> In the end, the call to pa_bluetooth_transport_free() calls
> pa_hasmap_remove() through pa_bluetooth_transport_unlink(), but since
> memory has already been freed, the second try results in a segfault.
> 
> Triggering hf_audio_card removal during pa_bluetooth_device removal allows
> hf_audio_card to be freed at the right time.
> ---
>  src/modules/bluetooth/backend-ofono.c | 18 ++
>  src/modules/bluetooth/bluez5-util.c   |  2 ++
>  src/modules/bluetooth/bluez5-util.h   |  1 +
>  3 files changed, 21 insertions(+)
> 
> diff --git a/src/modules/bluetooth/backend-ofono.c 
> b/src/modules/bluetooth/backend-ofono.c
> index 1f0efe923..0e5bbe8b7 100644
> --- a/src/modules/bluetooth/backend-ofono.c
> +++ b/src/modules/bluetooth/backend-ofono.c
> @@ -70,6 +70,7 @@ struct hf_audio_card {
>  int (*acquire)(struct hf_audio_card *card);
>  
>  pa_bluetooth_transport *transport;
> +pa_hook_slot *device_unlink_slot;
>  };
>  
>  struct pa_bluetooth_backend {
> @@ -181,6 +182,17 @@ static int card_acquire(struct hf_audio_card *card) {
>  return -1;
>  }
>  
> +static void hf_audio_agent_card_removed(pa_bluetooth_backend *backend, const 
> char *path);
> +
> +static pa_hook_result_t device_unlink_cb(pa_bluetooth_discovery *y, const 
> pa_bluetooth_device *d, struct hf_audio_card *card) {
> +pa_assert(d);
> +pa_assert(card);
> +
> +hf_audio_agent_card_removed(card->backend, card->path);
> +
> +return PA_HOOK_OK;
> +}
> +
>  static struct hf_audio_card *hf_audio_card_new(pa_bluetooth_backend 
> *backend, const char *path) {
>  struct hf_audio_card *card = pa_xnew0(struct hf_audio_card, 1);
>  
> @@ -189,12 +201,18 @@ static struct hf_audio_card 
> *hf_audio_card_new(pa_bluetooth_backend *backend, co
>  card->fd = -1;
>  card->acquire = card_acquire;
>  
> +card->device_unlink_slot = 
> pa_hook_connect(pa_bluetooth_discovery_hook(backend->discovery, 
> PA_BLUETOOTH_HOOK_DEVICE_UNLINK),
> +   PA_HOOK_NORMAL, 
> (pa_hook_cb_t) device_unlink_cb, card);
> +
>  return card;
>  }
>  
>  static void hf_audio_card_free(struct hf_audio_card *card) {
>  pa_assert(card);
>  
> +if (card->device_unlink_slot)
> +pa_hook_slot_free(card->device_unlink_slot);
> +
>  if (card->transport)
>  pa_bluetooth_transport_free(card->transport);
>  
> diff --git a/src/modules/bluetooth/bluez5-util.c 
> b/src/modules/bluetooth/bluez5-util.c
> index 3c5a000c0..d95c9c117 100644
> --- a/src/modules/bluetooth/bluez5-util.c
> +++ b/src/modules/bluetooth/bluez5-util.c
> @@ -562,6 +562,8 @@ static void device_free(pa_bluetooth_device *d) {
>  
>  device_stop_waiting_for_profiles(d);
>  
> +pa_hook_fire(>discovery->hooks[PA_BLUETOOTH_HOOK_DEVICE_UNLINK], d);
> +
>  for (i = 0; i < PA_BLUETOOTH_PROFILE_COUNT; i++) {
>  pa_bluetooth_transport *t;
>  
> diff --git a/src/modules/bluetooth/bluez5-util.h 
> b/src/modules/bluetooth/bluez5-util.h
> index 82739bffd..1e9caecb4 100644
> --- a/src/modules/bluetooth/bluez5-util.h
> +++ b/src/modules/bluetooth/bluez5-util.h
> @@ -50,6 +50,7 @@ typedef enum pa_bluetooth_hook {
>  PA_BLUETOOTH_HOOK_TRANSPORT_STATE_CHANGED,/* Call data: 
> pa_bluetooth_transport */
>  PA_BLUETOOTH_HOOK_TRANSPORT_MICROPHONE_GAIN_CHANGED,  /* Call data: 
> pa_bluetooth_transport */
>  PA_BLUETOOTH_HOOK_TRANSPORT_SPEAKER_GAIN_CHANGED, /* Call data: 
> pa_bluetooth_transport */
> +PA_BLUETOOTH_HOOK_DEVICE_UNLINK,  /* Call data: 
> pa_bluetooth_device */
>  PA_BLUETOOTH_HOOK_MAX
>  } pa_bluetooth_hook_t;
>  

Thanks! Applied.

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

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

Re: [pulseaudio-discuss] pulseaudio master is frozen

[Tanu Kaskinen]

On Mon, 2019-07-01 at 11:29 +0530, Arun Raghavan wrote:
> Hi folks,
> As we were discussing, 13.0 is a bit overdue, so we're freezing
> master now. Release tracker issue is at:
> 
>   https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/174
> 
> Just as a refresher, this means we will not be landing any new
> features to master without an explicit exception, and only critical
> bug fixes should land outside of those changes.
> 
> We used to keep a temporary 'next' branch for the times where the
> freeze cycle went longer and we didn't want to hold reviewed patches
> back. This may not be necessary any more with the Gitlab merge
> request system
> 
> We have discussed an exception for Pali's initial A2DP fixes,
> Russell's info script, and the fixes for the pending bug on the
> tracker relating to detecting when we are running in a VM.

I had a look at where we are with Pali's patches, and it seems that the
patches that we really want are reviewed, and there were some
improvements requested. Therefore this part is currently blocked on
waiting for new patch versions.

Pali, do you have fixes for the first three (or even just the first
two) patches? These:
 * bluetooth: Fix A2DP codec API to provide information about data
buffer
 * bluetooth: Fix usage of RTP structures in SBC codec
 * bluetooth: Implement reading SO_TIMESTAMP for A2DP source

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

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

Re: [pulseaudio-discuss] [PATCH v2] bluetooth: Fix crash in setup_stream()

[Tanu Kaskinen]

On Tue, 2019-06-18 at 10:15 +0200, Frédéric Danis wrote:
> setup_stream() crashes when calling set_nonblock() with an invalid
> stream_fd.
> 
> On a new call, the ofono backend gets notified of a new connection.
> The ofono backend sets the transport state to playing, and that triggers
> a profile change, which sets up the stream for the first time.
> Then module-bluetooth-policy sets up the loopbacks. The loopbacks get
> fully initialized before the crash.
> 
> After module-bluetooth-policy has done its things, the execution
> continues in the transport state change hook. The next hook user is
> module-bluez5-device, whose handle_transport_state_change() function
> gets called. It will then set up the stream again even though it's
> already set up. I'm not sure if that's a some kind of a bug.
> setup_stream() can handle the case where it's unnecessarily called,
> though, so this second setup is not a big problem.
> 
> The crash happens, because the connection died due to POLLHUP in the IO
> thread before the second setup_stream() call.
> ---
> Changes in v2:
> * Update comments and commit message
> 
>  src/modules/bluetooth/module-bluez5-device.c | 26 ++--
>  1 file changed, 24 insertions(+), 2 deletions(-)
> 
> diff --git a/src/modules/bluetooth/module-bluez5-device.c 
> b/src/modules/bluetooth/module-bluez5-device.c
> index 56c96054d..91c678223 100644
> --- a/src/modules/bluetooth/module-bluez5-device.c
> +++ b/src/modules/bluetooth/module-bluez5-device.c
> @@ -753,6 +753,8 @@ static void setup_stream(struct userdata *u) {
>  struct pollfd *pollfd;
>  int one;
>  
> +pa_assert(u->stream_fd >= 0);
> +
>  /* return if stream is already set up */
>  if (u->stream_setup_done)
>  return;
> @@ -829,7 +831,17 @@ static int source_process_msg(pa_msgobject *o, int code, 
> void *data, int64_t off
>  }
>  
>  case PA_SOURCE_MESSAGE_SETUP_STREAM:
> -setup_stream(u);
> +/* Skip stream setup if stream_fd has been invalidated.
> +   This can occur if the stream has already been set up and
> +   then immediately received POLLHUP. If the stream has
> +   already been set up earlier, then this setup_stream()
> +   call is redundant anyway, but currently the code
> +   is such that this kind of unnecessary setup_stream()
> +   calls can happen. */
> +if (u->stream_fd < 0)
> +pa_log_debug("Skip source stream setup while closing");
> +else
> +setup_stream(u);
>  return 0;
>  
>  }
> @@ -1007,7 +1019,17 @@ static int sink_process_msg(pa_msgobject *o, int code, 
> void *data, int64_t offse
>  }
>  
>  case PA_SINK_MESSAGE_SETUP_STREAM:
> -setup_stream(u);
> +/* Skip stream setup if stream_fd has been invalidated.
> +   This can occur if the stream has already been set up and
> +   then immediately received POLLHUP. If the stream has
> +   already been set up earlier, then this setup_stream()
> +   call is redundant anyway, but currently the code
> +   is such that this kind of unnecessary setup_stream()
> +   calls can happen. */
> +if (u->stream_fd < 0)
> +pa_log_debug("Skip sink stream setup while closing");
> +else
> +setup_stream(u);
>  return 0;
>  }
>  

Thanks! Applied.

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

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

Re: [pulseaudio-discuss] Pavucontrol on Flathub

[Tanu Kaskinen]

On Mon, 2019-07-01 at 11:34 +0530, Arun Raghavan wrote:
> On Mon, 1 Jul 2019, at 11:26 AM, Tanu Kaskinen wrote:
> > On Sat, 2019-06-29 at 10:37 +0530, Arun Raghavan wrote:
> > > Hi folks,
> > > Just a heads-up -- Will Thompson has nice enough to create a flatpak
> > > for pavucontrol. It's on flathub, so you can see it at:
> > > 
> > >   https://flathub.org/apps/details/org.pulseaudio.pavucontrol
> > > 
> > > Instructions on installing are also on that page.
> > > 
> > > For those who are unfamiliar with it, flatpak provides a way to run
> > > applications in a sandbox, against a standard distribution-neutral
> > > runtime. Flathub is a repository for a number of such applications.
> > > 
> > > The code for the flatpak of pavucontrol is at:
> > > 
> > >   https://github.com/flathub/org.pulseaudio.pavucontrol
> > 
> > That's great!
> > 
> > What are your views on what we should or shouldn't do with this in the
> > future? Ideally we'd maintain it upstream, because as a user I'd prefer
> > to trust the upstream rather than some third party when installing
> > flatpaks (and if the upstream maintains the flatpak, it will probably
> > be always up to date). It would just mean some extra work for us when
> > doing releases.
> 
> Yup, I think we should maintain this (Will had asked that we do that
> while writing it, and and I'd signed up for that but more hands are
> definitely welcome). I'll ask Nick Richards to give write permissions
> to you and George (or ideally the PulseAudio organisation).

Once we've set up the procedures for maintaining the flatpak ourselves,
is there any reason to have a separate repository for it? Shouldn't the
flatpak stuff go to the main pavucontrol repo? Not that I have anything
against having push rights to the current github repo for now. (By "the
procedures" I mean documenting how to update the flatpak build files
and how to test them, and following that documentation when doing
releases.)

> > At least the appdata.xml file looks like something that we should
> > maintain ourselves.
> 
> Agreed, but it depends on dropping intltool apparently.

Which you seem to have done in a merge request already. Thanks!

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

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

Re: [pulseaudio-discuss] [PATCH v2 4/8] core: move sink-inputs conditionally when update default_sink

[Tanu Kaskinen]

On Mon, 2019-07-01 at 08:48 +0200, Georg Chini wrote:
> On 01.07.19 08:03, Georg Chini wrote:
> > On 01.07.19 07:08, Tanu Kaskinen wrote:
> > > On Sun, 2019-06-30 at 13:52 +0200, Georg Chini wrote:
> > > > On 17.01.19 07:53, Hui Wang wrote:
> > > > > When the default sink changes, the streams from the old default sink
> > > > > should be moved to the new default sink, unless the preferred_sink
> > > > > string is set to the old default sink and the active port of the old
> > > > > default sink is not unavailable
> 
> 
> > > > >+
> > > > > +void pa_sink_move_streams_to_default_sink(pa_core *core, pa_sink 
> > > > > *old_sink, bool from_user) {
> > > > > +pa_sink_input *i;
> > > > > +uint32_t idx;
> > > > > +bool old_sink_is_unavailable;
> > > > Does this not give a warning about using uninitialized variables?
> > > > > +
> > > > > +pa_assert(core);
> > > > > +pa_assert(old_sink);
> > > > > +
> > > > > +if (old_sink == core->default_sink)
> > > > > +return;
> > > > > +
> > > > > +if (old_sink->active_port && old_sink->active_port->available 
> > > > > == PA_AVAILABLE_NO)
> > > > > +old_sink_is_unavailable = true;
> > > > This is not sufficient to determine if the old sink is still available.
> > > > There are sinks
> > > > that do not have ports (null-sink, virtual sinks). I think you will 
> > > > need
> > > > another boolean
> > > > argument to the function which indicates availability of the old sink.
> > > The definition of an unavailable sink is that its active port is
> > > unavailable. I don't know what kind of sinks you're thinking about
> > > here, maybe virtual sinks that are on top of an unavailable hardware
> > > sink? There are many places where we check the availability of a sink
> > > this way, and I don't think it makes sense to be different here.
> > 
> > I don't understand. Virtual sinks don't have ports. So checking only
> > sinks that have an active port excludes all sinks that don't have
> > ports like the null-sink and virtual sinks. Following your definition
> > above, those sinks are never available.

You have it reversed: following my definition above, those sinks are
always available.

> Checking the code, only alsa, bluetooth and raop sinks define ports and
> the "many places" you are referring to are compare_sinks() and
> compare_sources() in core.c and a check in module-switch-on-connect,
> which is used to determine the availability of the default sink.

At least module-stream-restore checks device availability too (although
probably not anymore after this patch set, because module-stream-
restore won't do the routing directly anymore, it will just restore the
preferred_sink variable, which can be done regardless of the sink
availability).

Extending the hardware sink availability to filter sinks probably makes
sense, but I think that's a topic for a separate patch (or patches).

You suggested an extra flag for pa_sink_move_streams_to_default_sink(),
which seems unnecessary to me. The function can in any case figure out
the availability by itself (possibly using a helper function
pa_sink_is_available() that can handle filter sinks too).

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

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

Re: [pulseaudio-discuss] Pavucontrol on Flathub

[Tanu Kaskinen]

On Sat, 2019-06-29 at 10:37 +0530, Arun Raghavan wrote:
> Hi folks,
> Just a heads-up -- Will Thompson has nice enough to create a flatpak
> for pavucontrol. It's on flathub, so you can see it at:
> 
>   https://flathub.org/apps/details/org.pulseaudio.pavucontrol
> 
> Instructions on installing are also on that page.
> 
> For those who are unfamiliar with it, flatpak provides a way to run
> applications in a sandbox, against a standard distribution-neutral
> runtime. Flathub is a repository for a number of such applications.
> 
> The code for the flatpak of pavucontrol is at:
> 
>   https://github.com/flathub/org.pulseaudio.pavucontrol

That's great!

What are your views on what we should or shouldn't do with this in the
future? Ideally we'd maintain it upstream, because as a user I'd prefer
to trust the upstream rather than some third party when installing
flatpaks (and if the upstream maintains the flatpak, it will probably
be always up to date). It would just mean some extra work for us when
doing releases.

At least the appdata.xml file looks like something that we should
maintain ourselves.

We should probably advertise this on the pavucontrol home page.

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

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

Re: [pulseaudio-discuss] [PATCH v2 4/8] core: move sink-inputs conditionally when update default_sink

[Tanu Kaskinen]

On Sun, 2019-06-30 at 13:52 +0200, Georg Chini wrote:
> On 17.01.19 07:53, Hui Wang wrote:
> > When the default sink changes, the streams from the old default sink
> > should be moved to the new default sink, unless the preferred_sink
> > string is set to the old default sink and the active port of the old
> > default sink is not unavailable
> > 
> > Signed-off-by: Hui Wang 
> > ---
> >   src/modules/dbus/iface-core.c   |  2 +-
> >   src/modules/module-default-device-restore.c |  2 +-
> >   src/modules/module-switch-on-connect.c  | 27 ++--
> >   src/pulsecore/cli-command.c |  2 +-
> >   src/pulsecore/core.c| 10 --
> >   src/pulsecore/core.h|  4 +--
> >   src/pulsecore/device-port.c |  2 +-
> >   src/pulsecore/protocol-native.c |  2 +-
> >   src/pulsecore/sink.c| 35 +++--
> >   src/pulsecore/sink.h|  6 
> >   10 files changed, 54 insertions(+), 38 deletions(-)
> > 
> > diff --git a/src/modules/dbus/iface-core.c b/src/modules/dbus/iface-core.c
> > index 5229c0467..9763480d2 100644
> > --- a/src/modules/dbus/iface-core.c
> > +++ b/src/modules/dbus/iface-core.c
> > @@ -721,7 +721,7 @@ static void handle_set_fallback_sink(DBusConnection 
> > *conn, DBusMessage *msg, DBu
> >   return;
> >   }
> >   
> > -pa_core_set_configured_default_sink(c->core, 
> > pa_dbusiface_device_get_sink(fallback_sink)->name);
> > +pa_core_set_configured_default_sink(c->core, 
> > pa_dbusiface_device_get_sink(fallback_sink)->name, true);
> >   
> >   pa_dbus_send_empty_reply(conn, msg);
> >   }
> > diff --git a/src/modules/module-default-device-restore.c 
> > b/src/modules/module-default-device-restore.c
> > index c4dbad99f..33e74c071 100644
> > --- a/src/modules/module-default-device-restore.c
> > +++ b/src/modules/module-default-device-restore.c
> > @@ -69,7 +69,7 @@ static void load(struct userdata *u) {
> >   pa_log_warn("Invalid sink name: %s", ln);
> >   else {
> >   pa_log_info("Restoring default sink '%s'.", ln);
> > -pa_core_set_configured_default_sink(u->core, ln);
> > +pa_core_set_configured_default_sink(u->core, ln, false);
> >   }
> >   
> >   } else if (errno != ENOENT)
> > diff --git a/src/modules/module-switch-on-connect.c 
> > b/src/modules/module-switch-on-connect.c
> > index f0cb29a7c..3ceac8b4f 100644
> > --- a/src/modules/module-switch-on-connect.c
> > +++ b/src/modules/module-switch-on-connect.c
> > @@ -54,9 +54,6 @@ struct userdata {
> >   };
> >   
> >   static pa_hook_result_t sink_put_hook_callback(pa_core *c, pa_sink *sink, 
> > void* userdata) {
> > -pa_sink_input *i;
> > -uint32_t idx;
> > -pa_sink *old_default_sink;
> >   const char *s;
> >   struct userdata *u = userdata;
> >   
> > @@ -88,7 +85,7 @@ static pa_hook_result_t sink_put_hook_callback(pa_core 
> > *c, pa_sink *sink, void*
> >   
> >   /* No default sink, nothing to move away, just set the new default */
> >   if (!c->default_sink) {
> > -pa_core_set_configured_default_sink(c, sink->name);
> > +pa_core_set_configured_default_sink(c, sink->name, false);
> >   return PA_HOOK_OK;
> >   }
> >   
> > @@ -103,28 +100,8 @@ static pa_hook_result_t sink_put_hook_callback(pa_core 
> > *c, pa_sink *sink, void*
> >   return PA_HOOK_OK;
> >   }
> >   
> > -old_default_sink = c->default_sink;
> > -
> >   /* Actually do the switch to the new sink */
> > -pa_core_set_configured_default_sink(c, sink->name);
> > -
> > -/* Now move all old inputs over */
> > -if (pa_idxset_size(old_default_sink->inputs) <= 0) {
> > -pa_log_debug("No sink inputs to move away.");
> > -return PA_HOOK_OK;
> > -}
> > -
> > -PA_IDXSET_FOREACH(i, old_default_sink->inputs, idx) {
> > -if (pa_safe_streq(i->sink->name, i->preferred_sink) || 
> > !PA_SINK_INPUT_IS_LINKED(i->state))
> > -continue;
> > -
> > -if (pa_sink_input_move_to(i, sink, false) < 0)
> > -pa_log_info("Failed to move sink input %u \"%s\" to %s.", 
> > i->index,
> > -pa_strnull(pa_proplist_gets(i->proplist, 
> > PA_PROP_APPLICATION_NAME)), sink->name);
> > -else
> > -pa_log_info("Successfully moved sink input %u \"%s\" to %s.", 
> > i->index,
> > -pa_strnull(pa_proplist_gets(i->proplist, 
> > PA_PROP_APPLICATION_NAME)), sink->name);
> > -}
> > +pa_core_set_configured_default_sink(c, sink->name, false);
> 
> I wonder if we could use something like 
> pa_core_set_temporary_default_sink() here
> and have a variable core->temporary_default_sink that has even higher 
> priority
> than core->configured_default_sink in the default sink selection 
> process. The temporary
> default sink could be reset when the sink 

Re: [pulseaudio-discuss] [PATCH v11 01/11] bluetooth: Fix A2DP codec API to provide information about data buffer

[Tanu Kaskinen]

On Mon, 2019-06-17 at 12:05 +0200, Pali Rohár wrote:
> On Saturday 15 June 2019 11:50:10 Tanu Kaskinen wrote:
> > Although I made that mistake, I think I'm right in saying that our
> > reading logic is broken at least with SBC. The sender can change the
> > frame size without warning, so we shouldn't base our read (encoded)
> > buffer size on that. If our buffer size is less than MTU (which it
> > currently can be), the frame size may change in such a way that future
> > packets are larger than our allocated read buffer. That will lead to
> > reading partial packets.
> > 
> > This is what I think would be correct:
> > 
> > 1) Use the read MTU as the encoded data buffer size.
> > 
> > 2) After calling pa_read(), inspect the RTP header to find out the RTP
> > packet payload size. If it's larger than what can fit our read buffer,
> > that's an error, because the packets shouldn't exceed the MTU.
> > 
> > 3) Decode only the payload part, not the whole buffer.
> > 
> > 4) It's unfortunately possible (or so I think until proven otherwise)
> > that there were two RTP packets queued in the socket, and the first one
> > didn't fill the MTU completely, so we have the beginning of the second
> > packet in our read buffer. If this is the case, we have to save the
> > leftover part somewhere. That somewhere can be the beginning of the
> > read buffer. The next time we read from the socket, we read using an
> > offset so that the new data goes after the earlier leftover data.
> > 
> > 5) When the streaming stops, the leftover offset needs to be reset, so
> > that it doesn't cause trouble when restarting streaming later.
> 
> I'm not sure if all this can happen. A2DP socket created by bluez, which
> is passed to pulseaudio via dbus, is of type SOCK_SEQPACKET.
> 
> man 2 socket describes it as:
> 
>   SOCK_SEQPACKET  Provides a sequenced, reliable, two-way connection-
>   based data transmission path for datagrams of fixed
>   maximum length; a consumer is required to read an
>   entire packet with each input system call.
> 
>   SOCK_SEQPACKET sockets employ the same system calls as
>   SOCK_STREAM sockets.  The only difference is that read(2) calls will
>   return only the amount of data requested, and any data remaining in
>   the arriving packet will be discarded.  Also all message boundaries
>   in incoming datagrams are preserved.

Ok, that's great! There won't be any leftover data that we need to be
concerned about. And if we call msgrcv() with 100 byte buffer and the
frame is 70 bytes, we will get only 70 bytes. We just need to make sure
that the read buffer is always big enough (equal to MTU should
suffice).

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

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

Re: [pulseaudio-discuss] [PATCH] bluetooth: Fix crash in setup_stream()

[Tanu Kaskinen]

On Mon, 2019-06-17 at 11:49 +0200, Frédéric Danis wrote:
> setup_stream() crashes when calling set_nonblock() with an invalid
> stream_fd.
> 
> This crash is due to a race condition.
> The audio call starts normally, and a 1st call to setup_stream() is
> completed properly.
> But, if the call is "quickly" hung up, the stream_fd is in error (POLLHUP)
> before other modules (loopback, …) have completed their initialization.
> This error triggers a call to teardown_stream() which set stream_fd to -1.
> After that, the other modules continue their initialization before the IO
> thread is stopped, triggering a 2nd call to setup_stream().

I think this description is a bit inaccurate or unclear. Based on the
log you showed in irc, it seems that this is what happens:

The ofono backend gets notified of a new connection. The ofono backend
sets the transport state to playing, and that triggers a profile
change, which sets up the stream for the first time. Then module-
bluetooth-policy sets up the loopbacks. The loopbacks get fully
initialized before the crash.

After module-bluetooth-policy has done its things, the execution
continues in the transport state change hook. The next hook user is
module-bluez5-device, whose handle_transport_state_change() function
gets called. It will then set up the stream again even though it's
already set up. I'm not sure if that's a some kind of a bug.
setup_stream() can handle the case where it's unnecessarily called,
though, so this second setup is not a big problem.

The crash happens, because the connection died due to POLLHUP in the IO
thread before the second setup_stream() call.

The fix is probably good, but the commit message and the comments need
some changes.

> ---
>  src/modules/bluetooth/module-bluez5-device.c | 18 --
>  1 file changed, 16 insertions(+), 2 deletions(-)
> 
> diff --git a/src/modules/bluetooth/module-bluez5-device.c 
> b/src/modules/bluetooth/module-bluez5-device.c
> index 56c96054d..d0e3c7a09 100644
> --- a/src/modules/bluetooth/module-bluez5-device.c
> +++ b/src/modules/bluetooth/module-bluez5-device.c
> @@ -753,6 +753,8 @@ static void setup_stream(struct userdata *u) {
>  struct pollfd *pollfd;
>  int one;
>  
> +pa_assert(u->stream_fd >= 0);
> +
>  /* return if stream is already set up */
>  if (u->stream_setup_done)
>  return;
> @@ -829,7 +831,13 @@ static int source_process_msg(pa_msgobject *o, int code, 
> void *data, int64_t off
>  }
>  
>  case PA_SOURCE_MESSAGE_SETUP_STREAM:
> -setup_stream(u);
> +/* Skip stream setup if stream_fd as been invalidated, this can
> + * occurs in case of POLLHUP before other modules have finished
> + * their initialization */

The initialization of other modules is not relevant (except maybe due
to the delay that causes which makes the race condition trigger more
easily). I think this would be a better comment:

/* Skip stream setup if stream_fd has been invalidated.
   This can occur if the stream has already been set up and
   then immediately received POLLHUP. If the stream has
   already been set up earlier, then this setup_stream()
   call is redundant anyway, but currently the code
   is such that this kind of unnecessary setup_stream()
   calls can happen. */

> +if (u->stream_fd < 0)
> +pa_log_debug("Skip source stream setup while closing");
> +else
> +setup_stream(u);
>  return 0;
>  
>  }
> @@ -1007,7 +1015,13 @@ static int sink_process_msg(pa_msgobject *o, int code, 
> void *data, int64_t offse
>  }
>  
>  case PA_SINK_MESSAGE_SETUP_STREAM:
> -setup_stream(u);
> +/* Skip stream setup if stream_fd as been invalidated, this can
> + * occurs in case of POLLHUP before other modules have finished
> + * their initialization */
> +if (u->stream_fd < 0)
> +pa_log_debug("Skip sink stream setup while closing");
> +else
> +setup_stream(u);
>  return 0;
>  }
>  
-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

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

Re: [pulseaudio-discuss] [PATCH v11 03/11] bluetooth: Implement reading SO_TIMESTAMP for A2DP source

[Tanu Kaskinen]

On Sun, 2019-06-02 at 17:25 +0200, Pali Rohár wrote:
> ---
>  src/modules/bluetooth/module-bluez5-device.c | 31 
> ++--
>  1 file changed, 29 insertions(+), 2 deletions(-)
> 
> diff --git a/src/modules/bluetooth/module-bluez5-device.c 
> b/src/modules/bluetooth/module-bluez5-device.c
> index c0b293d94..e79d472bc 100644
> --- a/src/modules/bluetooth/module-bluez5-device.c
> +++ b/src/modules/bluetooth/module-bluez5-device.c
> @@ -536,6 +536,10 @@ static int a2dp_process_push(struct userdata *u) {
>  memchunk.index = memchunk.length = 0;
>  
>  for (;;) {
> +uint8_t aux[1024];
> +struct iovec iov;
> +struct cmsghdr *cm;
> +struct msghdr m;
>  bool found_tstamp = false;
>  pa_usec_t tstamp;
>  uint8_t *ptr;
> @@ -544,7 +548,19 @@ static int a2dp_process_push(struct userdata *u) {
>  
>  a2dp_prepare_decoder_buffer(u);
>  
> -l = pa_read(u->stream_fd, u->decoder_buffer, 
> u->read_encoded_block_size, >stream_write_type);
> +pa_zero(m);
> +pa_zero(aux);
> +pa_zero(iov);
> +
> +m.msg_iov = 
> +m.msg_iovlen = 1;
> +m.msg_control = aux;
> +m.msg_controllen = sizeof(aux);
> +
> +iov.iov_base = u->decoder_buffer;
> +iov.iov_len = u->read_encoded_block_size;
> +
> +l = recvmsg(u->stream_fd, , 0);
>  
>  if (l <= 0) {
>  
> @@ -564,8 +580,19 @@ static int a2dp_process_push(struct userdata *u) {
>  pa_assert((size_t) l <= u->decoder_buffer_size);
>  
>  /* TODO: get timestamp from rtp */
> +
> +for (cm = CMSG_FIRSTHDR(); cm; cm = CMSG_NXTHDR(, cm)) {
> +if (cm->cmsg_level == SOL_SOCKET && cm->cmsg_type == 
> SO_TIMESTAMP) {
> +struct timeval *tv = (struct timeval*) CMSG_DATA(cm);
> +pa_rtclock_from_wallclock(tv);
> +tstamp = pa_timeval_load(tv);
> +found_tstamp = true;
> +break;
> +}
> +}
> +
>  if (!found_tstamp) {
> -/* pa_log_warn("Couldn't find SO_TIMESTAMP data in auxiliary 
> recvmsg() data!"); */
> +pa_log_warn("Couldn't find SO_TIMESTAMP data in auxiliary 
> recvmsg() data!");

If SO_TIMESTAMP isn't set on one message, it's probably not set on any
message. Flooding the log isn't good, so this needs some rework. Maybe
PA_ONCE_BEGIN/END would be appropriate here?

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

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

Re: [pulseaudio-discuss] [PATCH v11 02/11] bluetooth: Fix usage of RTP structures in SBC codec

[Tanu Kaskinen]

On Sun, 2019-06-02 at 17:25 +0200, Pali Rohár wrote:
> Rename struct rtp_payload to rtp_sbc_payload as it is specific for SBC
> codec. Add proper checks for endianity in rtp.h header and use uint8_t type
> where appropriated. And because rtp_sbc_payload structure is not parsed by
> decoder there is no support for fragmented SBC frames. Add warning for it.
> ---
>  src/modules/bluetooth/a2dp-codec-sbc.c | 16 ++
>  src/modules/bluetooth/rtp.h| 58 
> +++---
>  2 files changed, 42 insertions(+), 32 deletions(-)
> 
> diff --git a/src/modules/bluetooth/a2dp-codec-sbc.c 
> b/src/modules/bluetooth/a2dp-codec-sbc.c
> index f339b570d..6ab0b46cd 100644
> --- a/src/modules/bluetooth/a2dp-codec-sbc.c
> +++ b/src/modules/bluetooth/a2dp-codec-sbc.c
> @@ -480,7 +480,7 @@ static void reset(void *codec_info) {
>  
>  static void get_buffer_size(void *codec_info, size_t link_mtu, size_t 
> *decoded_buffer_size, size_t *encoded_buffer_size) {
>  struct sbc_info *sbc_info = (struct sbc_info *) codec_info;
> -size_t rtp_size = sizeof(struct rtp_header) + sizeof(struct rtp_payload);
> +size_t rtp_size = sizeof(struct rtp_header) + sizeof(struct 
> rtp_sbc_payload);
>  size_t num_of_frames = (link_mtu - rtp_size) / sbc_info->frame_length;
>  
>  *decoded_buffer_size = num_of_frames * sbc_info->codesize;
> @@ -510,14 +510,14 @@ static int reduce_encoder_bitrate(void *codec_info) {
>  static size_t encode_buffer(void *codec_info, uint32_t timestamp, const 
> uint8_t *input_buffer, size_t input_size, uint8_t *output_buffer, size_t 
> output_size, size_t *processed) {
>  struct sbc_info *sbc_info = (struct sbc_info *) codec_info;
>  struct rtp_header *header;
> -struct rtp_payload *payload;
> +struct rtp_sbc_payload *payload;
>  uint8_t *d;
>  const uint8_t *p;
>  size_t to_write, to_encode;
>  unsigned frame_count;
>  
>  header = (struct rtp_header*) output_buffer;
> -payload = (struct rtp_payload*) (output_buffer + sizeof(*header));
> +payload = (struct rtp_sbc_payload*) (output_buffer + sizeof(*header));
>  
>  frame_count = 0;
>  
> @@ -562,7 +562,7 @@ static size_t encode_buffer(void *codec_info, uint32_t 
> timestamp, const uint8_t
>  } PA_ONCE_END;
>  
>  /* write it to the fifo */
> -memset(output_buffer, 0, sizeof(*header) + sizeof(*payload));
> +pa_memzero(output_buffer, sizeof(*header) + sizeof(*payload));
>  header->v = 2;
>  
>  /* A2DP spec: "A payload type in the RTP dynamic range shall be chosen".
> @@ -583,13 +583,17 @@ static size_t decode_buffer(void *codec_info, const 
> uint8_t *input_buffer, size_
>  struct sbc_info *sbc_info = (struct sbc_info *) codec_info;
>  
>  struct rtp_header *header;
> -struct rtp_payload *payload;
> +struct rtp_sbc_payload *payload;
>  const uint8_t *p;
>  uint8_t *d;
>  size_t to_write, to_decode;
>  
>  header = (struct rtp_header *) input_buffer;
> -payload = (struct rtp_payload*) (input_buffer + sizeof(*header));
> +payload = (struct rtp_sbc_payload*) (input_buffer + sizeof(*header));
> +
> +/* TODO: Add support for decoding fragmented SBC frames */
> +if (payload->is_fragmented)
> +pa_log_warn("SBC frame is fragmented, decoding may fail");

If we don't currently support fragmented frames, I think it would be
better to just flat out fail here. I imagine we'll hit a fatal error
soon anyway, but if by some miracle PulseAudio managed to decode the
stream anyway (maybe the frames aren't fragmented after all), the
syslog would potentially get flooded with these warnings.

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

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

Re: [pulseaudio-discuss] Resampler rewinding

[Tanu Kaskinen]

On Sat, 2019-06-15 at 11:31 +0200, Georg Chini wrote:
> On 15.06.19 10:01, Tanu Kaskinen wrote:
> > On Tue, 2019-06-11 at 22:08 +0200, Georg Chini wrote:
> > > Hi Tanu,
> > > 
> > > the first diagram should look like this:
> > > 
> > > DIAGRAM FOR HARDWARE SINK 1 BEFORE STARTING THE MOVE
> > > 
> > > +-+-
> > > >client stream memblockq  
> > > >  |
> > > +-+-
> > >   
> > >   ^ read index
> > > 
> > > +++-
> > > >   client history_queue  |queue 
> > > > length|
> > > +++-
> > >^ read 
> > > index ^write index
> > >   
> > >   
> > >
> > >  
> > > +--+
> > >  | data in the client 
> > > resampler |
> > >  
> > > +--+
> > > 
> > > +--+
> > > >   client render_memblockq  | queue length |
> > > +--+
> > >   ^ read index   ^ write index
> > > 
> > > +
> > >  |  dma buffer|
> > > +
> > >  ^ hardware playback position,
> > >can't rewind beyond this point
> > > 
> > > This is why I do not need to take the render memblockq length into 
> > > account when
> > > rewinding the history queue. (When rewinding during a volume change, the 
> > > history
> > > queue is also rewound by the same amount as the render memblockq plus the 
> > > data in
> > > the resampler. Then the resampler bit is fed back into the resampler.)
> > > 
> > > The third diagram is correct again, before finishing the move, the read 
> > > pointers are
> > > out of sync and will be re-synchronized when pa_sink_input_drop() is 
> > > called the next
> > > time during FINISH_MOVE.
> > I don't see why history_queue length should be in sync with the
> > render_memblockq length. I find your scheme harder to understand,
> > because the usual rule of the write position of a downstream buffer
> > matching the read position of the next buffer upstream doesn't hold. In
> > your scheme the read index of history_queue doesn't point to the
> > location from which the resampler reads data. Could you change this bit
> > in your code?
> > 
> I do not read from the history queue during normal operation, the input
> data for the resampler comes from the client. I just push the data that
> the client provides into the history.

Ok, so the history_queue isn't part of the audio flow, it's just a
separate buffer with its own special rules.

To make it part of the audio flow, you could read a chunk from the
client, push it to the history_queue, then immediately read the chunk
back from the history_queue and push it to the resampler.

> It is much simpler to keep the indices in sync than to have to care about
> the read index difference between the render memblockq and the history
> queue.

What is there to care about? The read index difference is the
render_memblockq length plus the resampler delay. Those will keep up to
date by themselves, no manual intervention needed.

> This basically means that I can do the same operations on the history
> queue that I do on the render memblockq.
> The history queue is only read in two situations:
> 
> 1) During a volume change. In this case I can now simply rewind the history
> queue by the same amount that I rewind the render memblockq plus the bit
> that I have to feed into the resampler.

Otherwise you'd simply rewind the history queue by the new
render_memblockq length (after rewinding it first) plus the resampler
delay. Doesn't seem any more complicated to me.

&

Re: [pulseaudio-discuss] [PATCH v11 01/11] bluetooth: Fix A2DP codec API to provide information about data buffer

[Tanu Kaskinen]

On Sat, 2019-06-15 at 11:05 +0200, Pali Rohár wrote:
> On Saturday 15 June 2019 11:50:10 Tanu Kaskinen wrote:
> > On Sun, 2019-06-02 at 17:25 +0200, Pali Rohár wrote:
> > > Each codec has different compression ratio and own method how to calculate
> > > buffer size of encoded or decoded samples. So change A2DP codec API to
> > > provide this information for module-bluez5-device module and fix
> > > a2dp_prepare_encoder_buffer() and a2dp_prepare_decoder_buffer() functions.
> > > 
> > > API functions get_read_buffer_size() and get_write_buffer_size() now set
> > > both decoded and encoded buffer sizes. Function reduce_encoder_bitrate()
> > > was changed to not return new buffer size (it was not obvious if buffer
> > > size was for encoded or decoded samples), but caller rather should call
> > > get_write_buffer_size() to get new sizes.
> > > ---
> > >  src/modules/bluetooth/a2dp-codec-api.h   | 17 ++--
> > >  src/modules/bluetooth/a2dp-codec-sbc.c   | 25 ++---
> > >  src/modules/bluetooth/module-bluez5-device.c | 41 
> > > ++--
> > >  3 files changed, 50 insertions(+), 33 deletions(-)
> > > 
> > > diff --git a/src/modules/bluetooth/a2dp-codec-api.h 
> > > b/src/modules/bluetooth/a2dp-codec-api.h
> > > index 55bb9ff70..517dc76f1 100644
> > > --- a/src/modules/bluetooth/a2dp-codec-api.h
> > > +++ b/src/modules/bluetooth/a2dp-codec-api.h
> > > @@ -72,15 +72,14 @@ typedef struct pa_a2dp_codec {
> > >  /* Reset internal state of codec info data in codec_info */
> > >  void (*reset)(void *codec_info);
> > >  
> > > -/* Get read block size for codec */
> > > -size_t (*get_read_block_size)(void *codec_info, size_t 
> > > read_link_mtu);
> > > -/* Get write block size for codec */
> > > -size_t (*get_write_block_size)(void *codec_info, size_t 
> > > write_link_mtu);
> > > -
> > > -/* Reduce encoder bitrate for codec, returns new write block size or 
> > > zero
> > > - * if not changed, called when socket is not accepting encoded data 
> > > fast
> > > - * enough */
> > > -size_t (*reduce_encoder_bitrate)(void *codec_info, size_t 
> > > write_link_mtu);
> > > +/* Get buffer sizes for read operations */
> > > +void (*get_read_buffer_size)(void *codec_info, size_t read_link_mtu, 
> > > size_t *output_buffer_size, size_t *encoded_buffer_size);
> > > +/* Get buffer sizes for write operations */
> > > +void (*get_write_buffer_size)(void *codec_info, size_t 
> > > write_link_mtu, size_t *input_buffer_size, size_t *encoded_buffer_size);
> > 
> > Since these return two sizes, I think "size" in the callback name
> > should be changed to "sizes".
> 
> Ok, fine!
> 
> > In my opinion decoded_buffer_size would be a better name than
> > output/input_buffer_size.
> 
> I was thinking about it for a longer time. Main problem is that reader
> should know which size is for input buffer size and which for output
> buffer size. More times I had a mistake that I switched input and
> output, because from name "encoded" and "decoded" it is not know which
> one is input and which output.

I would have imagined that the "get_read_buffer_size" callback name is
enough to make it clear which is which, but if you have experience of
getting them mixed up anyway, then it no doubt is a real problem.

> When encoding, input is decoded buffer; when decoding, input is encoded
> buffer.
> 
> And you can see that it is not possible to have consistency in functions
> get_read_buffer_sizes and get_write_buffer_sizes. Either third argument
> would be input buffer size; or it would be decoded buffer size.

I don't follow the argument in this paragraph. What consistency problem
is there?

> So I decided to have both information in function parameters, to know
> which one is input/output and also which one is encoded/decoded.
> 
> 
> Another suggestion how to solve this problem to know which buffer is
> input and which output:
> 
> Use names: decoded_output_buffer_size, encoded_input_buffer_size
> 
> It is just longer name, but contains both information.

I think these longer names are good too.

> > > +
> > > +/* Reduce encoder bitrate for codec, returns non-zero on failure,
> > > + * called when socket is not accepting encoded data fast enough */
> > > +int (*reduce_encoder_bitrate)(void *codec_info);
> > >  
> > 

Re: [pulseaudio-discuss] [PATCH v11 01/11] bluetooth: Fix A2DP codec API to provide information about data buffer

[Tanu Kaskinen]

On Sun, 2019-06-02 at 17:25 +0200, Pali Rohár wrote:
> Each codec has different compression ratio and own method how to calculate
> buffer size of encoded or decoded samples. So change A2DP codec API to
> provide this information for module-bluez5-device module and fix
> a2dp_prepare_encoder_buffer() and a2dp_prepare_decoder_buffer() functions.
> 
> API functions get_read_buffer_size() and get_write_buffer_size() now set
> both decoded and encoded buffer sizes. Function reduce_encoder_bitrate()
> was changed to not return new buffer size (it was not obvious if buffer
> size was for encoded or decoded samples), but caller rather should call
> get_write_buffer_size() to get new sizes.
> ---
>  src/modules/bluetooth/a2dp-codec-api.h   | 17 ++--
>  src/modules/bluetooth/a2dp-codec-sbc.c   | 25 ++---
>  src/modules/bluetooth/module-bluez5-device.c | 41 
> ++--
>  3 files changed, 50 insertions(+), 33 deletions(-)
> 
> diff --git a/src/modules/bluetooth/a2dp-codec-api.h 
> b/src/modules/bluetooth/a2dp-codec-api.h
> index 55bb9ff70..517dc76f1 100644
> --- a/src/modules/bluetooth/a2dp-codec-api.h
> +++ b/src/modules/bluetooth/a2dp-codec-api.h
> @@ -72,15 +72,14 @@ typedef struct pa_a2dp_codec {
>  /* Reset internal state of codec info data in codec_info */
>  void (*reset)(void *codec_info);
>  
> -/* Get read block size for codec */
> -size_t (*get_read_block_size)(void *codec_info, size_t read_link_mtu);
> -/* Get write block size for codec */
> -size_t (*get_write_block_size)(void *codec_info, size_t write_link_mtu);
> -
> -/* Reduce encoder bitrate for codec, returns new write block size or zero
> - * if not changed, called when socket is not accepting encoded data fast
> - * enough */
> -size_t (*reduce_encoder_bitrate)(void *codec_info, size_t 
> write_link_mtu);
> +/* Get buffer sizes for read operations */
> +void (*get_read_buffer_size)(void *codec_info, size_t read_link_mtu, 
> size_t *output_buffer_size, size_t *encoded_buffer_size);
> +/* Get buffer sizes for write operations */
> +void (*get_write_buffer_size)(void *codec_info, size_t write_link_mtu, 
> size_t *input_buffer_size, size_t *encoded_buffer_size);

Since these return two sizes, I think "size" in the callback name
should be changed to "sizes".

In my opinion decoded_buffer_size would be a better name than
output/input_buffer_size.

> +
> +/* Reduce encoder bitrate for codec, returns non-zero on failure,
> + * called when socket is not accepting encoded data fast enough */
> +int (*reduce_encoder_bitrate)(void *codec_info);
>  
>  /* Encode input_buffer of input_size to output_buffer of output_size,
>   * returns size of filled ouput_buffer and set processed to size of
> diff --git a/src/modules/bluetooth/a2dp-codec-sbc.c 
> b/src/modules/bluetooth/a2dp-codec-sbc.c
> index cdc20d7f0..f339b570d 100644
> --- a/src/modules/bluetooth/a2dp-codec-sbc.c
> +++ b/src/modules/bluetooth/a2dp-codec-sbc.c
> @@ -423,7 +423,10 @@ static void *init(bool for_encoding, bool 
> for_backchannel, const uint8_t *config
>  sbc_info->min_bitpool = config->min_bitpool;
>  sbc_info->max_bitpool = config->max_bitpool;
>  
> -/* Set minimum bitpool for source to get the maximum possible block_size 
> */
> +/* Set minimum bitpool for source to get the maximum possible buffer size
> + * in get_buffer_size() function. Buffer size is inversely proportional 
> to
> + * frame length which depends on bitpool value. Bitpool is controlled by
> + * other side from range [min_bitpool, max_bitpool]. */
>  sbc_info->initial_bitpool = for_encoding ? sbc_info->max_bitpool : 
> sbc_info->min_bitpool;

Please specify that you're talking about the decoded buffer size. I
(for some reason) assumed that you meant the encoded buffer size, and
started writing a complaint about "buffer size is inversely
proportional to frame length" being wrong...

Although I made that mistake, I think I'm right in saying that our
reading logic is broken at least with SBC. The sender can change the
frame size without warning, so we shouldn't base our read (encoded)
buffer size on that. If our buffer size is less than MTU (which it
currently can be), the frame size may change in such a way that future
packets are larger than our allocated read buffer. That will lead to
reading partial packets.

This is what I think would be correct:

1) Use the read MTU as the encoded data buffer size.

2) After calling pa_read(), inspect the RTP header to find out the RTP
packet payload size. If it's larger than what can fit our read buffer,
that's an error, because the packets shouldn't exceed the MTU.

3) Decode only the payload part, not the whole buffer.

4) It's unfortunately possible (or so I think until proven otherwise)
that there were two RTP packets queued in the socket, and the first one
didn't fill the MTU completely, so we have the beginning of the second

Re: [pulseaudio-discuss] Resampler rewinding

[Tanu Kaskinen]

On Tue, 2019-06-11 at 22:08 +0200, Georg Chini wrote:
> Hi Tanu,
> 
> the first diagram should look like this:
> 
> DIAGRAM FOR HARDWARE SINK 1 BEFORE STARTING THE MOVE
> 
> +-+-
> >   client stream memblockq   
> > |
> +-+-
>   
>  ^ read index
> 
> +++-
> >  client history_queue  |queue 
> > length|
> +++-
>   ^ read index
>  ^write index
>   
>  
>   
> 
> +--+
> | data in the client 
> resampler |
> 
> +--+
> 
> +--+
> >  client render_memblockq  | queue length |
> +--+
>  ^ read index   ^ write index
> 
> +
> |  dma buffer|
> +
> ^ hardware playback position,
>   can't rewind beyond this point
> 
> This is why I do not need to take the render memblockq length into account 
> when
> rewinding the history queue. (When rewinding during a volume change, the 
> history
> queue is also rewound by the same amount as the render memblockq plus the 
> data in
> the resampler. Then the resampler bit is fed back into the resampler.)
> 
> The third diagram is correct again, before finishing the move, the read 
> pointers are
> out of sync and will be re-synchronized when pa_sink_input_drop() is called 
> the next
> time during FINISH_MOVE.

I don't see why history_queue length should be in sync with the
render_memblockq length. I find your scheme harder to understand,
because the usual rule of the write position of a downstream buffer
matching the read position of the next buffer upstream doesn't hold. In
your scheme the read index of history_queue doesn't point to the
location from which the resampler reads data. Could you change this bit
in your code?

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

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

Re: [pulseaudio-discuss] where can I see stderr output of LADSPA plugin ?

[Tanu Kaskinen]

On Mon, 2019-06-10 at 02:11 +0300, Sergei Steshenko wrote:
> Hello All,
> 
> I have a developed by myself LADSPA plugin which works and which I 
> managed to use with pulseaudio.
> 
> As the plugin operates it prints some messages to stderr, and I do see 
> them when I use the plugin with, say, ecasound or mplayer.
> 
> However, if I invoke pulseaudio as
> 
> (export LADSPA_PATH=/mnt/althome/sergei/acoustics_work_sp/ladspa; 
> pulseaudio -v --start --log-level=4 --log-target=stderr)

Don't use --start, because it will launch pulseaudio in background, and
the stderr output won't go anywhere.

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

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

Re: [pulseaudio-discuss] [RFC 0/2] Add dynamic configuration of SBC bitpool

[Tanu Kaskinen]

On Sun, 2019-06-09 at 21:41 +0200, Pali Rohár wrote:
> On Sunday 09 June 2019 08:51:38 Tanu Kaskinen wrote:
> > On Mon, 2019-06-03 at 16:01 +0200, Pali Rohár wrote:
> > > Hi!
> > > 
> > > On Thursday 23 May 2019 16:12:18 Frédéric Danis wrote:
> > > > Hi Pali,
> > > > 
> > > > On 17/05/2019 16:38, Pali Rohár wrote:
> > > > > On Friday 17 May 2019 16:26:30 Frédéric Danis wrote:
> > > > > > Hi Pali,
> > > > > > 
> > > > > > On 17/05/2019 15:51, Pali Rohár wrote:
> > > > > > > On Friday 17 May 2019 15:45:10 Frédéric Danis wrote:
> > > > > > > > This series of patch allows to manage the bandwidth used by an 
> > > > > > > > A2DP source
> > > > > > > > using SBC encoder by adding ability to change the bitpool 
> > > > > > > > dynamically during
> > > > > > > > runtime.
> > > > > > > > In a crowded environment this can allow to limit interference 
> > > > > > > > between source
> > > > > > > > and headphones.
> > > > > > > > 
> > > > > > > > This needs "Message API v2" patches from Georg Chini [1]
> > > > > > > > 
> > > > > > > > I am currently not sure in patch 2 where should occur the SBC 
> > > > > > > > bitpool apply.
> > > > > > > > 
> > > > > > > > Any comments appreciated.
> > > > > > > > 
> > > > > > > > [1] 
> > > > > > > > https://gitlab.freedesktop.org/pulseaudio/pulseaudio/merge_requests/51
> > > > > > > Hi! I would suggest to wait until my patches for extending A2DP 
> > > > > > > codecs
> > > > > > > is reviewed and merged. You can find them in email with subject
> > > > > > > "[PATCH v10 00/11] Bluetooth A2DP codecs"
> > > > > > Tanu Kaskinen has already pointed them to me and I have a version 
> > > > > > using
> > > > > > them.
> > > > > > I've sent this RFC with minimal dependency on waiting patches to 
> > > > > > start
> > > > > > getting some feedback about it.
> > > > > Ok.
> > > > > 
> > > > > > With your patches, I have to use the "SBC (Automatic Quality)" 
> > > > > > profile to be
> > > > > > able to change the SBC bitpool.
> > > > > Ok.
> > > > > 
> > > > > > Do you know if there is a way to set it as preferred profile for new
> > > > > > connections?
> > > > > So.. I do not think that "SBC (Automatic Quality)" should be used as
> > > > > default/preferred profile.
> > > > > 
> > > > > Lot of people are complaining about bad quality of the bluetooth a2dp
> > > > > implementation in linux... And the solution is to use SBC UHQ mode if 
> > > > > is
> > > > > available -- so to stop using SBC High Quality (and automatic 
> > > > > quality).
> > > > > In most cases SBC UHQ is possible to use only via DualChannel mode as
> > > > > the highest possible bitpool value for JointStereo mode in most cases 
> > > > > is
> > > > > not enough for UHQ.
> > > > 
> > > > I understand your point of view, but my tests with SBC UHQ mode in an
> > > > environment with interferences may increase sound quality but with audio
> > > > dropouts. Which is not really better.
> > > 
> > > Generally there are 3 problems:
> > > 
> > > 1) Some codecs have fixed parameters, no way for "low quality".
> > > 
> > > 2) What should be the default codec?
> > > 
> > > 3) What should happen when current codec is "unusable" in current
> > >environment?
> > > 
> > > Main objection against usage of SBC is that you do not know what
> > > configuration and parameters are in use. So people rather want to have
> > > aptX which has only one quality, no dynamic change.
> > > 
> > > This is also reason for introducing SBC profiles, to have ability to
> > > compare codec quality.
> > > 
> > > One of the solution is: For each device remember last used codec/profile
> &g

Re: [pulseaudio-discuss] [PATCH] stream-restore: Don't restore if the active_port is PA_AVAILABLE_NO

[Tanu Kaskinen]

On Wed, 2019-05-15 at 14:39 +0800, Hui Wang wrote:
> We met two problems recently, one happened on a Lenovo machine with
> dual analogue codecs, the other happened on a Dell machine with
> a digital mic directly connected to PCH. The two problems are
> basically same, there is an internal mic and an external mic, the
> internal mic always shows up in the gnome-control-center, the external
> mic only shows up when it is plugged. After the external mic is
> plugged and users select it from gnome-control-center, the
> gnome-control-center will read all saved streams through extension_cb,
> and bind the source of external mic to all streams, after that the
> apps only record sound via the source of external mic, after the
> external mic is unplugged, the internal mic will automatically be
> selected since it is the only left input device in the
> gnome-control-center, since users don't select it, all streams are
> still bond the source of external mic. When users record sound via
> apps, they can't record any sound even the default_source is the
> source of internal mic and the internal mic is selected in the UI.
> 
> It is very common that a machine has internal mic and external mic,
> but this problem didn't expose before, that is because both internal
> mic and external mic belong to one source, but for those two
> machines, the internal mic belongs to one source, while the external
> mic belongs to another source (they are in differnt codecs or one is
> in the codec and the other is from PCH),
> 
> To fix it with a mininal change, we just check if the active_port is
> PA_AVAILABLE_NO or not when building a new stream, if it is, don't
> restore the device to the new built stream, let pa_source_output_new()
> decide the source device for this stream.
> 
> And we also do the same change to sink_input.
> 
> This change only affects the new built streams, it will not change
> the database, so the users' preference is still saved in the database,
> after the active_port is not PA_AVAILABLE_NO, the new streams will
> still restore to the preferred device.
> 
> Signed-off-by: Hui Wang 
> ---
>  src/modules/module-stream-restore.c | 12 
>  1 file changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/src/modules/module-stream-restore.c 
> b/src/modules/module-stream-restore.c
> index 6c7b4c75b..cbef4782d 100644
> --- a/src/modules/module-stream-restore.c
> +++ b/src/modules/module-stream-restore.c
> @@ -1459,8 +1459,10 @@ static pa_hook_result_t 
> sink_input_new_hook_callback(pa_core *c, pa_sink_input_n
> same time, in which case we want to make sure we don't
> interfere with that */
>  if (s && PA_SINK_IS_LINKED(s->state))
> -if (pa_sink_input_new_data_set_sink(new_data, s, true, false))
> -pa_log_info("Restoring device for stream %s.", name);
> +if (!s->active_port || s->active_port->available != 
> PA_AVAILABLE_NO) {
> +if (pa_sink_input_new_data_set_sink(new_data, s, true, 
> false))
> +pa_log_info("Restoring device for stream %s.", name);
> + }
>  
>  entry_free(e);
>  }
> @@ -1562,8 +1564,10 @@ static pa_hook_result_t 
> source_output_new_hook_callback(pa_core *c, pa_source_ou
> same time, in which case we want to make sure we don't
> interfere with that */
>  if (s && PA_SOURCE_IS_LINKED(s->state)) {
> -pa_log_info("Restoring device for stream %s.", name);
> -pa_source_output_new_data_set_source(new_data, s, true, false);
> +if (!s->active_port || s->active_port->available != 
> PA_AVAILABLE_NO) {
> +pa_log_info("Restoring device for stream %s.", name);
> +pa_source_output_new_data_set_source(new_data, s, true, 
> false);
> + }
>  }
>  
>  entry_free(e);

Thanks! Applied.

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

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

Re: [pulseaudio-discuss] [RFC 0/2] Add dynamic configuration of SBC bitpool

[Tanu Kaskinen]

On Mon, 2019-06-03 at 16:01 +0200, Pali Rohár wrote:
> Hi!
> 
> On Thursday 23 May 2019 16:12:18 Frédéric Danis wrote:
> > Hi Pali,
> > 
> > On 17/05/2019 16:38, Pali Rohár wrote:
> > > On Friday 17 May 2019 16:26:30 Frédéric Danis wrote:
> > > > Hi Pali,
> > > > 
> > > > On 17/05/2019 15:51, Pali Rohár wrote:
> > > > > On Friday 17 May 2019 15:45:10 Frédéric Danis wrote:
> > > > > > This series of patch allows to manage the bandwidth used by an A2DP 
> > > > > > source
> > > > > > using SBC encoder by adding ability to change the bitpool 
> > > > > > dynamically during
> > > > > > runtime.
> > > > > > In a crowded environment this can allow to limit interference 
> > > > > > between source
> > > > > > and headphones.
> > > > > > 
> > > > > > This needs "Message API v2" patches from Georg Chini [1]
> > > > > > 
> > > > > > I am currently not sure in patch 2 where should occur the SBC 
> > > > > > bitpool apply.
> > > > > > 
> > > > > > Any comments appreciated.
> > > > > > 
> > > > > > [1] 
> > > > > > https://gitlab.freedesktop.org/pulseaudio/pulseaudio/merge_requests/51
> > > > > Hi! I would suggest to wait until my patches for extending A2DP codecs
> > > > > is reviewed and merged. You can find them in email with subject
> > > > > "[PATCH v10 00/11] Bluetooth A2DP codecs"
> > > > Tanu Kaskinen has already pointed them to me and I have a version using
> > > > them.
> > > > I've sent this RFC with minimal dependency on waiting patches to start
> > > > getting some feedback about it.
> > > Ok.
> > > 
> > > > With your patches, I have to use the "SBC (Automatic Quality)" profile 
> > > > to be
> > > > able to change the SBC bitpool.
> > > Ok.
> > > 
> > > > Do you know if there is a way to set it as preferred profile for new
> > > > connections?
> > > So.. I do not think that "SBC (Automatic Quality)" should be used as
> > > default/preferred profile.
> > > 
> > > Lot of people are complaining about bad quality of the bluetooth a2dp
> > > implementation in linux... And the solution is to use SBC UHQ mode if is
> > > available -- so to stop using SBC High Quality (and automatic quality).
> > > In most cases SBC UHQ is possible to use only via DualChannel mode as
> > > the highest possible bitpool value for JointStereo mode in most cases is
> > > not enough for UHQ.
> > 
> > I understand your point of view, but my tests with SBC UHQ mode in an
> > environment with interferences may increase sound quality but with audio
> > dropouts. Which is not really better.
> 
> Generally there are 3 problems:
> 
> 1) Some codecs have fixed parameters, no way for "low quality".
> 
> 2) What should be the default codec?
> 
> 3) What should happen when current codec is "unusable" in current
>environment?
> 
> Main objection against usage of SBC is that you do not know what
> configuration and parameters are in use. So people rather want to have
> aptX which has only one quality, no dynamic change.
> 
> This is also reason for introducing SBC profiles, to have ability to
> compare codec quality.
> 
> One of the solution is: For each device remember last used codec/profile
> and use it as default. If there is no remembered codec/profile (e.g.
> because it is first time connection) then choose the codec/profile with
> highest possible quality. If user is unsatisfied he should be able to
> change it.
> 
> > > > > In this patch series is also big rework of SBC codec, to support e.g.
> > > > > UHQ mode and your changes would introduce new conflicts with that 
> > > > > patch
> > > > > series.
> > > > > 
> > > > > Anyway, correct behavior of SBC codec in automatic mode should
> > > > > automatically increase or decrease SBC bitpool based on available
> > > > > bandwidth.
> > > > The idea should be to have an external application getting information
> > > This is way to the hell.
> > > 
> > > > about
> > > > the radio environment like the number of Bluetooth devices (A2DP 
> > > > sources and
> > > > sinks, a

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

[Tanu Kaskinen]

On Thu, 2019-06-06 at 18:39 +0200, Arun Raghavan wrote:
> 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).

The same argument could probably be made for quite a few pending
patches and other things (individually not that much work, but there
are many of them). Getting the message API in the next release doesn't
seem super important to me, if there's nothing using it.

If we delay the freeze by a couple of weeks as Arun suggested, I may
end up reviewing the patches before the freeze anyway, though, because
I need them in the loopback manager hobby project.

> > > Otherwise I would be fine with freezing master and preparing
> > > a new release. Do we have any blocker bugs?

I need to check my notes, but for now the only bug that I'm aware of
that I think should be a blocker is this:
https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/667

The blockers are tracked here:
https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/174

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

I'm fine with delaying the freeze by two weeks. Freeze on 2019-06-20
then (that's two weeks after your message)?

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

___
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

[Tanu Kaskinen]

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?

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

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

Re: [pulseaudio-discuss] RFC: loopback manager

[Tanu Kaskinen]

On Sun, 2019-05-26 at 20:07 -0400, Joe wrote:
> On 5/26/19 1:43 AM, Alexander E. Patrakov wrote:
> > сб, 25 мая 2019 г. в 18:38, Tanu Kaskinen :
> > > Hello,
> > > 
> > > I nowadays use module-loopback on a daily basis, and I thought it would
> > > be nice to provide a GUI (in pavucontrol) for configuring loopbacks.
> > > For this I propose we create a new module: module-loopback-manager. The
> > > purpose of that module is to provide a client interface for managing
> > > loopbacks. Without such manager interface it's not possible to create
> > > loopbacks that stay around after reboot. Well, one could add module-
> > > loopback to default.pa, but that doesn't mesh well with dynamic
> > > hardware, and that's not doable from pavucontrol anyway. The new module
> > > would maintain a database of loopbacks, so that they can be recreated
> > > after a reboot.
> > > 
> > > The client interface would contain functionality for adding and
> > > removing loopbacks, and changing the parameters of existing loopbacks.
> > > 
> > > A loopback object would have the following attributes (to be shown in
> > > "pactl list loopbacks"):
> > > 
> > > Name: The identifier for the loopback.
> > > 
> > > Description: A human-friendly description for UI labels.
> > > 
> > > Source: The source name. Can also be unset, in which case the
> > > loopback should follow the default source setting.
> > > 
> > > Sink: The sink name. Can also be unset, in which case the loopback
> > > should follow the default sink setting.
> > > 
> > > Enabled: The user can temporarily disable a loopback without
> > > removing it altogether.
> > > 
> > > Running: A boolean that is true when the loopback is running, and
> > > false when the loopback is stopped for whatever reason. The interface
> > > should also provide a human-friendly string explaining why the loopback
> > > is not running (the loopback could be disabled, the sink or source
> > > might not be present at the moment, or the sink or source might be
> > > suspended).
> > > 
> > > Requested latency: The latency that has been requested by the user.
> > > 
> > > Current latency: The current actual latency. Might be different
> > > than the requested latency, because the requested latency may be too
> > > low to work.
> > > 
> > > Persistent: A boolean indicating whether the loopback will be
> > > restored after restarting PulseAudio. My plan is that loopbacks that
> > > are created through the manager interface are always persistent, and
> > > non-persistent loopbacks are only for loopbacks that are created by
> > > loading module-loopback.
> > > 
> > > Source output index: When the loopback is running, it will have a
> > > source output associated with it.
> > > 
> > > Sink input index: When the loopback is running, it will have a sink
> > > input associated with it.
> > > 
> > > module-loopback index: When the loopback was created by loading
> > > module-loopback, this is the module index.
> > > 
> > > A maximum latency attribute could be added later, which would prevent
> > > the loopback increasing the latency too much (at the cost of drop-
> > > outs).
> > > 
> > > The pactl interface could look like this:
> > > 
> > > pactl loopback add [--description=] [--enabled=] 
> > > [--latency-msec=]   
> > > pactl loopback remove 
> > > pactl loopback set-description  
> > > pactl loopback set-source  
> > > pactl loopback set-sink  
> > > pactl loopback set-enabled  /toggle
> > > pactl loopback set-latency-msec  
> > > 
> > > Any thoughts? Would this kind of addition be welcome? If you think that
> > > it's not worth having this feature, please say so, so that I don't
> > > spend too much effort on this.
> > I think it would be a useful exercise for you as a developer, even if
> > there are very few users. At least, it is (AFAIK) the first attempt in
> > PulseAudio to create something dynamically based on a policy stored in
> > a persistent database. The experience gained through the exercise
> > would likely be useful in other cases when one needs to deal with the
> > "default.pa is too static and cannot configure hot-plugged things"
> > problem.
> > 
> > An

[pulseaudio-discuss] RFC: loopback manager

[Tanu Kaskinen]

Hello,

I nowadays use module-loopback on a daily basis, and I thought it would
be nice to provide a GUI (in pavucontrol) for configuring loopbacks.
For this I propose we create a new module: module-loopback-manager. The
purpose of that module is to provide a client interface for managing
loopbacks. Without such manager interface it's not possible to create
loopbacks that stay around after reboot. Well, one could add module-
loopback to default.pa, but that doesn't mesh well with dynamic
hardware, and that's not doable from pavucontrol anyway. The new module
would maintain a database of loopbacks, so that they can be recreated
after a reboot.

The client interface would contain functionality for adding and
removing loopbacks, and changing the parameters of existing loopbacks.

A loopback object would have the following attributes (to be shown in
"pactl list loopbacks"):

Name: The identifier for the loopback.

Description: A human-friendly description for UI labels.

Source: The source name. Can also be unset, in which case the
loopback should follow the default source setting.

Sink: The sink name. Can also be unset, in which case the loopback
should follow the default sink setting.

Enabled: The user can temporarily disable a loopback without
removing it altogether.

Running: A boolean that is true when the loopback is running, and
false when the loopback is stopped for whatever reason. The interface
should also provide a human-friendly string explaining why the loopback
is not running (the loopback could be disabled, the sink or source
might not be present at the moment, or the sink or source might be
suspended).

Requested latency: The latency that has been requested by the user.

Current latency: The current actual latency. Might be different
than the requested latency, because the requested latency may be too
low to work.

Persistent: A boolean indicating whether the loopback will be
restored after restarting PulseAudio. My plan is that loopbacks that
are created through the manager interface are always persistent, and
non-persistent loopbacks are only for loopbacks that are created by
loading module-loopback.

Source output index: When the loopback is running, it will have a
source output associated with it.

Sink input index: When the loopback is running, it will have a sink
input associated with it.

module-loopback index: When the loopback was created by loading
module-loopback, this is the module index.

A maximum latency attribute could be added later, which would prevent
the loopback increasing the latency too much (at the cost of drop-
outs).

The pactl interface could look like this:

pactl loopback add [--description=] [--enabled=] 
[--latency-msec=]   
pactl loopback remove 
pactl loopback set-description  
pactl loopback set-source  
pactl loopback set-sink  
pactl loopback set-enabled  /toggle
pactl loopback set-latency-msec  

Any thoughts? Would this kind of addition be welcome? If you think that
it's not worth having this feature, please say so, so that I don't
spend too much effort on this.

-- 
Tanu

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

Re: [pulseaudio-discuss] new module module-plugin-sink

[Tanu Kaskinen]

On Sat, 2019-05-04 at 22:41 +0200, Georg Chini wrote:
> /***
>   This file is part of PulseAudio.
> 
>   PulseAudio is free software; you can redistribute it and/or modify
>   it under the terms of the GNU Lesser General Public License as published
>   by the Free Software Foundation; either version 2.1 of the License,
>   or (at your option) any later version.
> 
>   PulseAudio is distributed in the hope that it will be useful, but
>   WITHOUT ANY WARRANTY; without even the implied warranty of
>   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
>   General Public License for more details.
> 
>   You should have received a copy of the GNU Lesser General Public License
>   along with PulseAudio; if not, see ;.
> ***/
> 
> /* Channel positions copied from pulseaudio channelmap.h */
> enum channel_position {
> CHANNEL_POSITION_INVALID = -1,
> CHANNEL_POSITION_MONO = 0,
> 
> CHANNEL_POSITION_FRONT_LEFT,   /**< Apple, Dolby call this 
> 'Left' */
> CHANNEL_POSITION_FRONT_RIGHT,  /**< Apple, Dolby call this 
> 'Right' */
> CHANNEL_POSITION_FRONT_CENTER, /**< Apple, Dolby call this 
> 'Center' */
> 
> CHANNEL_POSITION_LEFT = CHANNEL_POSITION_FRONT_LEFT,
> CHANNEL_POSITION_RIGHT = CHANNEL_POSITION_FRONT_RIGHT,
> CHANNEL_POSITION_CENTER = CHANNEL_POSITION_FRONT_CENTER,
> 
> CHANNEL_POSITION_REAR_CENTER,  /**< Microsoft calls this 
> 'Back Center', Apple calls this 'Center Surround', Dolby calls this 'Surround 
> Rear Center' */
> CHANNEL_POSITION_REAR_LEFT,/**< Microsoft calls this 
> 'Back Left', Apple calls this 'Left Surround' (!), Dolby calls this 'Surround 
> Rear Left'  */
> CHANNEL_POSITION_REAR_RIGHT,   /**< Microsoft calls this 
> 'Back Right', Apple calls this 'Right Surround' (!), Dolby calls this 
> 'Surround Rear Right'  */
> 
> CHANNEL_POSITION_LFE,  /**< Microsoft calls this 'Low 
> Frequency', Apple calls this 'LFEScreen' */
> CHANNEL_POSITION_SUBWOOFER = CHANNEL_POSITION_LFE,
> 
> CHANNEL_POSITION_FRONT_LEFT_OF_CENTER, /**< Apple, Dolby call this 
> 'Left Center' */
> CHANNEL_POSITION_FRONT_RIGHT_OF_CENTER,/**< Apple, Dolby call this 
> 'Right Center */
> 
> CHANNEL_POSITION_SIDE_LEFT,/**< Apple calls this 'Left 
> Surround Direct', Dolby calls this 'Surround Left' (!) */
> CHANNEL_POSITION_SIDE_RIGHT,   /**< Apple calls this 'Right 
> Surround Direct', Dolby calls this 'Surround Right' (!) */
> 
> CHANNEL_POSITION_AUX0,
> CHANNEL_POSITION_AUX1,
> CHANNEL_POSITION_AUX2,
> CHANNEL_POSITION_AUX3,
> CHANNEL_POSITION_AUX4,
> CHANNEL_POSITION_AUX5,
> CHANNEL_POSITION_AUX6,
> CHANNEL_POSITION_AUX7,
> CHANNEL_POSITION_AUX8,
> CHANNEL_POSITION_AUX9,
> CHANNEL_POSITION_AUX10,
> CHANNEL_POSITION_AUX11,
> CHANNEL_POSITION_AUX12,
> CHANNEL_POSITION_AUX13,
> CHANNEL_POSITION_AUX14,
> CHANNEL_POSITION_AUX15,
> CHANNEL_POSITION_AUX16,
> CHANNEL_POSITION_AUX17,
> CHANNEL_POSITION_AUX18,
> CHANNEL_POSITION_AUX19,
> CHANNEL_POSITION_AUX20,
> CHANNEL_POSITION_AUX21,
> CHANNEL_POSITION_AUX22,
> CHANNEL_POSITION_AUX23,
> CHANNEL_POSITION_AUX24,
> CHANNEL_POSITION_AUX25,
> CHANNEL_POSITION_AUX26,
> CHANNEL_POSITION_AUX27,
> CHANNEL_POSITION_AUX28,
> CHANNEL_POSITION_AUX29,
> CHANNEL_POSITION_AUX30,
> CHANNEL_POSITION_AUX31,
> 
> CHANNEL_POSITION_TOP_CENTER,   /**< Apple calls this 'Top 
> Center Surround' */
> 
> CHANNEL_POSITION_TOP_FRONT_LEFT,   /**< Apple calls this 
> 'Vertical Height Left' */
> CHANNEL_POSITION_TOP_FRONT_RIGHT,  /**< Apple calls this 
> 'Vertical Height Right' */
> CHANNEL_POSITION_TOP_FRONT_CENTER, /**< Apple calls this 
> 'Vertical Height Center' */
> 
> CHANNEL_POSITION_TOP_REAR_LEFT,/**< Microsoft and Apple call 
> this 'Top Back Left' */
> CHANNEL_POSITION_TOP_REAR_RIGHT,   /**< Microsoft and Apple call 
> this 'Top Back Right' */
> CHANNEL_POSITION_TOP_REAR_CENTER,  /**< Microsoft and Apple call 
> this 'Top Back Center' */
> 
> CHANNEL_POSITION_MAX
> };
> 
> /* Error codes copied from pulseaudio def.h */
> enum {
> OK = 0, /**< No error */
> ERR_ACCESS, /**< Access failure */
> ERR_COMMAND,/**< Unknown command */
> ERR_INVALID,/**< Invalid argument */
> ERR_EXIST,  /**< Entity exists */
> ERR_NOENTITY,   /**< No such entity */
> ERR_CONNECTIONREFUSED,  /**< Connection refused */
> ERR_PROTOCOL,   /**< Protocol error */
> ERR_TIMEOUT,/**< Timeout */
> ERR_AUTHKEY,/**< No authentication key */
> ERR_INTERNAL,   /**< Internal error */

Re: [pulseaudio-discuss] [alsa-devel] ALSA -> pulseaudio channel mapping, what is it (and why?)

[Tanu Kaskinen]

On Fri, 2019-05-03 at 11:05 -0700, frede...@ofb.net wrote:
> Dear ALSA developers,
> 
> I ran into a problem which seems to be caused by some lines in
> "alsa-plugins-1.1.8/pulse/pcm_pulse.c".
> 
> The problem is that if I create a 6-channel PulseAudio device, and
> then I configure an ALSA device in ~/.asoundrc to output to the
> PulseAudio device, the channels of the ALSA device are mixed together
> in various ways and don't correspond 1-1 with the channels of the
> PulseAudio device.
> 
> I find this to be counter-intuitive. If I wanted channels to be mixed
> and remapped in various ways, I would use the PulseAudio module
> module-remap-sink on the PulseAudio side, since AFAICT ALSA does not
> support named channels.

There is an API for querying and configuring PCM device channel maps.
pcm_pulse.c doesn't seem to implement that API, though, so applications
are expected to use the default channel map, and if that doesn't match
the sink channel map, then PulseAudio will do the remapping (and
possibly remixing, if the channel maps differ in other ways than just
channel order).

> I would not expect remixing to happen in the
> ALSA->Pulse bridge, since the relevant PCM plugin contains no channel
> map parameter.

The remixing happens in PulseAudio, not in pcm_pulse.c. pcm_pulse.c
just tells PulseAudio the channel map that the stream uses.

> I don't even know what channel map I should give the PulseAudio device
> in order to prevent remixing from occurring. The file pcm_pulse.c
> contains the lines:
> 
> for (c = pcm->ss.channels; c > 0; c--)
> if (pa_channel_map_init_auto(, c, PA_CHANNEL_MAP_ALSA))
> break;
> 
> This refers to a macro in /usr/include/pulse/channelmap.h:
> 
> /** \cond fulldocs */
> PA_CHANNEL_MAP_ALSA,
> /**< The default mapping used by ALSA. This mapping is probably
>  * not too useful since ALSA's default channel mapping depends on
>  * the device string used. */
> /** \endcond */
> 
> The comment says that the ALSA mapping is "not too useful" - so why
> are we using it?

pcm_pulse.c has to specify some channel map. Do you have better
proposals than PA_CHANNEL_MAP_ALSA?

> Also, how do I find out what it is, if it "depends on
> the device string used"?

There's currently no way to query the sink channel map through the ALSA
API. There's snd_pcm_get_chmap() that pcm_pulse.c could maybe
implement. There's the complication that usually the pulse PCM uses the
default sink, and the default sink can change at any time, so the
channel map can change at any time too, but that's probably not a huge
problem in practice.

> My preference would simply be to have a 1-1 channel map in pcm_pulse,
> so that a PulseAudio device with 6 channels will turn into an ALSA
> device with THE SAME 6 CHANNELS. No mixing. Mixing is confusing in
> this context, and seems undocumented outside of the code.

Remapping/remixing is very much expected in usual media playback cases.
If you have a 5.1 movie, it's easier for the player application to play
the audio in whatever channel order it wants and let the sound server
to remap and remix as necessary.

> I tried using aux0 thru aux5 as the PulseAudio channel map, to prevent
> geometry-based remixing. However, this results in silence - apparently
> none of the 6 ALSA channels end up going anywhere. That was also
> unexpected. Since I am playing 6-channel audio to a 6-channel device,
> which emulates another 6-channel device, I would have thought that the
> channel mapping wouldn't be complicated. Instead, it appears that the
> PulseAudio sink needs to have channels with specific names in order to
> receive data from ALSA.
> 
> Can we fix this, or improve the user experience?

What's the sink channel map in PulseAudio and what's your application's
channel map? Apparently one of them is not using the default ALSA map
for 6 channels.

If your application is not using the default channel map, why not?

If the sink is not using the default channel map, then it's expected
that PulseAudio shuffles the channels around, otherwise audio meant for
the front left speaker could end up in the rear right speaker, for
example. Do you have a use case for ignoring the channel map? Maybe the
SND_PCM_NO_AUTO_CHANNELS flag could be used in pcm_pulse.c to disable
channel remapping (I'm not volunteering to implement that, though).

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

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

Re: [pulseaudio-discuss] configure a soundcard?

[Tanu Kaskinen]

On Fri, 2019-04-26 at 07:37 -0500, Matt Zagrabelny wrote:
> On Fri, Apr 26, 2019 at 4:28 AM Tanu Kaskinen  wrote:
> 
> > > Card #1
> > > Name: alsa_card.pci-_00_14.2
> > 
> > ...
> > 
> > > Ports:
> > 
> > ...
> > 
> > > analog-output-lineout: Line Out (priority: 9900, latency
> > > offset: 0 usec, not available)
> > > Part of profile(s): output:analog-stereo,
> > > output:analog-stereo+input:analog-stereo, output:analog-surround-21,
> > > output:analog-surround-21+input:analog-stereo, output:analog-surround-40,
> > > output:analog-surround-40+input:analog-stereo, output:analog-surround-41,
> > > output:analog-surround-41+input:analog-stereo, output:analog-surround-50,
> > > output:analog-surround-50+input:analog-stereo, output:analog-surround-51,
> > > output:analog-surround-51+input:analog-stereo, output:analog-surround-71,
> > > output:analog-surround-71+input:analog-stereo
> > > analog-output-headphones: Headphones (priority: 9000,
> > > latency offset: 0 usec, not available)
> > > Properties:
> > > device.icon_name = "audio-headphones"
> > > Part of profile(s): output:analog-stereo,
> > > output:analog-stereo+input:analog-stereo
> > > iec958-stereo-output: Digital Output (S/PDIF) (priority:
> > 0,
> > > latency offset: 0 usec)
> > > Part of profile(s): output:iec958-stereo,
> > > output:iec958-stereo+input:analog-stereo
> > 
> > Both analog ports are marked as "not available", which means that to
> > PulseAudio looks like nothing is plugged in in either connector. This
> > is the reason why PulseAudio always picks the digital output on boot.
> > Broken jack detection is is a hardware or driver issue, which can be
> > worked around, see below.
> > 
> 
> Ahhh. Understood.
> 
> 
> > > > while read -r line; do amixer -c0 cget "$line"; done <<< $(amixer
> > -c0
> > > > controls | grep Jack)
> > > > 
> > > 
> > > numid=1,iface=CARD,name='HDMI/DP,pcm=3 Jack'
> > >   ; type=BOOLEAN,access=r---,values=1
> > >   : values=on
> > > numid=7,iface=CARD,name='HDMI/DP,pcm=7 Jack'
> > >   ; type=BOOLEAN,access=r---,values=1
> > >   : values=off
> > 
> > It seems that I guessed wrong the card number. Card 0 seems to be the
> > HDMI card, while we're interested in the analog sound card, which is
> > alsa card 1. So change the script to this:
> > 
> > while read -r line; do amixer -c0 cget "$line"; done <<< $(amixer -c0
> > controls | grep Jack)
> > 
> 
> I'm guessing I should change the above -c0's to -c1's.

Oops! Yes, that's what I meant.

> Here is that output:
> 
> numid=44,iface=CARD,name='CD Phantom Jack'
>   ; type=BOOLEAN,access=r---,values=1
>   : values=on
> numid=49,iface=CARD,name='Front Headphone Jack'
>   ; type=BOOLEAN,access=r---,values=1
>   : values=off
> numid=42,iface=CARD,name='Front Mic Jack'
>   ; type=BOOLEAN,access=r---,values=1
>   : values=off
> numid=43,iface=CARD,name='Line Jack'
>   ; type=BOOLEAN,access=r---,values=1
>   : values=off
> numid=47,iface=CARD,name='Line Out CLFE Jack'
>   ; type=BOOLEAN,access=r---,values=1
>   : values=off
> numid=45,iface=CARD,name='Line Out Front Jack'
>   ; type=BOOLEAN,access=r---,values=1
>   : values=off
> numid=48,iface=CARD,name='Line Out Side Jack'
>   ; type=BOOLEAN,access=r---,values=1
>   : values=off
> numid=46,iface=CARD,name='Line Out Surround Jack'
>   ; type=BOOLEAN,access=r---,values=1
>   : values=off
> numid=41,iface=CARD,name='Rear Mic Jack'
>   ; type=BOOLEAN,access=r---,values=1
>   : values=off
> numid=50,iface=CARD,name='SPDIF Jack'
>   ; type=BOOLEAN,access=r---,values=1
>   : values=off

Okay, the relevant jacks are "Front Headphone" and "Line Out Front". I
don't know if you're trying to use the headphone or the line out port,
but if you can disable jack detection for both:

In /usr/share/pulseaudio/alsa-mixer/paths/analog-output-
headphones.conf, change these lines:

[Jack Front Headphone]
required-any = any

to

[Jack Front Headphone]
required-any = any
state.plugged = unknown
state.unplugged = unknown

and similarly in /usr/share/pulseaudio/alsa-mixer/paths/analog-output-
lineout.conf change these lines:

[Jack Line Out Front]
required-any = any

to

[Jack Line Out Front]
required-any = any
state.plugged = unknown
state.unplugged = unknown

These changes will be overwritten whenever your distribution updates
pulseaudio (yes, this sucks, hopefully this will be improved some day;
I think George Chini already has something prepared related to
disabling jack detection).

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

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

Re: [pulseaudio-discuss] R: New equalizer module (module-eqpro-sink), some questions

[Tanu Kaskinen]

On Fri, 2019-04-26 at 11:40 +0200, Georg Chini wrote:
> On 26.04.19 10:56, Tanu Kaskinen wrote:
> > On Tue, 2019-04-23 at 21:20 +0200, Georg Chini wrote:
> > > The current scheme for
> > > updating
> > > parameters I have in mind should work for any of the existing filters
> > > and relies on
> > > passing around parameter structures:
> > > 
> > > 
> > >   /* The following functions can be provided to set and get
> > > parameters. The parameter
> > >* structure is defined by the filter and should contain all
> > > parameters that are
> > >* configurable by the user. The library code makes no assumption
> > > on the contents
> > >* of the structure but only passes references. The library
> > > implements a message
> > >* handler which supports the following messages that use the
> > > functions below:
> > >* get_parameter - Retrieve a single parameter.
> > >* set_parameter - Set a single parameter.
> > >* get_all_parameters - Retrieve all parameters as a comma
> > > separated list.
> > >* set_all_parameters - Set all parameters simultaneously.
> > >* get_parameter_description - Returns a list that describes all
> > > parameters.
> > >* Format of the list elements is:
> > >* {{Identifier}{Type}{default}{min}{max}}
> > >* The last message can be used to get information about the filter
> > > or to implement
> > >* a filter control GUI that is independent of the filter type. */
> > > 
> > >   /* Get the value of the parameter described by identifier. The
> > > value shall be returned
> > >* as a string in value. The identifier may be any string that the
> > > filter recognizes
> > >* like a name or index, depending of the implementation of this
> > > function. */
> > >   int (*parameter_get)(const char *identifier, char **value, void
> > > *userdata);
> > > 
> > >   /* Sets the value of the parameter described by identifier. The
> > > value is expected as
> > >* a string. The identifier may be any string that the filter
> > > recognizes like a name
> > >* or index. Returns a parameter structure filled with all current
> > > parameter values,
> > >* reflecting the updated parameter, so that the structure can be
> > > passed to
> > >* update_filter_parameter(). update_filter_parameter() will
> > > replace the current
> > >* parameter set with the new structure. */
> > >   void *(*parameter_set)(const char *identifier, const char *value,
> > > void *userdata);
> > > 
> > >   /* Returns a comma separated list of the values of all filter
> > > parameters. */
> > >   char *(*parameter_get_all)(void *userdata);
> > > 
> > >   /* Expects a comma separated list of all filter parameter values
> > > and returns a parameter
> > >* structure that can be passed to update_filter_parameters(). See
> > > set_parameter(). */
> > >   void *(*parameter_set_all(const char *all_params, void *userdata);
> > > 
> > >   /* Returns a parameter description string as described above. */
> > Some comments on the interface:
> 
> Thanks, that was what I hoped for.
> 
> > "Parameters as a comma separated list" sounds potentially problematic
> > if the specification extends to the public API as well, unless all
> > possible parameter types are defined to not contain commas. Why is the
> > list not encoded in the same way other lists are encoded in the message
> > API?
> 
> It surely can be encoded the same way, but currently the
> parameters for the LADSPA sink can be specified on the
> command line as a comma separated list, so I thought it
> would be a good idea to keep that format and allow other
> filters to do the same thing. I do not think it is a big restriction
> to not allow commas in the parameters. I can think of
> following parameter types: Int (signed and unsigned), float,
> bool and string. Only the string type would have a problem
> and we could use escaping there. Or do I miss something?
> The comma separated list is easier to understand for users
> of the interface.

Hmm, maybe you're right that it's a bit more user friendly format. It
feels somewhat ugly to send a list as a string when the transport has
native support for lists, but I think I can live with that.

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

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

Re: [pulseaudio-discuss] configure a soundcard?

[Tanu Kaskinen]

On Mon, 2019-04-22 at 07:47 -0500, Matt Zagrabelny wrote:
> On Mon, Apr 22, 2019 at 3:06 AM Tanu Kaskinen  wrote:
> 
> > On Sat, 2019-04-20 at 12:11 -0500, Matt Zagrabelny wrote:
> > > Greetings,
> > > 
> > > I'm running Debian Buster and I have a 1/8" audio jack. I need the sink
> > to
> > > be an analog output to send off to some other device. Things work great,
> > > except for when the system reboots, it comes up configured as a digital
> > > soundcard:
> > > 
> > > Digital Stereo (IEC958)
> > > 
> > > Here is a diff between a "pactl list" when the computer reboots and when
> > > I've configured it to be an analog sink:
> > > 
> > > -Sink #1
> > > -   State: SUSPENDED
> > > -   Name: alsa_output.pci-_00_14.2.iec958-stereo
> > > -   Description: Built-in Audio Digital Stereo (IEC958)
> > > +Sink #2
> > > +   State: RUNNING
> > > +   Name: alsa_output.pci-_00_14.2.analog-stereo
> > > +   Description: Built-in Audio Analog Stereo
> > > 
> > > What is the best way to have the configuration saved between reboots?
> > > 
> > > I can provide further info if needed.
> > > 
> > > Thanks for any help!
> 
> Hey Tanu!
> 
> Thanks for the assistance. Below is the output of what you asked for.



> Card #1
> Name: alsa_card.pci-_00_14.2

...

> Ports:

...

> analog-output-lineout: Line Out (priority: 9900, latency
> offset: 0 usec, not available)
> Part of profile(s): output:analog-stereo,
> output:analog-stereo+input:analog-stereo, output:analog-surround-21,
> output:analog-surround-21+input:analog-stereo, output:analog-surround-40,
> output:analog-surround-40+input:analog-stereo, output:analog-surround-41,
> output:analog-surround-41+input:analog-stereo, output:analog-surround-50,
> output:analog-surround-50+input:analog-stereo, output:analog-surround-51,
> output:analog-surround-51+input:analog-stereo, output:analog-surround-71,
> output:analog-surround-71+input:analog-stereo
> analog-output-headphones: Headphones (priority: 9000,
> latency offset: 0 usec, not available)
> Properties:
> device.icon_name = "audio-headphones"
> Part of profile(s): output:analog-stereo,
> output:analog-stereo+input:analog-stereo
> iec958-stereo-output: Digital Output (S/PDIF) (priority: 0,
> latency offset: 0 usec)
> Part of profile(s): output:iec958-stereo,
> output:iec958-stereo+input:analog-stereo

Both analog ports are marked as "not available", which means that to
PulseAudio looks like nothing is plugged in in either connector. This
is the reason why PulseAudio always picks the digital output on boot.
Broken jack detection is is a hardware or driver issue, which can be
worked around, see below.

> > while read -r line; do amixer -c0 cget "$line"; done <<< $(amixer -c0
> > controls | grep Jack)
> > 
> 
> numid=1,iface=CARD,name='HDMI/DP,pcm=3 Jack'
>   ; type=BOOLEAN,access=r---,values=1
>   : values=on
> numid=7,iface=CARD,name='HDMI/DP,pcm=7 Jack'
>   ; type=BOOLEAN,access=r---,values=1
>   : values=off

It seems that I guessed wrong the card number. Card 0 seems to be the
HDMI card, while we're interested in the analog sound card, which is
alsa card 1. So change the script to this:

while read -r line; do amixer -c0 cget "$line"; done <<< $(amixer -c0 
controls | grep Jack)

This information is required for me to give instructions for how to
work around the issue.

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

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

Re: [pulseaudio-discuss] [PATCH v9 0/8] Bluetooth A2DP codecs

[Tanu Kaskinen]

On Thu, 2019-04-25 at 19:03 +0200, Pali Rohár wrote:
> On Thursday 25 April 2019 18:54:05 Pali Rohár wrote:
> > On Thursday 25 April 2019 18:51:49 Pali Rohár wrote:
> > > On Thursday 25 April 2019 19:43:28 Luiz Augusto von Dentz wrote:
> > > > Hi Pali,
> > > > 
> > > > On Thu, Apr 25, 2019 at 2:42 PM Luiz Augusto von Dentz
> > > >  wrote:
> > > > > Hi Pali,
> > > > > 
> > > > > On Thu, Apr 25, 2019 at 2:35 PM Pali Rohár  
> > > > > wrote:
> > > > > > On Thursday 25 April 2019 13:28:16 Pali Rohár wrote:
> > > > > > > On Thursday 25 April 2019 14:19:15 Luiz Augusto von Dentz wrote:
> > > > > > > > These seems to work great, I can even switch on the fly the 
> > > > > > > > profiles
> > > > > > > > and after a short delay it switches without a problem, there is 
> > > > > > > > one
> > > > > > > > issue related to reconnecting though:
> > > > > > > > 
> > > > > > > > https://gist.github.com/Vudentz/40f10e85fb860083958edae67093f016
> > > > > > > > 
> > > > > > > > With BlueZ remembering the last used endpoint (aptX) it seems 
> > > > > > > > the
> > > > > > > > policy ignores that and reverts to highest priority (SBC UHQ),
> > > > > > 
> > > > > > Relevant lines:
> > > > > > 
> > > > > > D: [lt-pulseaudio] bluez5-util.c: Transport 
> > > > > > /org/bluez/hci0/dev_94_20_53_2E_08_CE/sep5/fd26 available for 
> > > > > > profile a2dp_sink_aptx
> > > > > > ...
> > > > > > D: [lt-pulseaudio] card.c: a2dp_sink_aptx availability unknown
> > > > > > ...
> > > > > > D: [lt-pulseaudio] card.c: off availability yes
> > > > > > I: [lt-pulseaudio] card.c: bluez_card.94_20_53_2E_08_CE: 
> > > > > > active_profile: a2dp_sink_sbc_uhq2
> > > > > > D: [lt-pulseaudio] module-bluetooth-policy.c: Looking for A2DP 
> > > > > > profile activated by bluez for card bluez_card.94_20_53_2E_08_CE
> > > > > > I: [lt-pulseaudio] card.c: Created 5 "bluez_card.94_20_53_2E_08_CE"
> > > > > > 
> > > > > > We got information that sep5 is activated with fd26 and it 
> > > > > > corespondent
> > > > > > to profile a2dp_sink_aptx. And on next lines we see that profile has
> > > > > > unknown availability -- which means that it is possible to switch to
> > > > > > that codec/profile, but it is not activated yet. On next lines we 
> > > > > > see
> > > > > > that module-bluetooth-policy is trying to find "a2dp_*" which has
> > > > > > availability "on", but there is no one. So initial profile stay
> > > > > > a2dp_sink_sbc_uhq2 which was chosen as default by card.c.
> > > > > > 
> > > > > > So problem is why a2dp_sink_aptx profile has unknown availability 
> > > > > > even
> > > > > > it is activated? It should have "on" availability. And then policy
> > > > > > choose it as initial.
> > > > > 
> > > > > Right, looks like the state is not correct since it has a fd already
> > > > > it should have been marked available.
> > > > 
> > > > Problem seems to be that we need to set the transport state to playing
> > > > since we introduce the following code:
> > > > 
> > > > if (cp->available == PA_AVAILABLE_NO &&
> > > > u->support_a2dp_codec_switch && pa_bluetooth_profile_is_a2dp(profile))
> > > > cp->available = PA_AVAILABLE_UNKNOWN;
> > > > 
> > > > That means every A2DP profile will be set to unknown including even if
> > > > they have no transport yet
> > > 
> > > That is truth. But if there is a transport then availability is YES.
> > > 
> > > Availability NO is used when it is not possible to activate transport
> > > because it is unsupported (e.g. A2DP not connected or when bluez does
> > > not support profile switching).
> > > 
> > > > so now we have to set the initial transport to playing
> > > 
> > > How it should help? I do not see reason now...
> > > 
> > > Anyway, I was not able to reproduce your problem, basically I always had
> > > availability for activated profile set to YES.
> > 
> > Now I see it. PA_AVAILABLE_YES is returned only for
> > PA_BLUETOOTH_TRANSPORT_STATE_PLAYING.
> > 
> > So for PA_BLUETOOTH_TRANSPORT_STATE_IDLE we also get
> > PA_AVAILABLE_UNKNOWN and therefore module-bluetooth-policy does not know
> > which transport is activated.
> > 
> > Cannot we get transport state in module-bluetooth-policy? Seems that
> > this is the right direction.
> 
> Currently we have following mapping:
> 
> PA_BLUETOOTH_TRANSPORT_STATE_DISCONNECTED --> PA_AVAILABLE_NO
> PA_BLUETOOTH_TRANSPORT_STATE_PLAYING --> PA_AVAILABLE_YES
> PA_BLUETOOTH_TRANSPORT_STATE_IDLE --> PA_AVAILABLE_UNKNOWN
> 
> Plus PA_AVAILABLE_NO is changed to PA_AVAILABLE_UNKNOWN when pulseaudio
> can activate that transport via bluez codec switch API as described
> above.
> 
> PA_PORT_AVAILABLE_YES is defined as:
> This port is available, likely because the jack is plugged in.
> 
> PA_PORT_AVAILABLE_NO as:
> This port is not available, likely because the jack is not plugged in.
> 
> And PA_PORT_AVAILABLE_UNKNOWN as:
> This port does not support jack detection
> 
> Seems that PA code and applications skips profiles with PA_AVAILABLE_NO
> and do not allow to use it. 

Re: [pulseaudio-discuss] [PATCH v9 0/8] Bluetooth A2DP codecs

[Tanu Kaskinen]

On Thu, 2019-04-25 at 18:54 +0200, Pali Rohár wrote:
> On Thursday 25 April 2019 18:51:49 Pali Rohár wrote:
> > On Thursday 25 April 2019 19:43:28 Luiz Augusto von Dentz wrote:
> > > Hi Pali,
> > > 
> > > On Thu, Apr 25, 2019 at 2:42 PM Luiz Augusto von Dentz
> > >  wrote:
> > > > Hi Pali,
> > > > 
> > > > On Thu, Apr 25, 2019 at 2:35 PM Pali Rohár  wrote:
> > > > > On Thursday 25 April 2019 13:28:16 Pali Rohár wrote:
> > > > > > On Thursday 25 April 2019 14:19:15 Luiz Augusto von Dentz wrote:
> > > > > > > These seems to work great, I can even switch on the fly the 
> > > > > > > profiles
> > > > > > > and after a short delay it switches without a problem, there is 
> > > > > > > one
> > > > > > > issue related to reconnecting though:
> > > > > > > 
> > > > > > > https://gist.github.com/Vudentz/40f10e85fb860083958edae67093f016
> > > > > > > 
> > > > > > > With BlueZ remembering the last used endpoint (aptX) it seems the
> > > > > > > policy ignores that and reverts to highest priority (SBC UHQ),
> > > > > 
> > > > > Relevant lines:
> > > > > 
> > > > > D: [lt-pulseaudio] bluez5-util.c: Transport 
> > > > > /org/bluez/hci0/dev_94_20_53_2E_08_CE/sep5/fd26 available for profile 
> > > > > a2dp_sink_aptx
> > > > > ...
> > > > > D: [lt-pulseaudio] card.c: a2dp_sink_aptx availability unknown
> > > > > ...
> > > > > D: [lt-pulseaudio] card.c: off availability yes
> > > > > I: [lt-pulseaudio] card.c: bluez_card.94_20_53_2E_08_CE: 
> > > > > active_profile: a2dp_sink_sbc_uhq2
> > > > > D: [lt-pulseaudio] module-bluetooth-policy.c: Looking for A2DP 
> > > > > profile activated by bluez for card bluez_card.94_20_53_2E_08_CE
> > > > > I: [lt-pulseaudio] card.c: Created 5 "bluez_card.94_20_53_2E_08_CE"
> > > > > 
> > > > > We got information that sep5 is activated with fd26 and it 
> > > > > corespondent
> > > > > to profile a2dp_sink_aptx. And on next lines we see that profile has
> > > > > unknown availability -- which means that it is possible to switch to
> > > > > that codec/profile, but it is not activated yet. On next lines we see
> > > > > that module-bluetooth-policy is trying to find "a2dp_*" which has
> > > > > availability "on", but there is no one. So initial profile stay
> > > > > a2dp_sink_sbc_uhq2 which was chosen as default by card.c.
> > > > > 
> > > > > So problem is why a2dp_sink_aptx profile has unknown availability even
> > > > > it is activated? It should have "on" availability. And then policy
> > > > > choose it as initial.
> > > > 
> > > > Right, looks like the state is not correct since it has a fd already
> > > > it should have been marked available.
> > > 
> > > Problem seems to be that we need to set the transport state to playing
> > > since we introduce the following code:
> > > 
> > > if (cp->available == PA_AVAILABLE_NO &&
> > > u->support_a2dp_codec_switch && pa_bluetooth_profile_is_a2dp(profile))
> > > cp->available = PA_AVAILABLE_UNKNOWN;
> > > 
> > > That means every A2DP profile will be set to unknown including even if
> > > they have no transport yet
> > 
> > That is truth. But if there is a transport then availability is YES.
> > 
> > Availability NO is used when it is not possible to activate transport
> > because it is unsupported (e.g. A2DP not connected or when bluez does
> > not support profile switching).
> > 
> > > so now we have to set the initial transport to playing
> > 
> > How it should help? I do not see reason now...
> > 
> > Anyway, I was not able to reproduce your problem, basically I always had
> > availability for activated profile set to YES.
> 
> Now I see it. PA_AVAILABLE_YES is returned only for
> PA_BLUETOOTH_TRANSPORT_STATE_PLAYING.
> 
> So for PA_BLUETOOTH_TRANSPORT_STATE_IDLE we also get
> PA_AVAILABLE_UNKNOWN and therefore module-bluetooth-policy does not know
> which transport is activated.
> 
> Cannot we get transport state in module-bluetooth-policy? Seems that
> this is the right direction.

Yes, I think module-bluetooth-policy should look at the transport
states directly, if that provides better information than the profile
availability.

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

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

Re: [pulseaudio-discuss] R: New equalizer module (module-eqpro-sink), some questions

[Tanu Kaskinen]

On Tue, 2019-04-23 at 21:20 +0200, Georg Chini wrote:
> On 22.04.19 09:34, Tanu Kaskinen wrote:
> > On Sat, 2019-04-20 at 11:38 +0200, Georg Chini wrote:
> > > PA uses malloc() in the IO-thread, so are we doing things wrong?
> > > I think using malloc() when a parameter changes is not interfering
> > > with real-time operation because the filter must be reset after
> > > a parameter change anyway.
> Am I allowed to use free() from the I/O-thread?

No. To my knowledge a lot of the memory management work may actually
happen in free() rather than malloc().

> The current scheme for 
> updating
> parameters I have in mind should work for any of the existing filters 
> and relies on
> passing around parameter structures:
> 
> 
>  /* The following functions can be provided to set and get 
> parameters. The parameter
>   * structure is defined by the filter and should contain all 
> parameters that are
>   * configurable by the user. The library code makes no assumption 
> on the contents
>   * of the structure but only passes references. The library 
> implements a message
>   * handler which supports the following messages that use the 
> functions below:
>   * get_parameter - Retrieve a single parameter.
>   * set_parameter - Set a single parameter.
>   * get_all_parameters - Retrieve all parameters as a comma 
> separated list.
>   * set_all_parameters - Set all parameters simultaneously.
>   * get_parameter_description - Returns a list that describes all 
> parameters.
>   * Format of the list elements is:
>   * {{Identifier}{Type}{default}{min}{max}}
>   * The last message can be used to get information about the filter 
> or to implement
>   * a filter control GUI that is independent of the filter type. */
> 
>  /* Get the value of the parameter described by identifier. The 
> value shall be returned
>   * as a string in value. The identifier may be any string that the 
> filter recognizes
>   * like a name or index, depending of the implementation of this 
> function. */
>  int (*parameter_get)(const char *identifier, char **value, void 
> *userdata);
> 
>  /* Sets the value of the parameter described by identifier. The 
> value is expected as
>   * a string. The identifier may be any string that the filter 
> recognizes like a name
>   * or index. Returns a parameter structure filled with all current 
> parameter values,
>   * reflecting the updated parameter, so that the structure can be 
> passed to
>   * update_filter_parameter(). update_filter_parameter() will 
> replace the current
>   * parameter set with the new structure. */
>  void *(*parameter_set)(const char *identifier, const char *value, 
> void *userdata);
> 
>  /* Returns a comma separated list of the values of all filter 
> parameters. */
>  char *(*parameter_get_all)(void *userdata);
> 
>  /* Expects a comma separated list of all filter parameter values 
> and returns a parameter
>   * structure that can be passed to update_filter_parameters(). See 
> set_parameter(). */
>  void *(*parameter_set_all(const char *all_params, void *userdata);
> 
>  /* Returns a parameter description string as described above. */

Some comments on the interface:

"Parameters as a comma separated list" sounds potentially problematic
if the specification extends to the public API as well, unless all
possible parameter types are defined to not contain commas. Why is the
list not encoded in the same way other lists are encoded in the message
API?

"{{Identifier}{Type}{default}{min}{max}}" is probably too strict for
the parameter description specification, if it extends to the public
API as well. Min/max only works for range values, but I can imagine
some filter having a "choose one from a list of non-numeric options". I
think the structure after {default} should be dependent on the
parameter type.

> This would allocate the memory in the main thread but would require that
> the I/O-thread frees the old parameter structure when it is replaced. 
> Alternatively
> the function that replaces the old structure with the new one could return a
> pointer to the old structure, so that it can be freed in the main thread.

That should work. The structures probably have fixed size, though, in
which case malloc()/free() can be avoided altogether: the filters can
allocate two instances of the internal structures during intialization 
and switch between them when parameters are updated.

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

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

Re: [pulseaudio-discuss] pulseaudio still running before shutdown

[Tanu Kaskinen]

On Mon, 2019-04-22 at 12:58 +0200, Christian wrote:
> Hi Tanu,
> 
> thanks a lot for your answer and suggestion.
> 
> First of all I have to apologize for getting something wrong.
> I wrote:
> 
> "I don´t know why I get this message because the shutdown works well
> despite that error message. In fact it shuts down really fast."
> 
> That´s /incorrect/. In fact it´s like this:  the fact that pulseaudio is 
> still running indeed *prevents the shutdown *.
> I mixed it up with another project of mine. Sorry about that.
> 
> Now to your suggestion:
> 
> I looked  up _/etc/pulse/daemon.conf_. 
> 
> The "exit-idle-time"-value is currently set like so:
> 
> ; exit-idle-time = 20
> 
> The man-pages say: "Terminate  the  daemon after the last client quit and 
> this time in seconds passed."
> 
> Well, I think with the semicolon in front that value wasn´t set at all, right?
> So I´d have to get rid of the semicolon and then set "exit-idle-time = 0".
> 
> Would that be the way to go?

Yes.

> P.S.: 
> I still don´t understand why there are *two *proceses running before shutdown:
> 
> ps -ax | grep -i pulseaudio
>  1515 ?Sl 0:00 /usr/bin/pulseaudio --start --log-target=syslog
>  2348 ?Sl 0:01 /usr/bin/pulseaudio --start --log-target=syslog
>  3820 pts/2S+ 0:00 grep --color=auto -i pulseaudio

I would guess the other one is for gdm. You can use "pa aux" to see
also the user of the process.

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

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

Re: [pulseaudio-discuss] R: New equalizer module (module-eqpro-sink), some questions

[Tanu Kaskinen]

On Mon, 2019-04-22 at 11:23 +0200, Georg Chini wrote:
> On 22.04.19 09:34, Tanu Kaskinen wrote:
> > On Sat, 2019-04-20 at 11:38 +0200, Georg Chini wrote:
> > > PA uses malloc() in the IO-thread, so are we doing things wrong?
> > > I think using malloc() when a parameter changes is not interfering
> > > with real-time operation because the filter must be reset after
> > > a parameter change anyway.
> > Where exactly is malloc() used? Sounds like a bug.
> 
> Well, for example pa_memblock_new() potentially uses malloc and
> this is surely used from the I/O thread. I did not check, but I guess
> there are also places where something like pa_xstrdup() or pa_xnew()
> is used from the I/O thread. At least I was not aware that there
> are any restrictions.
> pa_rtpoll_item_new() also potentially uses malloc().
> 
> All in all there are many places where malloc() might be used.

pa_memblock_new() and pa_rtpoll_item_new() both use malloc() only if
they run out of preallocated blocks/items (and the preallocation is
done precisely to avoid calling malloc()).

> > 
> > > Well, after evaluation of the feedback I have been getting so far,
> > > I do not think I will make an attempt to create some plugin-sink.
> > > The existing standards do not fit to what I have in mind and
> > > if I read Alexander right they even intentionally do not support
> > > those features.
> > > 
> > > Inventing a PA internal standard does not make sense, because
> > > your main argument against implementing the equalizer as a module
> > > was that you did not want to host the DSP code inside PA. If we
> > > did our own standard, new filters would again be bound to PA.
> > New filters would be specific to PA, yes, but not maintained by us, and
> > new filters wouldn't have to go through the review process, so there
> > would still be some benefit in having a PA specific stable plugin API.
> > 
> I don't understand. What is the difference between having DSP
> code in a module or in a filter plugin?

The difference is that the module API is not stable, so people can't
maintain their filters outside the upstream PulseAudio repository.

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

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

Re: [pulseaudio-discuss] pulseaudio still running before shutdown

[Tanu Kaskinen]

On Sun, 2019-04-21 at 13:37 +0200, Christian wrote:
> Hi,
> 
> 
> INFO:
> my system: Linux/Lubuntu 18.04.2 LTS, 64 bit
> 
> 
> I shut down my system with the terminal-command "shutdown -H -P +0" or
> "poweroff". But the observed phenomenon may also be seen when
> shutting down from the panel.
> 
> I changed my grub-config from GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
> to GRUB_CMDLINE_LINUX_DEFAULT="noplymouth" in order to get screen output
> of the logs.
> 
> And here I see an entry reading "failed unmounting /home" (in red).
> After that came some more messages which all were O.K. Everything else
> was in green with an "O.K." in front.
> 
> I don´t know why I get this message because the shutdown works well
> despite that error message. In fact it shuts down really fast.
> 
> So I took alook at journalctl. It shows me the following:
> 
> [...]
> Apr 05 18:16:19 rosika-Lenovo-H520e umount[25556]: umount: /home: das
> Ziel wird gerade benutzt. # /home is currently in use
> Apr 05 18:16:19 rosika-Lenovo-H520e systemd[1]: Unmounting
> /media/rosika/28BC-DAFC...
> Apr 05 18:16:19 rosika-Lenovo-H520e systemd[1]: Unmounting
> /media/rosika/f14a27c2-0b49-4607-94ea-2e56bbf76fe1...
> Apr 05 18:16:19 rosika-Lenovo-H520e systemd[1]: home.mount: Mount
> process exited, code=exited status=32
> Apr 05 18:16:19 rosika-Lenovo-H520e systemd[1]: Failed unmounting /home.
> # <-
> [...]
> 
> I found out that a pulseaudio process seems to be the culprit.
> 
> So I looked up the proceses before shutdown:
> 
> ps -ax | grep -i pulseaudio
>  1515 ?Sl 0:00 /usr/bin/pulseaudio --start --log-target=syslog
>  2348 ?Sl 0:01 /usr/bin/pulseaudio --start --log-target=syslog
>  3820 pts/2S+ 0:00 grep --color=auto -i pulseaudio
> 
> There are two pulseaudio processes running (!). I don´t know why. This
> is the state immediately before shutdown. All programmes are closed
> and nothing should be running regarding pulseaudio.
> 
> So I perform " killall pulseaudio" immediately before shutdown. After
> that I get no error messages at all.
> 
> Does anybody know what can be done about this?
> 
> Tnx a lot in advance.

Does setting "exit-idle-time = 0" in /etc/pulse/daemon.conf help?

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

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

Re: [pulseaudio-discuss] [PATCH] alsa: Fix inclusion of use-case.h

[Tanu Kaskinen]

On Sun, 2019-04-21 at 11:59 +0200, Takashi Iwai wrote:
> The recent change in ALSA upstream stripped -I$include/alsa path from
> pkgconfig.  We already fixed for this change in some places but still
> the code for UCM was overlooked, and this resulted in the unresolved
> symbols in alsa card module. Fix them as well.
> 
> Signed-off-by: Takashi Iwai 
> ---
>  configure.ac| 2 +-
>  src/modules/alsa/alsa-ucm.h | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/configure.ac b/configure.ac
> index c004bd70d1b2..b44ed1595af3 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -826,7 +826,7 @@ AS_IF([test "x$enable_alsa" = "xyes" && test 
> "x$HAVE_ALSA" = "x0"],
>  AS_IF([test "x$HAVE_ALSA" = "x1"],
>  [
>  save_CPPFLAGS="$CPPFLAGS"; CPPFLAGS="$CPPFLAGS $ASOUNDLIB_CFLAGS"
> -AC_CHECK_HEADERS([use-case.h], HAVE_ALSA_UCM=1, HAVE_ALSA_UCM=0)
> +AC_CHECK_HEADERS([alsa/use-case.h], HAVE_ALSA_UCM=1, HAVE_ALSA_UCM=0)
>  CPPFLAGS="$save_CPPFLAGS"
>  ],
>  HAVE_ALSA_UCM=0)
> diff --git a/src/modules/alsa/alsa-ucm.h b/src/modules/alsa/alsa-ucm.h
> index 53abf3f90845..c926f3cc39a6 100644
> --- a/src/modules/alsa/alsa-ucm.h
> +++ b/src/modules/alsa/alsa-ucm.h
> @@ -23,7 +23,7 @@
>  ***/
>  
>  #ifdef HAVE_ALSA_UCM
> -#include 
> +#include 
>  #else
>  typedef void snd_use_case_mgr_t;
>  #endif

Thanks! Applied.

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

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

Re: [pulseaudio-discuss] configure a soundcard?

[Tanu Kaskinen]

On Sat, 2019-04-20 at 12:11 -0500, Matt Zagrabelny wrote:
> Greetings,
> 
> I'm running Debian Buster and I have a 1/8" audio jack. I need the sink to
> be an analog output to send off to some other device. Things work great,
> except for when the system reboots, it comes up configured as a digital
> soundcard:
> 
> Digital Stereo (IEC958)
> 
> Here is a diff between a "pactl list" when the computer reboots and when
> I've configured it to be an analog sink:
> 
> -Sink #1
> -   State: SUSPENDED
> -   Name: alsa_output.pci-_00_14.2.iec958-stereo
> -   Description: Built-in Audio Digital Stereo (IEC958)
> +Sink #2
> +   State: RUNNING
> +   Name: alsa_output.pci-_00_14.2.analog-stereo
> +   Description: Built-in Audio Analog Stereo
> 
> What is the best way to have the configuration saved between reboots?
> 
> I can provide further info if needed.
> 
> Thanks for any help!

What does "pactl list cards" print, and what does this little script
print?

while read -r line; do amixer -c0 cget "$line"; done <<< $(amixer -c0 
controls | grep Jack)

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

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

Re: [pulseaudio-discuss] [PATCH v8 08/12] bluetooth: Add A2DP FastStream codec support

[Tanu Kaskinen]

On Sat, 2019-04-20 at 11:24 +0200, Pali Rohár wrote:
> On Saturday 20 April 2019 11:37:56 Tanu Kaskinen wrote:
> > On Sat, 2019-04-06 at 11:16 +0200, Pali Rohár wrote:
> > > This patch provides support for FastStream codec in bluetooth A2DP 
> > > profile.
> > > FastStream codec is bi-directional, which means that support both music
> > > playback and microphone voice at the same time.
> > > 
> > > FastStream codec is just SBC codec with fixed parameters. For playback are
> > > used following parameters: 48.0kHz or 44.1kHz, Blocks 16, Sub-bands 8,
> > > Joint Stereo, Loudness, Bitpool = 29 (data rate = 212kbps, packet size =
> > > (71+1)*3+4 = 220 = DM5). SBC frame size is 71 bytes, but padded with one
> > > zero byte due to rounding to 72 bytes. For microphone are used following
> > > SBC parameters: 16kHz, Mono, Blocks 16, Sub-bands 8, Loudness, Bitpool = 
> > > 32
> > > (data rate = 72kbps, packet size = 3*72 + 4 = 220 <= DM5).
> > > 
> > > So FastStream codec is slightly equivalent to SBC Low Quality settings
> > > (which uses bitpool value 30). But the main benefit of FastStream codec is
> > > support for microphone voice channel for audio calls. Compared to 
> > > bluetooth
> > > HSP profile (with CVSD codec), it provides better audio quality for both
> > > playback and recording.
> > > ---
> > >  src/Makefile.am   |   2 +
> > >  src/modules/bluetooth/a2dp-codec-faststream.c | 436 
> > > ++
> > >  src/modules/bluetooth/a2dp-codec-util.c   |   2 +
> > >  3 files changed, 440 insertions(+)
> > >  create mode 100644 src/modules/bluetooth/a2dp-codec-faststream.c
> > > +static bool is_configuration_valid(const uint8_t *config_buffer, uint8_t 
> > > config_size) {
> > > +const a2dp_faststream_t *config = (const a2dp_faststream_t *) 
> > > config_buffer;
> > > +
> > > +if (config_size != sizeof(*config)) {
> > > +pa_log_error("Invalid size of config buffer");
> > > +return false;
> > > +}
> > > +
> > > +if (A2DP_GET_VENDOR_ID(config->info) != FASTSTREAM_VENDOR_ID || 
> > > A2DP_GET_CODEC_ID(config->info) != FASTSTREAM_CODEC_ID) {
> > > +pa_log_error("Invalid vendor codec information in 
> > > configuration");
> > > +return false;
> > > +}
> > > +
> > > +if (!(config->direction & FASTSTREAM_DIRECTION_SINK) || 
> > > !(config->direction & FASTSTREAM_DIRECTION_SOURCE)) {
> > > +pa_log_error("Invalid direction in configuration");
> > > +return false;
> > > +}
> > > +
> > > +/* Remote endpoint indicates list of frequences, not just one 
> > > frequency */
> > 
> > Typo: "frequences" -> "frequencies".
> 
> Ok, I will fix all occurrences.
> 
> > > +if ((config->sink_frequency & 
> > > ~(FASTSTREAM_SINK_SAMPLING_FREQ_44100|FASTSTREAM_SINK_SAMPLING_FREQ_48000))
> > >  ||
> > > +   (!(config->sink_frequency & 
> > > (FASTSTREAM_SINK_SAMPLING_FREQ_44100|FASTSTREAM_SINK_SAMPLING_FREQ_48000
> > >  {
> > 
> > Do we really need to be this strict?
> 
> Yes.
> 
> > The final sample rate is decided
> > by us, so isn't it enough if the config contains just one of the rates
> > that we support? If the sink supports some other rates, we don't need
> > to care about that.
> 
> Normally in A2DP capabilities buffer device announces combination (list)
> of supported features and configurations. In A2DP config buffer device
> usually says one exact configuration which should be used.
> 
> But my testing headphones in A2DP FastStream config buffer sometimes
> says that sink frequency is both 44100|48000 -- which does not make
> sense. When pulseaudio started sending SBC data with 44.1kHz then sound
> was obviously bad, there was periodically quiet period (should be for
> 1.8 us). When pulseaudio started sending SBC data with 48kHz everything
> was OK. So conclusion is that when headphones says that sampling
> frequency is both 44100|48000 in config buffer they means it is 48kHz.
> 
> In function is_configuration_valid we need to ensure that pulseaudio and
> remove device negotiate correctly all parameters, including sampling
> frequency and both sides know how to interpret config buffer.
> 
> So strictness is needed to ensure that audio 

Re: [pulseaudio-discuss] R: New equalizer module (module-eqpro-sink), some questions

[Tanu Kaskinen]

On Sat, 2019-04-20 at 11:38 +0200, Georg Chini wrote:
> On 20.04.19 11:06, Tanu Kaskinen wrote:
> > On Fri, 2019-04-19 at 17:52 +0200, Georg Chini wrote:
> > > On 19.04.19 16:56, Tanu Kaskinen wrote:
> > > > Changing the number of eq bands isn't quite like changing regular
> > > > control values. The plugin probably has some per-band data, which has
> > > > to be reallocated when the number of bands changes. malloc() isn't
> > > > allowed in the IO thread. Also, all gain values assigned to the bands
> > > > previously are likely useless, because the band frequencies change. The
> > > > host will likely have to set all bands to the default gain value, so in
> > > > effect changing the band count is like starting from scratch, which is
> > > > very different from changing a regular control value.
> > > Yes, you are right, it would be like starting from scratch. It
> > > would however be not the primary goal to change the number
> > > of bands at run-time, but to be able to define the number of
> > > bands dynamically when the instance is created. Because this
> > > would affect the number of necessary ports (per band gains)
> > > it is not possible with the current definition unless you have
> > > a control port that can be an array. As a side effect, the band
> > > count could also be changed dynamically at run-time.
> > > 
> > > Why would malloc() not be allowed in the IO-thread? It's not
> > > allowed within the run() function, but that's a different thing.
> > Why is it a different thing? malloc() is not allowed in the run()
> > function, because the function is expected to be run in a realtime
> > thread, and malloc() is not realtime-safe. The IO thread is a realtime
> > thread, so the same limitations apply also outside the run() function.
> 
> PA uses malloc() in the IO-thread, so are we doing things wrong?
> I think using malloc() when a parameter changes is not interfering
> with real-time operation because the filter must be reset after
> a parameter change anyway.

Where exactly is malloc() used? Sounds like a bug.

Using malloc() when changing parameters does interfere with realtime
operation, because there may be more audio paths to the hardware sink
than just the ladspa filter. There may be streams that aren't filtered.

> > > > If the eq band count was an initialization parameter rather than a
> > > > control port, the IO thread limitations wouldn't become an issue, and
> > > > it would be explicit that changing the eq band count means starting
> > > > from scratch. It should still be possible to change initialization
> > > > parameters at runtime, that would just mean that a new plugin instance
> > > > is created and the old instance is removed.
> > > > 
> > > It is not possible to have that kind of initialization parameter.
> > > That is the main problem. As explained above, changing the
> > > number of bands would require changing the number of control
> > > ports.
> > If we're adding new stuff to the LADSPA interface anyway, we can surely
> > add a function that sets initialization parameters (and a function for
> > querying what initialization parameters the plugin has). We can then
> > specify that the control ports are to be created only after the
> > initialization parameters have been set.
> > 
> Well, after evaluation of the feedback I have been getting so far,
> I do not think I will make an attempt to create some plugin-sink.
> The existing standards do not fit to what I have in mind and
> if I read Alexander right they even intentionally do not support
> those features.
> 
> Inventing a PA internal standard does not make sense, because
> your main argument against implementing the equalizer as a module
> was that you did not want to host the DSP code inside PA. If we
> did our own standard, new filters would again be bound to PA.

New filters would be specific to PA, yes, but not maintained by us, and
new filters wouldn't have to go through the review process, so there
would still be some benefit in having a PA specific stable plugin API.

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

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

Re: [pulseaudio-discuss] R: New equalizer module (module-eqpro-sink), some questions

[Tanu Kaskinen]

On Fri, 2019-04-19 at 17:52 +0200, Georg Chini wrote:
> On 19.04.19 16:56, Tanu Kaskinen wrote:
> > On Fri, 2019-04-19 at 12:03 +0200, Georg Chini wrote:
> > > On 19.04.19 11:13, Tanu Kaskinen wrote:
> > > > On Tue, 2019-04-16 at 21:40 +0200, Georg Chini wrote:
> > > > > On 16.04.19 19:19, Tanu Kaskinen wrote:
> > > > > > On Thu, 2019-04-11 at 20:42 +0200, Georg Chini wrote:
> > > > > > > On 11.04.19 19:36, Tanu Kaskinen wrote:
> > > > > > > > If you want a better plugin standard, are you aware of LV2
> > > > > > > > and PipeWire's SPA (the latter doesn't seem to be properly 
> > > > > > > > documented
> > > > > > > > yet, but to my understanding it's supposed to have a stable and
> > > > > > > > flexible API)?
> > > > > > > Arun already suggested the pipewire SPA. I took a look, but it
> > > > > > > seems not very simple compared to LADSPA. I could not really
> > > > > > > understand how it works and it appears to support a lot more
> > > > > > > than just filters.
> > > > > > LV2 would also be an option, although it too is pretty complex 
> > > > > > compared
> > > > > > to LADSPA. But at least it's documented and has examples.
> > > > > I just took a look and on the first glance LV2 seems similar
> > > > > to LADSPA. I have to dig into the details though, maybe control
> > > > > arrays and interleaved audio ports are possible there.
> > > > I'm pretty sure they are possible, but neither of those features are
> > > > necessary. If the plugin gets the number of bands during the
> > > > initialization, it can create the appropriate number of non-array
> > > > control ports. Interleaved audio ports aren't needed either, because
> > > > PulseAudio can do the deinterleaving before passing the audio to the
> > > > plugin (like module-ladspa-sink already does). If one's going to write
> > > > an LV2 plugin, it's best to use standard port types so that all hosts
> > > > will be able to use the plugin.
> > > The problem here is that the number of ports must be known before
> > > the initialization because it is something which is already provided by
> > > the plugin descriptor. So there seems to be no way to change that
> > > number dynamically unless I misread the documentation. But looking
> > > at the LV2 standard, it supplies the port type lv2:CVPort (see
> > > https://gitlab.com/lv2/lv2/blob/master/lv2/core/lv2core.ttl, line 256)
> > > which is what I have been looking for if I read the documentation
> > > right.
> > I don't think CVPorts are relevant for this discussion. As far as I can
> > tell, they just provide a different kind of control port, one that can
> > use audio signal as input. You wanted a port that can take an array of
> > values, CVPorts isn't that.
> 
> The documentation basically says it is an array of floats which is
> not audio but control data. So it is very relevant here. This is
> exactly what is needed if you want to support a variable number
> of bands because you need a variable number of gains.

It's not just any random array, it's an array that the host can feed
control values at the same rate as it feeds audio to the audio ports.
So if the host sees an input CVPort, it will expect that the port can
be connected to an output CVPort or to an audio output port.

> > You seem to be right about the requirement to declare all ports in
> > advance. I thought dynamic ports would be the primary benefit of using
> > LV2 rather than creating a custom API based on LADSPA.
> > 
> > > Concerning interleaved audio format: Up to now I found nothing
> > > that explicitly forbids interleaved audio though it appears that the
> > > plugins usually provide one audio port per channel.
> > You can't use a plain AudioPort for interleaved audio, because hosts
> > will assume that it operates with mono audio. You can probably define a
> > subclass of AudioPort with different semantics, but then hosts other
> > than PulseAudio won't be able to use the plugin (unless they adopt your
> > extension).
> 
> Other hosts could still use the plugin because mono would
> be perfectly acceptable. But I agree that we should not
> implement something that is not in the specification. What
> should be possible however is writing an LV2 extension that
> allows interleaved ports. If hosts do not support this extension,
> the p

Re: [pulseaudio-discuss] [PATCH v8 08/12] bluetooth: Add A2DP FastStream codec support

[Tanu Kaskinen]

On Sat, 2019-04-06 at 11:16 +0200, Pali Rohár wrote:
> This patch provides support for FastStream codec in bluetooth A2DP profile.
> FastStream codec is bi-directional, which means that support both music
> playback and microphone voice at the same time.
> 
> FastStream codec is just SBC codec with fixed parameters. For playback are
> used following parameters: 48.0kHz or 44.1kHz, Blocks 16, Sub-bands 8,
> Joint Stereo, Loudness, Bitpool = 29 (data rate = 212kbps, packet size =
> (71+1)*3+4 = 220 = DM5). SBC frame size is 71 bytes, but padded with one
> zero byte due to rounding to 72 bytes. For microphone are used following
> SBC parameters: 16kHz, Mono, Blocks 16, Sub-bands 8, Loudness, Bitpool = 32
> (data rate = 72kbps, packet size = 3*72 + 4 = 220 <= DM5).
> 
> So FastStream codec is slightly equivalent to SBC Low Quality settings
> (which uses bitpool value 30). But the main benefit of FastStream codec is
> support for microphone voice channel for audio calls. Compared to bluetooth
> HSP profile (with CVSD codec), it provides better audio quality for both
> playback and recording.
> ---
>  src/Makefile.am   |   2 +
>  src/modules/bluetooth/a2dp-codec-faststream.c | 436 
> ++
>  src/modules/bluetooth/a2dp-codec-util.c   |   2 +
>  3 files changed, 440 insertions(+)
>  create mode 100644 src/modules/bluetooth/a2dp-codec-faststream.c

> +static bool is_configuration_valid(const uint8_t *config_buffer, uint8_t 
> config_size) {
> +const a2dp_faststream_t *config = (const a2dp_faststream_t *) 
> config_buffer;
> +
> +if (config_size != sizeof(*config)) {
> +pa_log_error("Invalid size of config buffer");
> +return false;
> +}
> +
> +if (A2DP_GET_VENDOR_ID(config->info) != FASTSTREAM_VENDOR_ID || 
> A2DP_GET_CODEC_ID(config->info) != FASTSTREAM_CODEC_ID) {
> +pa_log_error("Invalid vendor codec information in configuration");
> +return false;
> +}
> +
> +if (!(config->direction & FASTSTREAM_DIRECTION_SINK) || 
> !(config->direction & FASTSTREAM_DIRECTION_SOURCE)) {
> +pa_log_error("Invalid direction in configuration");
> +return false;
> +}
> +
> +/* Remote endpoint indicates list of frequences, not just one frequency 
> */

Typo: "frequences" -> "frequencies".

> +if ((config->sink_frequency & 
> ~(FASTSTREAM_SINK_SAMPLING_FREQ_44100|FASTSTREAM_SINK_SAMPLING_FREQ_48000)) ||
> +   (!(config->sink_frequency & 
> (FASTSTREAM_SINK_SAMPLING_FREQ_44100|FASTSTREAM_SINK_SAMPLING_FREQ_48000 {

Do we really need to be this strict? The final sample rate is decided
by us, so isn't it enough if the config contains just one of the rates
that we support? If the sink supports some other rates, we don't need
to care about that.

> +pa_log_error("Invalid sampling sink frequency in configuration");
> +return false;
> +}
> +
> +/* Remote endpoint indicates list of frequences, not just one frequency 
> */

Typo: "frequences" -> "frequencies".

Is this comment really true for sources? I can understand that the
device can list multiple sink frequencies if it doesn't care what we
send, but is the device really allowed to be imprecise about what kind
of audio it will send through the backchannel?

> +if (config->source_frequency != FASTSTREAM_SOURCE_SAMPLING_FREQ_16000) {
> +pa_log_error("Invalid sampling source frequency in configuration");
> +return false;
> +}
> +
> +return true;
> +}


> +static void *init(bool for_encoding, bool for_backchannel, const uint8_t 
> *config_buffer, uint8_t config_size, pa_sample_spec *sample_spec) {
> +struct faststream_info *faststream_info;
> +const a2dp_faststream_t *config = (const a2dp_faststream_t *) 
> config_buffer;
> +int ret;
> +
> +pa_assert(config_size == sizeof(*config));
> +
> +faststream_info = pa_xnew0(struct faststream_info, 1);
> +faststream_info->is_backchannel = for_backchannel;
> +
> +ret = sbc_init(_info->sbc, 0);
> +if (ret != 0) {
> +pa_xfree(faststream_info);
> +pa_log_error("SBC initialization failed: %d", ret);
> +return NULL;
> +}
> +
> +sample_spec->format = PA_SAMPLE_S16LE;
> +
> +if (faststream_info->is_backchannel) {
> +/* config buffer contains list of frequences, not just one frequency 
> */

As with the earlier comment on this topic, it seems unlikely to me that
there can be multiple source frequencies listed. If there can, then how
do we communicate to the device that we expect 16kHz?

> +if (config->source_frequency & 
> FASTSTREAM_SOURCE_SAMPLING_FREQ_16000) {
> +faststream_info->frequency = SBC_FREQ_16000;
> +sample_spec->rate = 16000U;
> +} else {
> +pa_assert_not_reached();
> +}


> +static size_t decode_buffer(void *codec_info, const uint8_t *input_buffer, 
> size_t input_size, uint8_t *output_buffer, size_t output_size, 

Re: [pulseaudio-discuss] R: New equalizer module (module-eqpro-sink), some questions

[Tanu Kaskinen]

On Fri, 2019-04-19 at 12:03 +0200, Georg Chini wrote:
> On 19.04.19 11:13, Tanu Kaskinen wrote:
> > On Tue, 2019-04-16 at 21:40 +0200, Georg Chini wrote:
> > > On 16.04.19 19:19, Tanu Kaskinen wrote:
> > > > On Thu, 2019-04-11 at 20:42 +0200, Georg Chini wrote:
> > > > > On 11.04.19 19:36, Tanu Kaskinen wrote:
> > > > > > If you want a better plugin standard, are you aware of LV2
> > > > > > and PipeWire's SPA (the latter doesn't seem to be properly 
> > > > > > documented
> > > > > > yet, but to my understanding it's supposed to have a stable and
> > > > > > flexible API)?
> > > > > Arun already suggested the pipewire SPA. I took a look, but it
> > > > > seems not very simple compared to LADSPA. I could not really
> > > > > understand how it works and it appears to support a lot more
> > > > > than just filters.
> > > > LV2 would also be an option, although it too is pretty complex compared
> > > > to LADSPA. But at least it's documented and has examples.
> > > I just took a look and on the first glance LV2 seems similar
> > > to LADSPA. I have to dig into the details though, maybe control
> > > arrays and interleaved audio ports are possible there.
> > I'm pretty sure they are possible, but neither of those features are
> > necessary. If the plugin gets the number of bands during the
> > initialization, it can create the appropriate number of non-array
> > control ports. Interleaved audio ports aren't needed either, because
> > PulseAudio can do the deinterleaving before passing the audio to the
> > plugin (like module-ladspa-sink already does). If one's going to write
> > an LV2 plugin, it's best to use standard port types so that all hosts
> > will be able to use the plugin.
> 
> The problem here is that the number of ports must be known before
> the initialization because it is something which is already provided by
> the plugin descriptor. So there seems to be no way to change that
> number dynamically unless I misread the documentation. But looking
> at the LV2 standard, it supplies the port type lv2:CVPort (see
> https://gitlab.com/lv2/lv2/blob/master/lv2/core/lv2core.ttl, line 256)
> which is what I have been looking for if I read the documentation
> right.

I don't think CVPorts are relevant for this discussion. As far as I can
tell, they just provide a different kind of control port, one that can
use audio signal as input. You wanted a port that can take an array of
values, CVPorts isn't that.

You seem to be right about the requirement to declare all ports in
advance. I thought dynamic ports would be the primary benefit of using
LV2 rather than creating a custom API based on LADSPA.

> Concerning interleaved audio format: Up to now I found nothing
> that explicitly forbids interleaved audio though it appears that the
> plugins usually provide one audio port per channel.

You can't use a plain AudioPort for interleaved audio, because hosts
will assume that it operates with mono audio. You can probably define a
subclass of AudioPort with different semantics, but then hosts other
than PulseAudio won't be able to use the plugin (unless they adopt your
extension).

> PA can surely deinterleave the input and interleave the output
> but to me it looks like completely unnecessary copying around
> of buffers within a real time thread. With interleaved channels,
> you could directly pass the input and output buffers. Why should
> we copy the data twice if it can be avoided? Additionally, using
> one port per channel makes it impossible to adapt the number
> of channels dynamically when loading the plugin for the reason
> given above.

The reason I suggested deinterleaving in PulseAudio was to allow the
plugin to be compatible with other hosts. Without native support for
dynamic ports in LV2, such compatibility seems to be hard/impossible to
achieve, however.

As for dynamically changing channels, I don't see the use case for
that.

> > > > > > You say that your extension allows full integration of Andrea's
> > > > > > equalizer, but I don't see how it allows the host to tell the plugin
> > > > > > how many channels and how many frequency bands it should initialize.
> > > > > For an interleaved audio port, there would be another control
> > > > > port which holds the number of (interleaved) channels. So
> > > > > this port would allow you to change the number of channels.
> > > > > You could for example have an audio port named "Input"
> > > > > and a control port "Number of input channels". Then the
> 

Re: [pulseaudio-discuss] [PATCH v8 07/12] bluetooth: Add A2DP aptX and aptX HD codecs support

[Tanu Kaskinen]

On Fri, 2019-04-19 at 12:52 +0200, Pali Rohár wrote:
> On Friday 19 April 2019 11:41:22 Tanu Kaskinen wrote:
> > On Sat, 2019-04-06 at 11:16 +0200, Pali Rohár wrote:
> > > +static size_t decode_buffer(void *codec_info, const uint8_t 
> > > *input_buffer, size_t input_size, uint8_t *output_buffer, size_t 
> > > output_size, size_t *processed) {
> > > +struct aptx_context *aptx_c = (struct aptx_context *) codec_info;
> > > +
> > > +const uint8_t *p;
> > > +uint8_t *d;
> > > +size_t to_write, to_decode;
> > > +
> > > +p = input_buffer;
> > > +to_decode = input_size;
> > > +
> > > +d = output_buffer;
> > > +to_write = output_size;
> > > +
> > > +while (PA_LIKELY(to_decode > 0)) {
> > 
> > Is it intentional that encode_buffer() checks both to_encode and
> > to_write in the while loop condition, but decode_buffer() only checks
> > to_decode? If so, why does encode_buffer() need to be extra careful but
> > decode_buffer() doesn't?
> 
> These checks are similar/same as in SBC codec code. And SBC code was
> there prior to my work. So personally I do not know.

Ok, let's find out if this code needs changing.

The output buffer size when decoding is determined by
get_read_block_size(), which returns a value corresponding to the read
MTU (the MTU is in the compressed domain, the block size is in the
uncompressed domain).

The input buffer size is potentially up to twice the read MTU.

It doesn't seem impossible that the socket could have more data queued
than just one MTU. Therefore this doesn't seem safe, because
decode_buffer() may overrun the output buffer. The solution isn't to
check to_write, however, because that would lead to some audio getting
dropped. I think the input buffer size should be limited to roughly one
MTU just like the output buffer size is limited to roughly one MTU. The
exact logic is codec dependent, so the codec implementation should
decide both the input and output buffer sizes, and it should be ensured
that the output buffer is big enough to fully decode a full input
buffer.

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

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

Re: [pulseaudio-discuss] License problem: LDAC codec & pulseaudio

[Tanu Kaskinen]

On Fri, 2019-04-19 at 00:17 +0200, Pali Rohár wrote:
> On Saturday 23 February 2019 17:59:57 Tanu Kaskinen wrote:
> > On Sat, 2019-02-23 at 16:06 +0100, Pali Rohár wrote:
> > > Hello,
> > > 
> > > I would like to discuss about licence problems with usage of LDAC
> > > encoder libldac in pulseaudio. LDAC is a codec used by some Sony
> > > bluetooth headsets and it would be nice to have support for it after my
> > > patch series for Modular API for A2DP codecs is merged.
> > > 
> > > There is only one released LDAC encoder. It is libldac which can be
> > > found at: https://android.googlesource.com/platform/external/libldac/
> > > It is licensed under Apache License Version 2.0.
> > > 
> > > If I understood correctly pulseaudio is licensed under LGPL v2.1 or
> > > later with some exceptions when some optional GPL dependences are
> > > enabled then server part is licensed under GPL v2 or later. So it can be
> > > distributed under GPL v3, right? Please correct me if I'm wrong.
> > > 
> > > According to FSF https://www.gnu.org/licenses/license-list.html#apache2
> > > Apache License Version 2.0 is compatible with GPL v3, but is
> > > incompatible with GPL v2.
> > > 
> > > So, would it be feasible to write LDAC specific code for pulseaudio
> > > under GPL v3 license (in separate files) and make compile time option to
> > > enable/disable GPL v3 LDAC support? When enabled it would mean that
> > > compiled binary of puleaudio server and server modules are forced to be
> > > distributed under GPL v3 and thanks to compatibility with Apache License
> > > Version 2.0, it would be possible to use libdac library. When disabled
> > > then it would be like before (without LDAC and with license like
> > > before). Am I correct?
> > 
> > Yes, I believe you're correct, and at least I am fine with adding LDAC
> > support via libldac.
> 
> I asked people in SUSE and I got answer that it should be ok if there is
> no GPLv2-only code. So has pulseaudio some GPLv2-only code or is all code
> compatible with GPLv3 (i.e. GPLv2-or-later)?

PulseAudio doesn't have any GPL code, but it has optional GPL
dependencies, all of which seem to be either GPLv2-or-later or GPLv3-
or-later (gdbm is the one that is nowadays licensed under GPLv3). The
LICENSE file could be more clear on these details...

You suggested writing LDAC specific code under GPLv3, but since
LGPLv2.1-or-later is convertible to GPLv3, I think the LDAC code should
be under LGPLv2.1-or-later like the rest of the code base.

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

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

Re: [pulseaudio-discuss] R: New equalizer module (module-eqpro-sink), some questions

[Tanu Kaskinen]

On Tue, 2019-04-16 at 21:40 +0200, Georg Chini wrote:
> On 16.04.19 19:19, Tanu Kaskinen wrote:
> > On Thu, 2019-04-11 at 20:42 +0200, Georg Chini wrote:
> > > On 11.04.19 19:36, Tanu Kaskinen wrote:
> > > > If you want a better plugin standard, are you aware of LV2
> > > > and PipeWire's SPA (the latter doesn't seem to be properly documented
> > > > yet, but to my understanding it's supposed to have a stable and
> > > > flexible API)?
> > > Arun already suggested the pipewire SPA. I took a look, but it
> > > seems not very simple compared to LADSPA. I could not really
> > > understand how it works and it appears to support a lot more
> > > than just filters.
> > LV2 would also be an option, although it too is pretty complex compared
> > to LADSPA. But at least it's documented and has examples.
> 
> I just took a look and on the first glance LV2 seems similar
> to LADSPA. I have to dig into the details though, maybe control
> arrays and interleaved audio ports are possible there.

I'm pretty sure they are possible, but neither of those features are
necessary. If the plugin gets the number of bands during the
initialization, it can create the appropriate number of non-array
control ports. Interleaved audio ports aren't needed either, because
PulseAudio can do the deinterleaving before passing the audio to the
plugin (like module-ladspa-sink already does). If one's going to write
an LV2 plugin, it's best to use standard port types so that all hosts
will be able to use the plugin.

> > > > You say that your extension allows full integration of Andrea's
> > > > equalizer, but I don't see how it allows the host to tell the plugin
> > > > how many channels and how many frequency bands it should initialize.
> > > For an interleaved audio port, there would be another control
> > > port which holds the number of (interleaved) channels. So
> > > this port would allow you to change the number of channels.
> > > You could for example have an audio port named "Input"
> > > and a control port "Number of input channels". Then the
> > > get_info_port() function would return the index of the
> > > "Number of input channels" control when called with the
> > > "Input" port as argument. Or the other way round: If you
> > > set "Number of input channels"  to 6 the plugin will expect
> > > 6 channels in the interleaved audio port (and you know
> > > which control port sets the number of channels because
> > > you can get it via the get_info_port() function.
> > > 
> > > The same applies to the number of bands. There must be a
> > > control port which reflects the number of elements in the
> > > control array which is the same as the number of bands.
> > > 
> > > Both values can be set to convenient defaults if the host does
> > > not supply them (like 5 bands and 2 channels).
> > Ok, so the idea is to do the configuration while the filter is running.
> > I think it would be better to do the configuration in the plugin setup
> > phase. I imagine that would simplify the control port allocoation and
> > management, since the setup doesn't have to run in the IO thread where
> > malloc() is not allowed. I don't see much benefit in doing this kind of
> > configuration while the filter is running, since the filter state most
> > likely has to be reset anyway when the number of EQ bands is changed.
> > 
> > There could be a function for getting a description of what options the
> > plugin accepts, and a setup function for setting the options.
> > 
> Why do you think that the filter must be configured while it is
> running? In case of the equalizer the number of channels and
> also the number of bands are known before the filter is run.
> The LADSPA standard says all control ports must be connected
> (and valid) before you can run the filter. If a parameter changes
> at runtime, the filter must be reset like the current ladspa-sink
> does.

Control ports are used for realtime parameter changes, so that's why I
thought the intention was to set the parameters while the filter is
running. I think it would be much clearer and easier to document the
expected host behaviour if the parameter configuration was not
implemented via control ports.

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

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

Re: [pulseaudio-discuss] [PATCH v8 07/12] bluetooth: Add A2DP aptX and aptX HD codecs support

[Tanu Kaskinen]

On Sat, 2019-04-06 at 11:16 +0200, Pali Rohár wrote:
> This patch provides support for aptX and aptX HD codecs in bluetooth A2DP
> profile. It uses open source LGPLv2.1+ licensed libopenaptx library which
> can be found at https://github.com/pali/libopenaptx.
> 
> aptX for s24 stereo samples provides fixed 6:1 compression ratio and
> bitrate 352.8 kbit/s, aptX HD provides fixed 4:1 compression ratio and
> bitrate 529.2 kbit/s.
> 
> According to soundexpert research, aptX codec used in bluetooth A2DP is no
> better than SBC High Quality settings. And you cannot hear difference
> between aptX and SBC High Quality, 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).
> 
> http://soundexpert.org/news/-/blogs/audio-quality-of-bluetooth-aptx
> ---
>  configure.ac|  36 +++
>  src/Makefile.am |   6 +
>  src/modules/bluetooth/a2dp-codec-aptx.c | 445 
> 
>  src/modules/bluetooth/a2dp-codec-util.c |   8 +
>  4 files changed, 495 insertions(+)
>  create mode 100644 src/modules/bluetooth/a2dp-codec-aptx.c

> +static bool can_accept_capabilities_common(const a2dp_aptx_t *capabilities, 
> uint32_t vendor_id, uint16_t codec_id) {
> +if (!(capabilities->frequency & (APTX_SAMPLING_FREQ_16000 | 
> APTX_SAMPLING_FREQ_32000 |
> + APTX_SAMPLING_FREQ_44100 | 
> APTX_SAMPLING_FREQ_48000)))
> +return false;
> +
> +if (A2DP_GET_VENDOR_ID(capabilities->info) != vendor_id || 
> A2DP_GET_CODEC_ID(capabilities->info) != codec_id)
> +return false;
> +
> +if (!(capabilities->channel_mode & APTX_CHANNEL_MODE_STEREO))

Why is mono support not implemented? Is it a limitation of libopenaptx?
It's not a big shortcoming, but it would be nice to support mono too.

> +static size_t decode_buffer(void *codec_info, const uint8_t *input_buffer, 
> size_t input_size, uint8_t *output_buffer, size_t output_size, size_t 
> *processed) {
> +struct aptx_context *aptx_c = (struct aptx_context *) codec_info;
> +
> +const uint8_t *p;
> +uint8_t *d;
> +size_t to_write, to_decode;
> +
> +p = input_buffer;
> +to_decode = input_size;
> +
> +d = output_buffer;
> +to_write = output_size;
> +
> +while (PA_LIKELY(to_decode > 0)) {

Is it intentional that encode_buffer() checks both to_encode and
to_write in the while loop condition, but decode_buffer() only checks
to_decode? If so, why does encode_buffer() need to be extra careful but
decode_buffer() doesn't?

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

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

Re: [pulseaudio-discuss] R: New equalizer module (module-eqpro-sink), some questions

[Tanu Kaskinen]

On Thu, 2019-04-11 at 20:42 +0200, Georg Chini wrote:
> On 11.04.19 19:36, Tanu Kaskinen wrote:
> > On Thu, 2019-04-11 at 15:16 +0200, Georg Chini wrote:
> > > On 08.04.19 09:27, Georg Chini wrote:
> > > > On 05.04.19 13:29, Tanu Kaskinen wrote:
> > > > > On Tue, 2019-04-02 at 20:28 +0200, Georg Chini wrote:
> > > > > > On 06.11.18 22:14, Andrea A wrote:
> > > > > > Hi Andrea,
> > > > > > 
> > > > > > 
> > > > > > maybe there is a chance now to have your equalizer included as a
> > > > > > module.
> > > > > > The messaging API patches
> > > > > > should have their final form (at least I do not think the public
> > > > > > functions will change anymore) and today
> > > > > > I submitted a patch series that consolidates the code of the current
> > > > > > virtual sinks and moves the common
> > > > > > code to a separate file. Using the common code should significantly
> > > > > > reduce the maintenance cost of an
> > > > > > additional sink.
> > > > > > 
> > > > > > So if you are still interested to have it included, at least I would
> > > > > > welcome a new patch.
> > > > > > 
> > > > > > 
> > > > > > Arun, Tanu, what do you think?
> > > > > I think it would anyway make sense to make one or more LADSPA plugins
> > > > > out of the equalizer code (I say one or more, because of the lack of
> > > > > parametrization support in LADSPA). That way the equalizer would be
> > > > > available also to other software than just PulseAudio (I'm thinking
> > > > > PipeWire in particular).
> > > > > 
> > > > > If a suitable LADSPA plugin existed, we might or might not still need 
> > > > > a
> > > > > separate equalizer module, but in any case we wouldn't need to 
> > > > > maintain
> > > > > the DSP code in PulseAudio. If there's some reason why module-ladspa-
> > > > > sink isn't (and can't become) suitable for implementing the 
> > > > > integration
> > > > > in PulseAudio, then a specialized module is fine.
> > > > > 
> > > > > I'm not saying that I'm dead against hosting the DSP code in
> > > > > PulseAudio, but I'd certainly prefer not to.
> > > > > 
> > > > It surely would make sense to have one or several  LADSPA
> > > > plugins, but for me a good equalizer should be an integral
> > > > part of pulseaudio. And as you say yourself, the full flexibility
> > > > cannot be achieved by a single LADSPA plugin. The equalizer
> > > > we are currently providing is buggy and completely unsupported.
> > > > The new equalizer would at least be fully documented, so that
> > > > it is possible to maintain. Additionally I agree with Andrea that
> > > > handling LADSPA plugins is somewhat cumbersome. From a
> > > > user point of view, a module is much easier to handle.
> > > I have taken a more detailed look on the LADSPA standard and
> > > to me it appears like you would not only need different plugins for
> > > different numbers of equalizer channels but in addition also
> > > for different number of audio channels. Both, the number of
> > > single-value parameters and number of input-/output-channels
> > > seem to be fixed, so producing a bunch of plugins is rather
> > > impractical.
> > An equalizer plugin doesn't need multiple channels, one mono plugin can
> > be instantiated for each channel. Or does this equalizer have some
> > cross-channel effects?
> 
> You are right, that would not be necessary. Only some plugin
> that does up- or down-mixing of channels would need that.
> 
> > > I wonder if there is a chance to extend the standard a bit to
> > > allow a variable number of audio channels and allow control
> > > ports to be arrays. It can be done with two more constants and
> > > one additional function, see attached diff. This extension would
> > > allow to reduce many of our virtual sinks to one plugin-sink and
> > > also allow full integration of Andrea's equalizer.
> > Do you have in mind actually extending the LADSPA standard (i.e.
> > something to be promoted to other projects as well), or just creating a
> > new custom (i.e. non-standard) plugin API for PulseAudio that is based
>

Re: [pulseaudio-discuss] [PATCH v8 03/12] bluetooth: Modular API for A2DP codecs

[Tanu Kaskinen]

On Fri, 2019-04-12 at 14:29 +0200, Pali Rohár wrote:
> On Friday 12 April 2019 15:22:20 Tanu Kaskinen wrote:
> > On Sat, 2019-04-06 at 11:15 +0200, Pali Rohár wrote:
> > > This patch introduce new modular API for bluetooth A2DP codecs. Its
> > > benefits are:
> > > 
> > > * bluez5-util and module-bluez5-device does not contain any codec specific
> > >   code, they are codec independent.
> > > 
> > > * For adding new A2DP codec it is needed just to adjust one table in
> > >   a2dp-codec-util.c file. All codec specific functions are in separate
> > >   codec file.
> > > 
> > > * Support for backchannel (microphone voice). Some A2DP codecs (like
> > >   FastStream or aptX Low Latency) are bi-directional and can be used for
> > >   both music playback and audio call.
> > > 
> > > * Support for more configurations per codec. This allows to implement low
> > >   quality mode of some codec together with high quality.
> > > 
> > > Current SBC codec implementation was moved from bluez5-util and
> > > module-bluez5-device to its own file and converted to this new A2DP API.
> > > ---
> > >  src/Makefile.am  |  12 +-
> > >  src/modules/bluetooth/a2dp-codec-api.h   |  95 
> > >  src/modules/bluetooth/a2dp-codec-sbc.c   | 638 
> > > +++
> > >  src/modules/bluetooth/a2dp-codec-util.c  |  56 +++
> > >  src/modules/bluetooth/a2dp-codec-util.h  |  34 ++
> > >  src/modules/bluetooth/bluez5-util.c  | 347 +--
> > >  src/modules/bluetooth/bluez5-util.h  |   5 +
> > >  src/modules/bluetooth/module-bluez5-device.c | 562 
> > > ---
> > >  8 files changed, 1127 insertions(+), 622 deletions(-)
> > >  create mode 100644 src/modules/bluetooth/a2dp-codec-api.h
> > >  create mode 100644 src/modules/bluetooth/a2dp-codec-sbc.c
> > >  create mode 100644 src/modules/bluetooth/a2dp-codec-util.c
> > >  create mode 100644 src/modules/bluetooth/a2dp-codec-util.h
> > 
> > Looks good! Just one small thing: there are still a couple of places in
> > a2dp-codec-sbc.c where 254 is used instead of MAX_A2DP_CAPS_SIZE. No
> > need to resubmit just because of that, I can fix that up myself.
> 
> Ok.
> 
> > I pushed the first 6 patches now, I'll continue reviewing the rest next
> > week.
> 
> Thank you!

The Meson build system broke with the patches that I pushed (now
fixed), can you make sure that the rest of the patches build also with
Meson?

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

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

Re: [pulseaudio-discuss] [PATCH v8 03/12] bluetooth: Modular API for A2DP codecs

[Tanu Kaskinen]

On Sat, 2019-04-06 at 11:15 +0200, Pali Rohár wrote:
> This patch introduce new modular API for bluetooth A2DP codecs. Its
> benefits are:
> 
> * bluez5-util and module-bluez5-device does not contain any codec specific
>   code, they are codec independent.
> 
> * For adding new A2DP codec it is needed just to adjust one table in
>   a2dp-codec-util.c file. All codec specific functions are in separate
>   codec file.
> 
> * Support for backchannel (microphone voice). Some A2DP codecs (like
>   FastStream or aptX Low Latency) are bi-directional and can be used for
>   both music playback and audio call.
> 
> * Support for more configurations per codec. This allows to implement low
>   quality mode of some codec together with high quality.
> 
> Current SBC codec implementation was moved from bluez5-util and
> module-bluez5-device to its own file and converted to this new A2DP API.
> ---
>  src/Makefile.am  |  12 +-
>  src/modules/bluetooth/a2dp-codec-api.h   |  95 
>  src/modules/bluetooth/a2dp-codec-sbc.c   | 638 
> +++
>  src/modules/bluetooth/a2dp-codec-util.c  |  56 +++
>  src/modules/bluetooth/a2dp-codec-util.h  |  34 ++
>  src/modules/bluetooth/bluez5-util.c  | 347 +--
>  src/modules/bluetooth/bluez5-util.h  |   5 +
>  src/modules/bluetooth/module-bluez5-device.c | 562 ---
>  8 files changed, 1127 insertions(+), 622 deletions(-)
>  create mode 100644 src/modules/bluetooth/a2dp-codec-api.h
>  create mode 100644 src/modules/bluetooth/a2dp-codec-sbc.c
>  create mode 100644 src/modules/bluetooth/a2dp-codec-util.c
>  create mode 100644 src/modules/bluetooth/a2dp-codec-util.h

Looks good! Just one small thing: there are still a couple of places in
a2dp-codec-sbc.c where 254 is used instead of MAX_A2DP_CAPS_SIZE. No
need to resubmit just because of that, I can fix that up myself.

I pushed the first 6 patches now, I'll continue reviewing the rest next
week.

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

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

Re: [pulseaudio-discuss] R: New equalizer module (module-eqpro-sink), some questions

[Tanu Kaskinen]

On Thu, 2019-04-11 at 15:16 +0200, Georg Chini wrote:
> On 08.04.19 09:27, Georg Chini wrote:
> > On 05.04.19 13:29, Tanu Kaskinen wrote:
> > > On Tue, 2019-04-02 at 20:28 +0200, Georg Chini wrote:
> > > > On 06.11.18 22:14, Andrea A wrote:
> > > > > Thanks a lot for the reply
> > > > > 
> > > > > > If the preset files are expected to be shared between users, then 
> > > > > > the
> > > > > database.h stuff isn't good, because different users can have their
> > > > > pulseaudio configured with different database formats. I like the 
> > > > > "ini-
> > > > > style" configuration file style that pulseaudio uses for .conf files.
> > > > > There are no helpers for writing those files, though, but that's
> > > > > probably not a big issue.
> > > > > 
> > > > > I can write a parser for ini-style file however since PA is
> > > > > multiplatform I need some information about how to store user and
> > > > > system settings. System settings can be hardcoded at least, but the
> > > > > directory of user config depends on the platform I think.
> > > > > 
> > > > > > Iwould love to have the equalizer as a LADSPA plugin
> > > > > My fear is that a LADSPA plugin will be too hard to use for a lot of
> > > > > desktop users. I think that a GNU desktop user would like to have a
> > > > > fully working audio equalizer in his distribution and PA is default in
> > > > > almost all GNU distributions. Configuring a LADSPA plugin may be hard
> > > > > and boring for the average user and GNU will continue to don't have a
> > > > > standard equalizer. Beyond the issues you've already listed.
> > > > > 
> > > > > > It's not very uncommon that some core
> > > > > change requires changes in all sinks, so even if the module is perfect
> > > > > and doesn't require maintenance in form of bug fixes, there are other
> > > > > kinds of real maintenance costs.
> > > > > 
> > > > > As far as I know the actual equalizer is deprecated so if this mine
> > > > > equalizer will be adequate I think that the actual can be substitute
> > > > > and the number of modules to maintain will not change.
> > > > > 
> > > > > Andrea993
> > > > > 
> > > > > 
> > > > Hi Andrea,
> > > > 
> > > > 
> > > > maybe there is a chance now to have your equalizer included as a 
> > > > module.
> > > > The messaging API patches
> > > > should have their final form (at least I do not think the public
> > > > functions will change anymore) and today
> > > > I submitted a patch series that consolidates the code of the current
> > > > virtual sinks and moves the common
> > > > code to a separate file. Using the common code should significantly
> > > > reduce the maintenance cost of an
> > > > additional sink.
> > > > 
> > > > So if you are still interested to have it included, at least I would
> > > > welcome a new patch.
> > > > 
> > > > 
> > > > Arun, Tanu, what do you think?
> > > I think it would anyway make sense to make one or more LADSPA plugins
> > > out of the equalizer code (I say one or more, because of the lack of
> > > parametrization support in LADSPA). That way the equalizer would be
> > > available also to other software than just PulseAudio (I'm thinking
> > > PipeWire in particular).
> > > 
> > > If a suitable LADSPA plugin existed, we might or might not still need a
> > > separate equalizer module, but in any case we wouldn't need to maintain
> > > the DSP code in PulseAudio. If there's some reason why module-ladspa-
> > > sink isn't (and can't become) suitable for implementing the integration
> > > in PulseAudio, then a specialized module is fine.
> > > 
> > > I'm not saying that I'm dead against hosting the DSP code in
> > > PulseAudio, but I'd certainly prefer not to.
> > > 
> > It surely would make sense to have one or several  LADSPA
> > plugins, but for me a good equalizer should be an integral
> > part of pulseaudio. And as you say yourself, the full flexibility
> > cannot be achieved by a single LADSPA plugin. The equalizer
> > we are currently providing is buggy and completel

Re: [pulseaudio-discuss] [PATCH v7 04/13] bluetooth: Modular API for A2DP codecs

[Tanu Kaskinen]

On Fri, 2019-04-05 at 12:36 +0200, Pali Rohár wrote:
> On Thursday 04 April 2019 18:19:32 Tanu Kaskinen wrote:
> > On Sat, 2019-02-23 at 10:45 +0100, Pali Rohár wrote:
> > > +
> > > +/* Initialize codec, returns codec info data and set sample_spec, 
> > > for_encoding is true when codec_info is used for encoding, 
> > > for_backchannel is true when codec_info is used for backchannel */
> > > +void *(*init_codec)(bool for_encoding, bool for_backchannel, const 
> > > uint8_t *config_buffer, uint8_t config_size, pa_sample_spec *sample_spec);
> > 
> > In order to be more consistent with other abstraction structs, I'd like
> > to add a void pointer variable called "userdata" to pa_a2dp_codec.
> 
> This is not possible. Instances of pa_a2dp_codec struct are statically
> defined directly in implementation of codec and are constant. So you
> cannot put there some dynamic data, like user pointers. See e.g.
> pa_a2dp_codec_aptx_hd how it is used.

I was going to say that we could just drop the const declaration, but
since it's possible to use two bluetooth devices simultaneously, the
fact that there's only one instance of each codec prevents adding any
state to the structs.

I think it would be better to allocate the codec structs dynamically so
that the codecs could store their own state rather than requiring
module-bluez5-device.c to do that, but I don't want to block the patch
series on this issue, so I guess we'll keep the code as it is.

> > > diff --git a/src/modules/bluetooth/bluez5-util.c 
> > > b/src/modules/bluetooth/bluez5-util.c
> > > index 485a57515..e4450cfe3 100644
> > > --- a/src/modules/bluetooth/bluez5-util.c
> > > +++ b/src/modules/bluetooth/bluez5-util.c
> > > @@ -950,6 +943,7 @@ static void 
> > > parse_interfaces_and_properties(pa_bluetooth_discovery *y, DBusMessa
> > >  
> > >  if (pa_streq(interface, BLUEZ_ADAPTER_INTERFACE)) {
> > >  pa_bluetooth_adapter *a;
> > > +unsigned a2dp_codec_i, a2dp_codec_count;
> > 
> > The a2dp_codec_count variable doesn't have much value, since it's used
> > only once and can be replaced with the pa_bluetooth_a2dp_codec_count()
> > call.
> 
> This is prevention to be called this external function N times. It is
> used as condition in for() loop and if I replace it on that place like
> you wrote it would be called every iteration of loop. Function is cannot
> be inlined as it is defined in .c file.

a2dp_codec_count is only used in the initialization part of the for
loop, so it's not used every iteration.

> > > @@ -911,11 +782,6 @@ static void setup_stream(struct userdata *u) {
> > >  
> > >  pa_log_debug("Stream properly set up, we're ready to roll!");
> > >  
> > > -if (u->profile == PA_BLUETOOTH_PROFILE_A2DP_SINK) {
> > > -a2dp_set_bitpool(u, u->sbc_info.max_bitpool);
> > 
> > It looks like resetting the bitpool isn't done anywhere. Should it be
> > done in the reset_codec() callback?
> 
> reset_codec() for SBC calls set_params() and it resets sbc.bitpool to
> default value. So reset_codec() calls resets bitpool.

Ah, so sbc_info.bitpool is the default bitpool value which is not
changed when the bitpool is reduced. Could the variable be renamed to
default_bitpool or initial_bitpool?

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

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

Re: [pulseaudio-discuss] R: New equalizer module (module-eqpro-sink), some questions

[Tanu Kaskinen]

On Tue, 2019-04-02 at 20:28 +0200, Georg Chini wrote:
> On 06.11.18 22:14, Andrea A wrote:
> > Thanks a lot for the reply
> > 
> > > If the preset files are expected to be shared between users, then the
> > database.h stuff isn't good, because different users can have their
> > pulseaudio configured with different database formats. I like the "ini-
> > style" configuration file style that pulseaudio uses for .conf files.
> > There are no helpers for writing those files, though, but that's
> > probably not a big issue.
> > 
> > I can write a parser for ini-style file however since PA is 
> > multiplatform I need some information about how to store user and 
> > system settings. System settings can be hardcoded at least, but the 
> > directory of user config depends on the platform I think.
> > 
> > > Iwould love to have the equalizer as a LADSPA plugin
> > 
> > My fear is that a LADSPA plugin will be too hard to use for a lot of 
> > desktop users. I think that a GNU desktop user would like to have a 
> > fully working audio equalizer in his distribution and PA is default in 
> > almost all GNU distributions. Configuring a LADSPA plugin may be hard 
> > and boring for the average user and GNU will continue to don't have a 
> > standard equalizer. Beyond the issues you've already listed.
> > 
> > > It's not very uncommon that some core
> > change requires changes in all sinks, so even if the module is perfect
> > and doesn't require maintenance in form of bug fixes, there are other
> > kinds of real maintenance costs.
> > 
> > As far as I know the actual equalizer is deprecated so if this mine 
> > equalizer will be adequate I think that the actual can be substitute 
> > and the number of modules to maintain will not change.
> > 
> > Andrea993
> > 
> > 
> 
> Hi Andrea,
> 
> 
> maybe there is a chance now to have your equalizer included as a module. 
> The messaging API patches
> should have their final form (at least I do not think the public 
> functions will change anymore) and today
> I submitted a patch series that consolidates the code of the current 
> virtual sinks and moves the common
> code to a separate file. Using the common code should significantly 
> reduce the maintenance cost of an
> additional sink.
> 
> So if you are still interested to have it included, at least I would 
> welcome a new patch.
> 
> 
> Arun, Tanu, what do you think?

I think it would anyway make sense to make one or more LADSPA plugins
out of the equalizer code (I say one or more, because of the lack of
parametrization support in LADSPA). That way the equalizer would be
available also to other software than just PulseAudio (I'm thinking
PipeWire in particular).

If a suitable LADSPA plugin existed, we might or might not still need a
separate equalizer module, but in any case we wouldn't need to maintain
the DSP code in PulseAudio. If there's some reason why module-ladspa-
sink isn't (and can't become) suitable for implementing the integration
in PulseAudio, then a specialized module is fine.

I'm not saying that I'm dead against hosting the DSP code in
PulseAudio, but I'd certainly prefer not to.

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

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

Re: [pulseaudio-discuss] [PATCH v7 04/13] bluetooth: Modular API for A2DP codecs

[Tanu Kaskinen]

On Sat, 2019-02-23 at 10:45 +0100, Pali Rohár wrote:
> This patch introduce new modular API for bluetooth A2DP codecs. Its
> benefits are:
> 
> * bluez5-util and module-bluez5-device does not contain any codec specific
>   code, they are codec independent.
> 
> * For adding new A2DP codec it is needed just to adjust one table in
>   a2dp-codec-util.c file. All codec specific functions are in separate
>   codec file.
> 
> * Support for backchannel (microphone voice). Some A2DP codecs (like
>   FastStream or aptX Low Latency) are bi-directional and can be used for
>   both music playback and audio call.
> 
> * Support for more configurations per codec. This allows to implement low
>   quality mode of some codec together with high quality.
> 
> Current SBC codec implementation was moved from bluez5-util and
> module-bluez5-device to its own file and converted to this new A2DP API.
> ---
>  src/Makefile.am  |  12 +-
>  src/modules/bluetooth/a2dp-codec-api.h   |  80 
>  src/modules/bluetooth/a2dp-codec-sbc.c   | 638 
> +++
>  src/modules/bluetooth/a2dp-codec-util.c  |  56 +++
>  src/modules/bluetooth/a2dp-codec-util.h  |  34 ++
>  src/modules/bluetooth/bluez5-util.c  | 348 +--
>  src/modules/bluetooth/bluez5-util.h  |   5 +
>  src/modules/bluetooth/module-bluez5-device.c | 563 ---
>  8 files changed, 1119 insertions(+), 617 deletions(-)
>  create mode 100644 src/modules/bluetooth/a2dp-codec-api.h
>  create mode 100644 src/modules/bluetooth/a2dp-codec-sbc.c
>  create mode 100644 src/modules/bluetooth/a2dp-codec-util.c
>  create mode 100644 src/modules/bluetooth/a2dp-codec-util.h
> 
> diff --git a/src/Makefile.am b/src/Makefile.am
> index 89f532278..5ef870e32 100644
> --- a/src/Makefile.am
> +++ b/src/Makefile.am
> @@ -2131,6 +2131,9 @@ 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/a2dp-codec-api.h \
> + modules/bluetooth/a2dp-codec-util.c \
> + modules/bluetooth/a2dp-codec-util.h \
>   modules/bluetooth/a2dp-codecs.h \
>   modules/bluetooth/rtp.h
>  if HAVE_BLUEZ_5_OFONO_HEADSET
> @@ -2145,6 +2148,11 @@ endif
>  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_CPPFLAGS = $(AM_CPPFLAGS)
> +
> +libbluez5_util_la_SOURCES += modules/bluetooth/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)
> @@ -2153,8 +2161,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-codec-api.h 
> b/src/modules/bluetooth/a2dp-codec-api.h
> new file mode 100644
> index 0..d9cc1a58e
> --- /dev/null
> +++ b/src/modules/bluetooth/a2dp-codec-api.h
> @@ -0,0 +1,80 @@
> +#ifndef fooa2dpcodechfoo
> +#define fooa2dpcodechfoo
> +
> +/***
> +  This file is part of PulseAudio.
> +
> +  Copyright 2018-2019 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
> +  published by the Free Software Foundation; either version 2.1 of the
> +  License, or (at your option) any later version.
> +
> +  PulseAudio is distributed in the hope that it will be useful, but
> +  WITHOUT ANY WARRANTY; without even the implied warranty of
> +  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> +  General Public License for more details.
> +
> +  You should have received a copy of the GNU Lesser General Public
> +  License along with PulseAudio; if not, see ;.
> +***/
> +
> +#include 
> +
> +typedef struct pa_a2dp_codec_capabilities {
> +uint8_t size;
> +uint8_t buffer[]; /* max size is 254 bytes */
> +} pa_a2dp_codec_capabilities;
> +
> +typedef struct pa_a2dp_codec_id {
> +uint8_t codec_id;
> +uint32_t vendor_id;
> +uint16_t vendor_codec_id;
> +} 

Re: [pulseaudio-discuss] [PATCH 1/3] alsa: fix infinite loop with Intel HDMI LPE

[Tanu Kaskinen]

On Tue, 2019-03-26 at 13:17 +0800, Hui Wang wrote:
> On 2017/12/28 下午6:09, Tanu Kaskinen wrote:
> > The Intel HDMI LPE driver works in a peculiar way when the HDMI cable is
> > not plugged in: any written audio is immediately discarded and underrun
> > is reported. That resulted in an infinite loop, because PulseAudio tried
> > to keep the buffer filled, which was futile since the written audio was
> > immediately consumed/discarded.
> > 
> > This patch adds special handling for the LPE driver: if the active port
> > of the sink is unavailable, the sink suspends itself. A new suspend
> > cause is added: PA_SUSPEND_UNAVAILABLE.
> > 
> > BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=100488
> > ---
> >  src/modules/alsa/alsa-mixer.h   |  1 +
> >  src/modules/alsa/alsa-sink.c| 22 ++
> >  src/modules/alsa/module-alsa-card.c | 34 ++
> >  src/pulsecore/core.h|  1 +
> >  4 files changed, 58 insertions(+)
> > 
> > diff --git a/src/modules/alsa/alsa-mixer.h b/src/modules/alsa/alsa-mixer.h
> > index 4ebf1922b..3577f435f 100644
> > --- a/src/modules/alsa/alsa-mixer.h
> > +++ b/src/modules/alsa/alsa-mixer.h
> > @@ -364,6 +364,7 @@ int pa_alsa_set_mixer_rtpoll(struct pa_alsa_mixer_pdata 
> > *pd, snd_mixer_t *mixer,
> >  struct pa_alsa_port_data {
> >  pa_alsa_path *path;
> >  pa_alsa_setting *setting;
> > +bool suspend_when_unavailable;
> >  };
> >  
> >  void pa_alsa_add_ports(void *sink_or_source_new_data, pa_alsa_path_set 
> > *ps, pa_card *card);
> > diff --git a/src/modules/alsa/alsa-sink.c b/src/modules/alsa/alsa-sink.c
> > index 7936cfaca..a80caab2e 100644
> > --- a/src/modules/alsa/alsa-sink.c
> > +++ b/src/modules/alsa/alsa-sink.c
> > @@ -1527,6 +1527,11 @@ static int sink_set_port_cb(pa_sink *s, 
> > pa_device_port *p) {
> >  s->set_volume(s);
> >  }
> >  
> > +if (data->suspend_when_unavailable && p->available == PA_AVAILABLE_NO)
> > +pa_sink_suspend(s, true, PA_SUSPEND_UNAVAILABLE);
> > +else
> 
> Hi Tanu,
> 
> We tried to backport this patch to pulseaudio-8.0 (for ubuntu linux
> 16.04),  but after applying this patch, all audio jacks (like headphone,
> line-in/line-out) can't work anymore. If we change the above line as
> below, the problem will disappear.
> 
> else (data->suspend_when_unavailable)
> 
> In theory, if a port is not set suspend_when_unavailable, the port
> should not be changed by this patch. I don't know if it is correct or
> not,  could you please take a look at it?

I don't think your change is correct. This code is run when the sink
changes its port, so there are two ports involved: the old port and the
new one. If the old port caused the sink to be suspended with the
UNAVAILABLE cause, and the new port doesn't require suspending when
it's unavailable, then with your change the sink doesn't get
unsuspended when it should.

In practice your change should be harmless, though, because all ports
on a Intel HDMI LPE card will have the suspend_when_unavailable flag
set, and on other cards the flag is never set.

You didn't specify what the exact problem with headphones etc. is. Is
there an assertion error? I would guess that you're running into this
bug that was introduced by the HDMI LPE fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=104761

Fixing that bug involved rewriting much of the device suspending and
state changing code. I don't know if you want to backport those patches
if your small change seems to make things work well enough, but here's
a list of relevant commits (oldest first, I'm not 100% that this is a
complete list):

3da0de5418b29c90974d0d3e2198c471c39d229f
6ed37aeef28708f8da34a16c7035fa1331fa13cb
d6e39b5e891c767dd42c369d9f118560b8bb24ae
7f201b1fd419b91a226d23ee1e216661ae082dcf
2dff0d6a6a4df2aab6f36212b705489d5af42835
7f09164ed7979210adcdb7674b9d6217fd44ed66
f6fe411b32c0cf5932fb4f169f5288c76bc6923d
0fad369ceb18a8e275e8f74f10f784e0d7476dfb
73b8a57078b94033edf84de2fc0cfbe344c10dcd
b2537a8f38ad71e4dee57263310235abdf2b95a4
ad0616d4c91de52b7cb69e6222efe96961755482
ad15e6e50e737fb55a87bb7def22332f774abce9

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

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

Re: [pulseaudio-discuss] [PATCH v7 00/13] New API for Bluetooth A2DP codecs

[Tanu Kaskinen]

On Sat, 2019-03-23 at 17:05 +0200, Tanu Kaskinen wrote:
> On Fri, 2019-03-22 at 11:44 +0100, Pali Rohár wrote:
> > Hello, may I ask for review of this patch series or at least first 10
> > patches? Patches are now one month old and I have not touched this for
> > that time period. Currently I have this code and details in my head, but
> > chances are that I forgot other details in future and therefore it would
> > be hard to me to again do needed analysis and later do required
> > modifications. Prepare all those changes were time consuming, it took me
> > half of year to evolve into V7 version and probably I would not have
> > time to implement it again in future...
> 
> I'll start reviewing them tomorrow. Sorry to everyone for my inactivity
> lately...

I see Georg gave some comments today in IRC about the first three
patches: patch 1 is not needed, patch 2 looks good and about patch 3
there was some discussion about a seeming mismatch with BlueZ, but that
turned out to not be a problem after all, so patch 3 should be good to
go in as well. I'll continue review from patch 4 then.

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

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

Re: [pulseaudio-discuss] [PATCH v7 00/13] New API for Bluetooth A2DP codecs

[Tanu Kaskinen]

On Fri, 2019-03-22 at 11:44 +0100, Pali Rohár wrote:
> Hello, may I ask for review of this patch series or at least first 10
> patches? Patches are now one month old and I have not touched this for
> that time period. Currently I have this code and details in my head, but
> chances are that I forgot other details in future and therefore it would
> be hard to me to again do needed analysis and later do required
> modifications. Prepare all those changes were time consuming, it took me
> half of year to evolve into V7 version and probably I would not have
> time to implement it again in future...

I'll start reviewing them tomorrow. Sorry to everyone for my inactivity
lately...

-- 
Tanu

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

Re: [pulseaudio-discuss] [ANNOUNCE] pavucontrol 4.0

[Tanu Kaskinen]

On Fri, 2019-03-08 at 19:03 +0200, Tanu Kaskinen wrote:
> On Wed, 2019-03-06 at 11:48 +0100, NicoHood wrote:
> > On 3/5/19 5:12 PM, Tanu Kaskinen wrote:
> > >  * There can now be only one pavucontrol window open at a time.
> > >Trying to start pavucontrol for a second time brings the
> > >first window to foreground.
> > 
> > Hi,
> > This "fix" is really a problem for me:
> > 
> > I have 6 audio sinks with pulseaudio installed in my appartment. I am
> > really happy that I can control each of them via pavucontrol using the
> > PULSE_SERVER environment variable option.
> > 
> > When I need to debug something I usually have more windows of
> > pavucontrol open, for multiple devices. Now this does not work anymore
> > which is super annoying.
> > 
> > My suggestion is to check for the PULSE_SERVER and only have unique
> > windows for each host. So If you want to run pulseaudio for localhost
> > multiple times only one instance is open, but you can still open
> > pavucontrol for other remote destinations (also only one for each host).
> > 
> > If that suggestion is too complicated to implement I would kindly
> > request to revert the recent fix. :S
> 
> We give GLib the application ID (org.pulseaudio.pavucontrol), and GLib
> then implements all the activation magic using that ID. We could append
> the server string to the application ID. I quickly tried setting a
> bogus ID, and that didn't seem to break anything (I noticed that
> running the pavucontrol command for a second time doesn't bring the
> window to foreground on my machine, though, but that doesn't seem to be
> related to the unusual application ID, because reverting back to the
> normal ID doesn't work any better).
> 
> So, I think I'll make a patch that appends the server string to the
> application ID, even though messing with the application ID feels quite
> "wrong".

I submitted a merge request now:
https://gitlab.freedesktop.org/pulseaudio/pavucontrol/merge_requests/11

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

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

Re: [pulseaudio-discuss] [ANNOUNCE] pavucontrol 4.0

[Tanu Kaskinen]

On Wed, 2019-03-06 at 11:48 +0100, NicoHood wrote:
> On 3/5/19 5:12 PM, Tanu Kaskinen wrote:
> >  * There can now be only one pavucontrol window open at a time.
> >Trying to start pavucontrol for a second time brings the
> >first window to foreground.
> 
> Hi,
> This "fix" is really a problem for me:
> 
> I have 6 audio sinks with pulseaudio installed in my appartment. I am
> really happy that I can control each of them via pavucontrol using the
> PULSE_SERVER environment variable option.
> 
> When I need to debug something I usually have more windows of
> pavucontrol open, for multiple devices. Now this does not work anymore
> which is super annoying.
> 
> My suggestion is to check for the PULSE_SERVER and only have unique
> windows for each host. So If you want to run pulseaudio for localhost
> multiple times only one instance is open, but you can still open
> pavucontrol for other remote destinations (also only one for each host).
> 
> If that suggestion is too complicated to implement I would kindly
> request to revert the recent fix. :S

We give GLib the application ID (org.pulseaudio.pavucontrol), and GLib
then implements all the activation magic using that ID. We could append
the server string to the application ID. I quickly tried setting a
bogus ID, and that didn't seem to break anything (I noticed that
running the pavucontrol command for a second time doesn't bring the
window to foreground on my machine, though, but that doesn't seem to be
related to the unusual application ID, because reverting back to the
normal ID doesn't work any better).

So, I think I'll make a patch that appends the server string to the
application ID, even though messing with the application ID feels quite
"wrong".

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

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

[pulseaudio-discuss] [ANNOUNCE] pavucontrol 4.0

[Tanu Kaskinen]

It's announcement time!

It's been a while, a long while, since the last pavucontrol release.
Almost four years, says the thing that counts time. Today we can reset
that thing! Pavucontrol 4.0 is here! Woo!

These are the main changes:

 * There can now be only one pavucontrol window open at a time.
   Trying to start pavucontrol for a second time brings the
   first window to foreground.

 * Added a "Show volume meters" checkbox to the Configuration
   tab. Disabling the volume meters reduces CPU use.

 * Improved the use of space (removed useless margins and
   paddings).

 * A more appropriate icon for the channel lock button.

 * Better channel label layout, prevents volume sliders from
   getting unaligned.

 * Maximum latency offset increased from 2 to 5 seconds to
   accommodate AirPlay devices that often have higher latency
   than 2 seconds (this is not that useful on newer PulseAudio
   versions, though, because the latency is reported much more
   accurately than before).

 * New --version command line option.

 * New translations: Chinese (Taiwan), Croatian, Korean,
   Norwegian Nynorsk, Lithuanian, Valencian.

 * Updated translations: Finnish, French, German, Italian,
   Japanese, Polish, Swedish.

 * Dropped support for GTK 2.

 * Bumped the minimum supported libpulse version to 5.0.

 * Improved compatibility with newer Glade versions.

Big thanks to all contributors!

The tarball:
https://freedesktop.org/software/pulseaudio/pavucontrol/pavucontrol-4.0.tar.xz
SHA256: 8fc45bac9722aefa6f022999cbb76242d143c31b314e2dbb38f034f4069d14e2


 git shortlog 

Anders Jonsson (2):
  main: Fix typo
  i18n: update the Swedish translation

Andreas Rönnquist (1):
  Remove closing window by pressing Esc

Antonio Ospite (2):
  i18n: Some fixes for the Italian translation
  i18n: improve one Italian string

Arun Raghavan (5):
  build-sys: Depend on libpulse >= 5.0
  build-sys: Use C++11 for building
  doc: Update link to git repository
  build-sys: Add m4 file for AX_CXX_COMPILE_STDCXX_11
  mainwindow: Don't add a border on the outermost vbox

Bruno Duyé (1):
  i18n: "Définir comme alternative" means "Set as an alternative" ...

Colin Leroy (2):
  devicewidget: Set latency offset's maximum to 5000ms
  Implement single-launch with Gtk::Application

David Kreuter (1):
  mainwindow: unavailable profiles are marked as such in their description

Felipe Sateler (1):
  mainwindow: force icons to have sane size

Jose A. Múrcia (1):
  i18n: add Valencian translation

Jung-Kyu Park (1):
  i18n: add Korean translation

Karl Ove Hufthammer (3):
  i18n: Add Norwegian Nynorsk translation
  channelwidget: Make volume strings translatable and add missing
space
  i18n: Update Norwegian Nynorsk translations

Lukas K (1):
  Add checkbutton for disabling volume meters

Masato Hashimoto (1):
  i18n: update the Japanese translation

Nikita Zlobin (1):
  UI form enhancement

Paul W. Frields (1):
  Use freedesktop.org standard icon name

Peter Meerwald (1):
  Add --version command line option

Pino Toscano (1):
  Remove Encoding key from .desktop file

Piotr Drąg (5):
  i18n: Updated Polish translation
  i18n: update Polish translation
  i18n: move Valencian translation to the standard language code
  i18n: update Polish translation
  i18n: update Polish translation

Tanu Kaskinen (24):
  .gitignore: add compile
  README: update links
  pavucontrol.glade: use a more appropriate icon for the channel lock button
  remove unnecessary RefPtr wrapping of PavuApplication
  remove unnecessary Window -> MainWindow casting
  update repository links to GitLab
  pavuapplication: initialize members in the constructor
  move some widget initializations from MinimalStreamWidget to subclasses
  rename more objects in the quest to get rid of duplicate IDs
  pavucontrol.glade: object renames automatically done by Glade
  pavucontrol.glade: changes automatically done by Glade
  drop gtk2 support
  README: remove the copyright notice
  README: add "Bug Reports" and "Contributing Code" sections
  README: remove the "Acknowledgements" section
  README: remove reference to an ancient Debian version
  README: remove the page footer
  README: add a news item for the upcoming release
  pavucontrol.glade: right-align channel labels
  channelwidget: refactor to reduce repetition
  channelwidget: ensure that all channel labels have the same width
  README: a couple of edits for the 4.0 changelog
  i18n: add zh_TW to LINGUAS
  prepare for releasing 4.0

Thomas Lange (1):
  i18n: update German translation

Tuure Savuoja (1):
  i18n: update Finnish (fi) translation for "set as fallback"

Yi-Jyun Pan (1):
  Update Headers

Yuri Chornoivan (1):

Re: [pulseaudio-discuss] [PATCH] alsa-mixer: use more identical entry to distinguish Focusrite Saffire Pro 10 i/o from Liquid Saffire 56

[Tanu Kaskinen]

On Tue, 2019-02-26 at 13:55 +0900, Takashi Sakamoto wrote:
> In a former commit 37358e42c49a ("alsa: Suppress udev detection of sound
> card for some units on IEEE 1394 bus"), PulseAudio has udev rules to
> suppress handling some units on IEEE 1394 bus for a below issue:
> 
> Bug 199365 - repeating bus resets on Firewire bus with Focusrite Saffaire 
> 26/io
> https://bugzilla.kernel.org/show_bug.cgi?id=199365
> 
> However, I found that the rules match another model; Focusrite Liquid
> Saffire 56. For detail, refer to below patch for Linux sound subsystem:
> 
> [alsa-devel] [PATCH] ALSA: bebob: use more identical mod_alias for
> Saffire Pro 10 I/O against Liquid Saffire 56
> https://mailman.alsa-project.org/pipermail/alsa-devel/2019-February/146003.html
> 
> For PulseAudio, more identical rule is better to distinguish them,
> because Liquid Saffire 56 (an application of TCAT TCD2200 ASIC, a.k.a
> Dice Jr.) can be handled by pulseaudio without the issue.
> 
> This commit changes udev rule with model name instead of model_id from
> configuration ROM. Below is data on udevd for Liquid Saffire 56, for
> your information:
> 
> $ udevadm info -q all -p /sys/bus/firewire/devices/fw1.0/sound/card2/
> P: 
> /devices/pci:00/:00:01.2/:03:00.2/:04:07.0/:0a:00.0/:0b:00.0/fw1/fw1.0/sound/card2
> E: 
> DEVPATH=/devices/pci:00/:00:01.2/:03:00.2/:04:07.0/:0a:00.0/:0b:00.0/fw1/fw1.0/sound/card2
> E: ID_BUS=firewire
> E: ID_FOR_SEAT=sound-pci-_0b_00_0
> E: ID_ID=firewire-0x00130e04018001e9
> E: ID_MODEL=LIQUID_SAFFIRE_56
> E: ID_MODEL_FROM_DATABASE=XIO2213A/B/XIO2221 IEEE-1394b OHCI Controller 
> [Cheetah Express]
> E: ID_MODEL_ID=0x06
> E: ID_PATH=pci-:0b:00.0
> E: ID_PATH_TAG=pci-_0b_00_0
> E: ID_PCI_CLASS_FROM_DATABASE=Serial bus controller
> E: ID_PCI_INTERFACE_FROM_DATABASE=OHCI
> E: ID_PCI_SUBCLASS_FROM_DATABASE=FireWire (IEEE 1394)
> E: ID_SERIAL=0x00130e04018001e9
> E: ID_SERIAL_SHORT=0x00130e04018001e9
> E: ID_VENDOR=Focusrite
> E: ID_VENDOR_FROM_DATABASE=Texas Instruments
> E: ID_VENDOR_ID=0x00130e
> E: SOUND_INITIALIZED=1
> E: SUBSYSTEM=sound
> E: SYSTEMD_WANTS=sound.target
> E: TAGS=:seat:systemd:
> E: USEC_INITIALIZED=9802422583
> 
> Fixes: 37358e42c49a ("alsa: Suppress udev detection of sound card for some 
> units on IEEE 1394 bus")
> Signed-off-by: Takashi Sakamoto 
> ---
>  src/modules/alsa/mixer/profile-sets/90-pulseaudio.rules | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/src/modules/alsa/mixer/profile-sets/90-pulseaudio.rules 
> b/src/modules/alsa/mixer/profile-sets/90-pulseaudio.rules
> index 1303d1bce..975dbd75c 100644
> --- a/src/modules/alsa/mixer/profile-sets/90-pulseaudio.rules
> +++ b/src/modules/alsa/mixer/profile-sets/90-pulseaudio.rules
> @@ -127,6 +127,9 @@ LABEL="pulseaudio_firewire_quirk"
>  # Focusrite Saffire Pro 10/26 i/o has a quirk to disappear from IEEE 1394 
> bus when losing connections.
>  # https://bugzilla.kernel.org/show_bug.cgi?id=199365
>  ENV{ID_VENDOR_ID}=="0x00130e", ENV{ID_MODEL_ID}=="0x03", 
> ENV{PULSE_IGNORE}="1"
> -ENV{ID_VENDOR_ID}=="0x00130e", ENV{ID_MODEL_ID}=="0x06", 
> ENV{PULSE_IGNORE}="1"
> +# Both of Saffire Pro 10 i/o and Liquid Saffire 56 has the same ID_MODEL_ID
> +# (0x06). Here, use the identical name in configuration ROM to 
> distinguish
> +# the former.
> +ENV{ID_VENDOR_ID}=="0x00130e", ENV{ID_MODEL}=="Pro10IO" ENV{PULSE_IGNORE}="1"
>  
>  LABEL="pulseaudio_end"

Thanks! Applied. I did some edits to the commit message, because you
used the word "identical" in a confusing way. Something being
"identical" means that it's exactly the same as something else, but you
seemed to use the word with very different meaning.

I intended to edit the comment in the udev rules too, but I forgot to
do that before pushing, so I changed the comment in a separate commit.

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

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

Re: [pulseaudio-discuss] License problem: LDAC codec & pulseaudio

[Tanu Kaskinen]

On Sat, 2019-02-23 at 16:06 +0100, Pali Rohár wrote:
> Hello,
> 
> I would like to discuss about licence problems with usage of LDAC
> encoder libldac in pulseaudio. LDAC is a codec used by some Sony
> bluetooth headsets and it would be nice to have support for it after my
> patch series for Modular API for A2DP codecs is merged.
> 
> There is only one released LDAC encoder. It is libldac which can be
> found at: https://android.googlesource.com/platform/external/libldac/
> It is licensed under Apache License Version 2.0.
> 
> If I understood correctly pulseaudio is licensed under LGPL v2.1 or
> later with some exceptions when some optional GPL dependences are
> enabled then server part is licensed under GPL v2 or later. So it can be
> distributed under GPL v3, right? Please correct me if I'm wrong.
> 
> According to FSF https://www.gnu.org/licenses/license-list.html#apache2
> Apache License Version 2.0 is compatible with GPL v3, but is
> incompatible with GPL v2.
> 
> So, would it be feasible to write LDAC specific code for pulseaudio
> under GPL v3 license (in separate files) and make compile time option to
> enable/disable GPL v3 LDAC support? When enabled it would mean that
> compiled binary of puleaudio server and server modules are forced to be
> distributed under GPL v3 and thanks to compatibility with Apache License
> Version 2.0, it would be possible to use libdac library. When disabled
> then it would be like before (without LDAC and with license like
> before). Am I correct?

Yes, I believe you're correct, and at least I am fine with adding LDAC
support via libldac.

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

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

Re: [pulseaudio-discuss] [re-post] libsndfile

[Tanu Kaskinen]

On Thu, 2019-02-14 at 16:38 +, sylvain.bertr...@gmail.com wrote:
> Hi,
> 
> Is it reasonable to think libsndfile can be made an optional dependency?

If a good justification is provided, a patch might very well be
accepted. What are you building that requires the dependencies to be so
minimal?

pacat (which is the same program as paplay, parec and parecord) would
become much less useful, because it could play only raw audio, but I
suppose you can live with that.

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

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

Re: [pulseaudio-discuss] [PATCH v6 00/11] New API for Bluetooth A2DP codecs

[Tanu Kaskinen]

On Sat, 2019-02-09 at 20:00 +0100, Pali Rohár wrote:
> Hello, as there is still open discussion about codec API and choosing
> codec, can you at least review first 4 patches which are independent of
> this problem?

I can review them once I've updated the alsa recipes in OpenEmbedded,
released pavucontrol and reviewed Hui Wang's patches.

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

___
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

[Tanu Kaskinen]

On Tue, 2019-02-12 at 10:14 +0100, Pali Rohár wrote:
> On Friday 08 February 2019 21:44:53 Tanu Kaskinen wrote:
> > On Tue, 2019-02-05 at 20:35 +0100, Pali Rohár wrote:
> > > On Tuesday 05 February 2019 21:22:46 Tanu Kaskinen wrote:
> > > > On Mon, 2019-02-04 at 20:28 +0100, Pali Rohár wrote:
> > > > > On Monday 28 January 2019 18:50:56 Tanu Kaskinen wrote:
> > > > > > On Fri, 2019-01-25 at 16:41 +0100, Pali Rohár wrote:
> > > > > > > On Friday 25 January 2019 17:11:00 Tanu Kaskinen wrote:
> > > > > > > > On Fri, 2019-01-25 at 11:02 +0100, Pali Rohár wrote:
> > > > > > > > > On Friday 25 January 2019 11:49:32 Tanu Kaskinen wrote:
> > > > > > > > > > On Sat, 2019-01-19 at 18:11 +0100, Pali Rohár wrote:
> > > > > > > > > > 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.
> > > > > > > > > 
> > > > > > > > > All this seems like bluetooth specific. Extending core 
> > > > > > > > > protocol API for
> > > > > > > > > bluetooth specific API means that all applications needs to 
> > > > > > > > > be extended
> > > > > > > > > to support it.
> > > > > > > > > 
> > > > > > > > > So for choosing A2DP codec, it would be needed to extend KDE 
> > > > > > > > > sound
> > > > > > > > > system settings application, Gnome configuration, and also 
> > > > > > > > > other...
> > > > > > > > > 
> > > > > > > > > I think this is too complicated and needs cooperation with 
> > > > > > > > > other
> > > > > > > > > projects and team.
> > > > > > > > 
> > > > > > > > Well, I disagree about it being

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

[Tanu Kaskinen]

On Tue, 2019-02-05 at 20:35 +0100, Pali Rohár wrote:
> On Tuesday 05 February 2019 21:22:46 Tanu Kaskinen wrote:
> > On Mon, 2019-02-04 at 20:28 +0100, Pali Rohár wrote:
> > > On Monday 28 January 2019 18:50:56 Tanu Kaskinen wrote:
> > > > On Fri, 2019-01-25 at 16:41 +0100, Pali Rohár wrote:
> > > > > On Friday 25 January 2019 17:11:00 Tanu Kaskinen wrote:
> > > > > > On Fri, 2019-01-25 at 11:02 +0100, Pali Rohár wrote:
> > > > > > > On Friday 25 January 2019 11:49:32 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=154696260401673=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.
> > > > > > > 
> > > > > > > So which codec should be chosen when you do not specify it? That 
> > > > > > > is the
> > > > > > > most important question if codec is going to be hidden.
> > > > > > 
> > > > > > Well, which codec do you choose by default when connecting a new
> > > > > > device?
> > > > > 
> > > > > Not choosing any. When creating a connection, codec selection is up to
> > > > > the remote device and bluez, on what they decide.
> > > > > 
> > > > > > Surely you assign some internal priority for the codecs.
> > > > > > 
> > > > > > If the user has selected a specific codec earlier then that codec
> > > > > > should be selected.
> > > > > 
> > > > > That is again not under pulseaudio control. When initializing 
> > > > > connection

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

[Tanu Kaskinen]

On Mon, 2019-02-04 at 20:28 +0100, Pali Rohár wrote:
> On Monday 28 January 2019 18:50:56 Tanu Kaskinen wrote:
> > On Fri, 2019-01-25 at 16:41 +0100, Pali Rohár wrote:
> > > On Friday 25 January 2019 17:11:00 Tanu Kaskinen wrote:
> > > > On Fri, 2019-01-25 at 11:02 +0100, Pali Rohár wrote:
> > > > > On Friday 25 January 2019 11:49:32 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=154696260401673=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.
> > > > > 
> > > > > So which codec should be chosen when you do not specify it? That is 
> > > > > the
> > > > > most important question if codec is going to be hidden.
> > > > 
> > > > Well, which codec do you choose by default when connecting a new
> > > > device?
> > > 
> > > Not choosing any. When creating a connection, codec selection is up to
> > > the remote device and bluez, on what they decide.
> > > 
> > > > Surely you assign some internal priority for the codecs.
> > > > 
> > > > If the user has selected a specific codec earlier then that codec
> > > > should be selected.
> > > 
> > > That is again not under pulseaudio control. When initializing connection
> > > it is up to the bluez and remote device.
> > > 
> > > Bluez has now API for switching A2DP codec, by doing disconnect and
> > > initializing a new connection with chosen endpoint (codec). And this is
> > > what happen when profile is going to be switched in pulseaudio.
> > > 
> > > Yes, we can probably implement per-device priority in way that after
> > > bluez initialize connection, we use API for codec switching to one which
> > > we want. But this is, I think rather complicated. And if it is really
> > > needed we can try to implement it later once everything other is
> > > working.
> > 
> > Thanks for the explanation.
> > 
> > > > > And if codec is exported as card profile, is not operation "switch to
> > > > > A2DP" same as "switch to A2DP profile with higher priority"?
> > > > 
> > > > Do you mean "the highest priority" rather than "

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

[Tanu Kaskinen]

Ping? There were some questions in the message below that I'd like to
get some kind of answers to.

-- Tanu

On Mon, 2019-01-28 at 18:50 +0200, Tanu Kaskinen wrote:
> On Fri, 2019-01-25 at 16:41 +0100, Pali Rohár wrote:
> > On Friday 25 January 2019 17:11:00 Tanu Kaskinen wrote:
> > > On Fri, 2019-01-25 at 11:02 +0100, Pali Rohár wrote:
> > > > On Friday 25 January 2019 11:49:32 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=154696260401673=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.
> > > > 
> > > > So which codec should be chosen when you do not specify it? That is the
> > > > most important question if codec is going to be hidden.
> > > 
> > > Well, which codec do you choose by default when connecting a new
> > > device?
> > 
> > Not choosing any. When creating a connection, codec selection is up to
> > the remote device and bluez, on what they decide.
> > 
> > > Surely you assign some internal priority for the codecs.
> > > 
> > > If the user has selected a specific codec earlier then that codec
> > > should be selected.
> > 
> > That is again not under pulseaudio control. When initializing connection
> > it is up to the bluez and remote device.
> > 
> > Bluez has now API for switching A2DP codec, by doing disconnect and
> > initializing a new connection with chosen endpoint (codec). And this is
> > what happen when profile is going to be switched in pulseaudio.
> > 
> > Yes, we can probably implement per-device priority in way that after
> > bluez initialize connection, we use API for codec switching to one which
> > we want. But this is, I think rather complicated. And if it is really
> > needed we can try to implement it later once everything other is
> > working.
> 
> Thanks for the explanation.
> 
> > > > And if codec is exported as card profile, is not operation "switch to
> > > > A2DP" same as "switch to A2DP profile with higher priority"?
> > > 
> > > Do you mean "the highest priority" rather than "higher priority"? Is
> > > your idea that when e.g. Gnome audio settings wants to enable bluetooth
> > > output,
> > 
> > What do you mean by "wants to enable bluetooth output"?
> 
> Let's say that the bluetooth card profile is "off". The user opens the
> Gnome audio settings and selects the bluetooth headset as th

Re: [pulseaudio-discuss] Questions regarding messaging API

[Tanu Kaskinen]

On Mon, 2019-01-28 at 18:43 +0100, Georg Chini wrote:
> On 28.01.19 18:37, Georg Chini wrote:
> > On 28.01.19 18:05, Tanu Kaskinen wrote:
> > > On Mon, 2019-01-28 at 17:50 +0100, Georg Chini wrote:
> > > > > > 2) For read_string() and read_raw() it is difficult to retain a 
> > > > > > default
> > > > > > value.
> > > > > > The string returned by the functions is a char, but it must not be 
> > > > > > freed
> > > > > > because it is part of the larger parameter string. So the string 
> > > > > > passed
> > > > > > as default would need to be a const char, which makes some type 
> > > > > > casting
> > > > > > necessary. Therefore I would like to keep it as is for the string 
> > > > > > functions.
> > > > > Is this about not changing the pass-by-reference arguments to 
> > > > > functions
> > > > > until success? If so, that seems like a separate issue from whether 
> > > > > the
> > > > > argument should be const or not. Just use an internal temporary
> > > > > variable in the functions and only assign to the user variable at the
> > > > > end of the function.
> > > > > 
> > > > > Regarding constness, I think the function parameter can be kept non-
> > > > > const even if it's not supposed to be freed (just make sure to 
> > > > > document
> > > > > that). It's ok to modify the string contents, nothing will break.
> > > > As said on IRC I think you did not get the point. Consider the
> > > > following code:
> > > > 
> > > > char *result;
> > > > 
> > > > /* To demonstrate the point, I fill result with a newly allocated 
> > > > string */
> > > > result = pa_xstrdup("A string");
> > > > 
> > > > /* Now I call read_string() */
> > > > err = pa_message_params_read_string(parameter_list, , );
> > > > 
> > > > Now, if the default value is returned, the string in result must be 
> > > > freed.
> > > > If the value returned is from the parameter list, the string in 
> > > > result must
> > > > NOT be freed. You could work around it by using typecasts or by 
> > > > deciding
> > > > if the string needs to be freed based on the err value, but I think
> > > > this is very ugly and there is nothing that prevents a user doing it 
> > > > the
> > > > wrong way. Therefore I would suggest not to use default values for the
> > > > string functions. For read_raw() a default seems pointless anyway,
> > > > so only the functions read_string() and read_string_array() would be
> > > > affected. For the numeric/boolean functions there is no such issue.
> > > It's an error to pass a string that needs freeing to
> > > pa_message_params_read_string(), just like it's an error to pass a
> > > string that needs freeing to pa_tagstruct_gets().
> > > 
> > > Your original patch didn't free the parameter either, so I don't know
> > > why you started to worry about this. Maybe you misunderstood this
> > > sentence:
> > > 
> > > "It should be mentioned that if allocate is true, the result should be
> > > freed with pa_xfree()."
> > > 
> > > Taken out of context (as was the case when I quoted it), it could be
> > > understood so that pa_message_params_read_string() should free the
> > > function parameter before assigning a new value to it, but I didn't
> > > mean that. I meant that the function documentation should tell the
> > > caller to use pa_xfree() (rather than plain free() or whatever else)
> > > when freeing the returned string.
> > > 
> > OK, I was worrying because unlike pa_tagstruct_gets() the
> > function parameter is currently char ** and not const char **
> > But after taking a second look, I see that I can make it const
> > now, so problem solved. Are you OK with leaving read_raw()
> > without default? Here the parameter must remain char**
> > because the returned string may be a list that can be
> > processed again by the parsing functions (and in my opinion
> > a default in this case does not make sense anyway).

By "leaving without default", do you mean that you want to assign to
the result variable early, when the function might still fail? I don't
see why you'd want to do that, 

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

[Tanu Kaskinen]

On Mon, 2019-01-28 at 18:01 +0100, Georg Chini wrote:
> On 28.01.19 17:50, Tanu Kaskinen wrote:
> > On Fri, 2019-01-25 at 16:41 +0100, Pali Rohár wrote:
> > > On Friday 25 January 2019 17:11:00 Tanu Kaskinen wrote:
> > > > On Fri, 2019-01-25 at 11:02 +0100, Pali Rohár wrote:
> > > > > With profiles it is simple as it is already supported in desktop
> > > > > environments.
> > > > That's certainly a benefit. The problem is just that forcing the user
> > > > to make a choice between codecs isn't very nice if the user doesn't
> > > > know the practical difference between the provided options.
> > > User is not forced. Bluez and remote device choose codec for him. And if
> > > user is not happy with selection then can change it to something
> > > different which "plays better".
> > > 
> > > We already have module bluetooth policy which switch between HFP and
> > > A2DP profiles based on active VOIP application. So user already has
> > > microphone support when calling. And after hanging call policy module
> > > should switch back to previous A2DP profile (codec) without user
> > > interaction.
> > > 
> > > So I do not think it is such catastrophic that user need to choose
> > > something. User has already pre-selected some A2DP variant. And based on
> > > fact that lot of headsets remember last used codec per device, it is not
> > > such a big problem.
> > Yeah, it seems that the need to choose the card profile isn't very
> > common. But there can be situations where the user wants to just
> > activate the A2DP profile. How do you communicate to the user which
> > codec is currently active if the card profile is "off"?
> > 
> One question: There are codecs which support a voice back channel.
> Would we not need at least two profiles, one for "normal" A2DP and
> one for A2DP with back channel?

Yes, you're right, even if we don't have per-codec profiles, we'll need
a separate bidirectional A2DP profile when that's implemented (IIRC
it's not yet implemented by these patches).

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

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

Re: [pulseaudio-discuss] Questions regarding messaging API

[Tanu Kaskinen]

On Mon, 2019-01-28 at 17:50 +0100, Georg Chini wrote:
> > > 2) For read_string() and read_raw() it is difficult to retain a default
> > > value.
> > > The string returned by the functions is a char, but it must not be freed
> > > because it is part of the larger parameter string. So the string passed
> > > as default would need to be a const char, which makes some type casting
> > > necessary. Therefore I would like to keep it as is for the string 
> > > functions.
> > Is this about not changing the pass-by-reference arguments to functions
> > until success? If so, that seems like a separate issue from whether the
> > argument should be const or not. Just use an internal temporary
> > variable in the functions and only assign to the user variable at the
> > end of the function.
> > 
> > Regarding constness, I think the function parameter can be kept non-
> > const even if it's not supposed to be freed (just make sure to document
> > that). It's ok to modify the string contents, nothing will break.
> 
> As said on IRC I think you did not get the point. Consider the
> following code:
> 
> char *result;
> 
> /* To demonstrate the point, I fill result with a newly allocated string */
> result = pa_xstrdup("A string");
> 
> /* Now I call read_string() */
> err = pa_message_params_read_string(parameter_list, , );
> 
> Now, if the default value is returned, the string in result must be freed.
> If the value returned is from the parameter list, the string in result must
> NOT be freed. You could work around it by using typecasts or by deciding
> if the string needs to be freed based on the err value, but I think
> this is very ugly and there is nothing that prevents a user doing it the
> wrong way. Therefore I would suggest not to use default values for the
> string functions. For read_raw() a default seems pointless anyway,
> so only the functions read_string() and read_string_array() would be
> affected. For the numeric/boolean functions there is no such issue.

It's an error to pass a string that needs freeing to
pa_message_params_read_string(), just like it's an error to pass a
string that needs freeing to pa_tagstruct_gets().

Your original patch didn't free the parameter either, so I don't know
why you started to worry about this. Maybe you misunderstood this
sentence:

"It should be mentioned that if allocate is true, the result should be
freed with pa_xfree()."

Taken out of context (as was the case when I quoted it), it could be
understood so that pa_message_params_read_string() should free the
function parameter before assigning a new value to it, but I didn't
mean that. I meant that the function documentation should tell the
caller to use pa_xfree() (rather than plain free() or whatever else)
when freeing the returned string.

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

___
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

[Tanu Kaskinen]

On Fri, 2019-01-25 at 16:41 +0100, Pali Rohár wrote:
> On Friday 25 January 2019 17:11:00 Tanu Kaskinen wrote:
> > On Fri, 2019-01-25 at 11:02 +0100, Pali Rohár wrote:
> > > On Friday 25 January 2019 11:49:32 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=154696260401673=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.
> > > 
> > > So which codec should be chosen when you do not specify it? That is the
> > > most important question if codec is going to be hidden.
> > 
> > Well, which codec do you choose by default when connecting a new
> > device?
> 
> Not choosing any. When creating a connection, codec selection is up to
> the remote device and bluez, on what they decide.
> 
> > Surely you assign some internal priority for the codecs.
> > 
> > If the user has selected a specific codec earlier then that codec
> > should be selected.
> 
> That is again not under pulseaudio control. When initializing connection
> it is up to the bluez and remote device.
> 
> Bluez has now API for switching A2DP codec, by doing disconnect and
> initializing a new connection with chosen endpoint (codec). And this is
> what happen when profile is going to be switched in pulseaudio.
> 
> Yes, we can probably implement per-device priority in way that after
> bluez initialize connection, we use API for codec switching to one which
> we want. But this is, I think rather complicated. And if it is really
> needed we can try to implement it later once everything other is
> working.

Thanks for the explanation.

> > > And if codec is exported as card profile, is not operation "switch to
> > > A2DP" same as "switch to A2DP profile with higher priority"?
> > 
> > Do you mean "the highest priority" rather than "higher priority"? Is
> > your idea that when e.g. Gnome audio settings wants to enable bluetooth
> > output,
> 
> What do you mean by "wants to enable bluetooth output"?

Let's say that the bluetooth card profile is "off". The user opens the
Gnome audio settings and selects the bluetooth headset as the new
output device (there is one device entry in the Gnome UI despite
multiple profiles). How does Gnome audio settings decide which profile
to select?

> Because you cannot initialize A2DP connection from pulseaudio (or at
> least pulseaudio does not support it). Initializing connection is done
> from bluez client (on KDE it is bluedevil). And pulseaudio allows to
> choose A2DP profile only if connection is already established by bluez.
> 
> > it should look at all output profiles on the card and pick the
> > one with the highest priority? I suppose that would work, and quite
> > possibly that's what it already does. That requires the profile
> > priorities to be dynamic, however, so that when the 

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

[Tanu Kaskinen]

On Fri, 2019-01-25 at 11:02 +0100, Pali Rohár wrote:
> On Friday 25 January 2019 11:49:32 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=154696260401673=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.
> 
> So which codec should be chosen when you do not specify it? That is the
> most important question if codec is going to be hidden.

Well, which codec do you choose by default when connecting a new
device? Surely you assign some internal priority for the codecs.

If the user has selected a specific codec earlier then that codec
should be selected.

> And if codec is exported as card profile, is not operation "switch to
> A2DP" same as "switch to A2DP profile with higher priority"?

Do you mean "the highest priority" rather than "higher priority"? Is
your idea that when e.g. Gnome audio settings wants to enable bluetooth
output, it should look at all output profiles on the card and pick the
one with the highest priority? I suppose that would work, and quite
possibly that's what it already does. That requires the profile
priorities to be dynamic, however, so that when the user selects a
profile, it becomes the highest priority codec.

How do you decide which A2DP profile to activate in module-bluetooth-
policy?

> > 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.
> 
> All this seems like bluetooth specific. Extending core protocol API for
> bluetooth specific API means that all applications needs to be extended
> to support it.
> 
> So for choosing A2DP codec, it would be needed to extend KDE sound
> system settings application, Gnome configuration, and also other...
> 
> I think this is too complicated and needs cooperation with other
> projects and team.

Well, I disagree about it being too complicated, and there's no need
for any particular cooperation effort. UIs that want to change the
codec just need to be updated to take 

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

[Tanu Kaskinen]

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

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.

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

___
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

[Tanu Kaskinen]

On Wed, 2019-01-23 at 18:52 +0100, Pali Rohár wrote:
> On Wednesday 23 January 2019 19:16:16 Luiz Augusto von Dentz wrote:
> > Hi Pali,
> > On Sat, Jan 19, 2019 at 7:19 PM Pali Rohár  wrote:
> > > I think that this patch series is now ready for review and testing. All
> > > needed parts are finished.
> > > 
> > > The only problem is with asynchronous profile switching as function
> > > pa_card_set_profile() does not support it. All details are in patch
> > > "[PATCH v5 5/7] bluetooth: Modular API for A2DP codecs".
> > > 
> > > So can you look at this patch series and review it?
> > 
> > I tested this today, it seems to work fine with sbc but with
> > faststream there seems to be some problem somewhere as it does seems
> > to consume too much cpu time. Regarding set_profile that is something
> > I think we will need to address otherwise the UI is pretty much
> > useless to switch as it doesn't seems to react well when -EAGAIN is
> > returned, we could perhaps block on SetConfiguration since we do block
> > on Acquire anyway, or you have already tried that?
> 
> Yes, I tried it. Pulseaudio blocks communication and therefore it also
> does not receive following DBus requests from bluez and so
> SetConfiguration timeout.
> 
> In fact -EAGAIN is just dropped in pulseaudio bluetooth module and
> replaced by -1. I just wanted to "highlight" that part of code, so I
> used -EAGAIN, but it has same meaning as any other non-zero value.
> 
> I was thinking about it and we could block this on another layer.
> pa_card_set_profile() is called when application request to change
> profile via PA socket. So extend pa_card_set_profile() API to pass
> callback function which would be called after profile is changed
> asynchronously. And just block user request until callback is called.
> 
> Maybe some other people who understand pulseaudio better can help? How
> to implement asynchronous profile switching?

To me it seems that either pa_card_set_profile() should be made
asynchronous, which would be nice, because it would allow errors to be
reported properly, or the bluetooth code should just initiate the
profile change operation and pretend that the switching always
succeeds. In the latter option, in case of failure the bluetooth code
would switch to the off profile.

I'm fine with either option.

In case you wanted some more detailed thoughts about implementation,
here's what I'd do if I chose the "make pa_card_set_profile()
asynchronous" option:

pa_card_set_profile() should be renamed to pa_card_set_profile_begin().
It would take a user callback to be called when the operation finishes.

pa_card_set_profile_begin() should return an operation object similar
to pa_operation in the client API (but I believe pa_operation is not
suitable to be used in the core, because it's tied to pa_context, and I
also dislike its use of reference counting). The operation object would
store the callback and any other necessary information related to the
profile switch.

The operation object would be created by pa_card_set_profile_begin()
and owned by pa_card. The card backend can also save some backend
specific data in the operation object.

Once the profile switch completes, the card backend should set the
result information (success/failure, error codes, etc.) in the
operation object and call pa_card_set_profile_finish() with the
operation object as an argument. pa_card_set_profile_finish() would
then call the user callback and free the operation object.

The operation needs to be cancellable too. If
pa_card_set_profile_begin() is called while there's an older operation
still in progress, the old operation needs to be cancelled. The card
backend needs to set a callback in the operation object to get notified
about cancellation. The pa_card_set_profile_begin() user can probably
handle a cancellation in the same way it handles any kind of failure
(so it gets notified via the operation user callback).

When the card is destroyed, any ongoing asynchronus operation needs to
be cancelled.

It would probably be a good idea to define a generic asynchronous
operation object at some point (the name could be pa_async_operation),
but as long as pa_card_set_profile() remains the only user for such
functionality, we can begin by making the operation object specific to
the profile switch operation, which would keep things a bit less
complex.

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

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

[pulseaudio-discuss] [ANNOUNCE] paprefs 1.1

[Tanu Kaskinen]

The 2019 edition of paprefs is here! The version number is only 1.1,
because there aren't any new features compared to the last year's
edition. The main changes are:

 * The D-Bus code has been ported from dbus-glib and libdbus to GDBus.
GDBus is part of GIO, which was already a dependency, so this means
fewer dependencies overall.

 * When enabling simulateneous output, paprefs now loads module-
combine-sink instead of module-combine. module-combine is a deprecated
alias for module-combine-sink, and loading it caused PulseAudio to log
a warning. There are no functional changes apart from avoiding the
warning.

Thank you Jan Tojnar and Julian Sikorski for your contributions!

The tarball:
https://freedesktop.org/software/pulseaudio/paprefs/paprefs-1.1.tar.xz
SHA256: 6ef243c17ebc19ca0e8569e23e00e597c801ca48a2facd77da1d4c08c42d3fa1


 git shortlog 

Jan Tojnar (2):
  Port from dbus-glib to gdbus
  Remove libdbus dependency

Julian Sikorski (1):
  Use module-combine-sink instead of module-combine

Tanu Kaskinen (3):
  README: GitLab migration happened
  README: add a news item for the 1.1 release
  prepare for releasing 1.1

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

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

Re: [pulseaudio-discuss] [PATCH 3/4] move streams to new appeared sinks if they prefer these sinks

[Tanu Kaskinen]

On Mon, 2019-01-07 at 22:20 +0100, Georg Chini wrote:
> On 07.01.19 18:07, Tanu Kaskinen wrote:
> > On Wed, 2019-01-02 at 08:25 -0500, Joe wrote:
> > > On 1/2/19 7:55 AM, Hui Wang wrote:
> > > > On 2019/1/1 上午2:10, Tanu Kaskinen wrote:
> > > > > On Mon, 2018-12-31 at 20:01 +0200, Tanu Kaskinen wrote:
> > > > > > On Mon, 2018-11-05 at 09:47 +0800, Hui Wang wrote:
> > > > > > > diff --git a/src/pulsecore/sink.c b/src/pulsecore/sink.c
> > > > > > > index 63a3456e7..a2a390beb 100644
> > > > > > > --- a/src/pulsecore/sink.c
> > > > > > > +++ b/src/pulsecore/sink.c
> > > > > > > @@ -722,6 +722,8 @@ void pa_sink_put(pa_sink* s) {
> > > > > > >/* This function must be called after the
> > > > > > > PA_CORE_HOOK_SINK_PUT hook,
> > > > > > > * because module-switch-on-connect needs to know the old
> > > > > > > default sink */
> > > > > > >pa_core_update_default_sink(s->core, false);
> > > > > > > +
> > > > > > > +pa_sink_bind_preferred_stream_to_a_sink(s);
> > > > > > >}
> > > > > > >  /* Called from main context */
> > > > > > > @@ -3919,3 +3921,32 @@ void
> > > > > > > pa_sink_move_streams_from_oldsink_to_newsink(pa_sink *old_sink,
> > > > > > > pa_sink *ne
> > > > > > >  return;
> > > > > > >}
> > > > > > > +
> > > > > > > +void pa_sink_bind_preferred_stream_to_a_sink(pa_sink *s) {
> > > > > > "Bind" is new terminology, and I'd like to avoid introducing new
> > > > > > terminology if possible. Also, "preferred stream" as a term doesn't
> > > > > > really make sense. So some better name for the function would be
> > > > > > desirable, but I can't immediately think of any obvious names... The
> > > > > > function is about moving streams to a sink that just became 
> > > > > > available.
> > > > > > "Move" and "streams" should be included in the name... Maybe
> > > > > > "pa_sink_move_streams_to_newly_available_sink()"? I also suggest 
> > > > > > moving
> > > > > > it away from the pa_sink namespace, because the function operates on
> > > > > > streams, not on a sink.
> > > > > That last sentence can be objected to - the function takes the sink as
> > > > > an argument, so it can be said to operate on the sink. But then the
> > > > > verb should be something that the sink does, like "take" ("move" is
> > > > > something that streams do). So pa_sink_take_streams()? Or
> > > > > pa_sink_take_streams_that_prefer_it()? I don't know. My weak 
> > > > > preference
> > > > > at this point is pa_core_move_streams_to_newly_available_sink(). It's
> > > > > quite descriptive, but unfortunately lacks the distinction that only
> > > > > those streams that prefer the newly available sink are moved.
> > > > > 
> > > > Understand what you mean here, will have a try to provide a new
> > > > function name and address the rest comments of this patch.
> > > > 
> > > > Thanks.
> > > Don't know the code at all, but from a purely English standpoint, how 
> > > about
> > > 
> > > "pa_sink_move_streams_to_newly_available_preferred_sink()"
> > > 
> > > if it's not too impossibly long for a name.
> > I'd be fine with that. It has the issue that the newly available sink
> > may not actually be preferred by any stream, so it's slightly
> > misleading, but it's nevertheless one of the better alternatives, if
> > not the best so far.
> > 
> How about pa_sink_move_stream_to_new_sink_if_preferred()?

That sounds very good to me (just replace "stream" with "streams").

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

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

Re: [pulseaudio-discuss] how to Start a pulseaudio application as a daemon with systemd

[Tanu Kaskinen]

On Thu, 2019-01-03 at 15:45 +0100, NicoHood wrote:
> On 5/21/18 11:54 AM, Tanu Kaskinen wrote:
> > On Sun, 2018-05-20 at 16:16 +0200, Christophe Lohr wrote:
> > > Le 20/05/2018 à 13:28, Tanu Kaskinen a écrit :
> > > > But what I think you should do is
> > > > disabling the pulseaudio user service in systemd, using the command
> > > > that I already gave:
> > > > 
> > > > sudo systemctl --global disable pulseaudio.socket pulseaudio.service
> > > > 
> > > > If you are using pulseaudio in the system-wide mode, you don't want
> > > > systemd starting user instances as well.
> > > 
> > > done! ;-)
> > > 
> > > Many thanks for your guidance.
> > > 
> > > The wiki page about "pulseaudio as system-wide" may be extended with 
> > > systemd materials ;-)
> > > <https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/SystemWide/>
> > > ... how to write a new  pulseaudio.service,  how to enable it, how to
> > > disable user service, etc.
> > 
> > Rather than just document how to write pulseaudio.service for the
> > system mode, we should provide and install that by default (but not
> > enable). 
> > 
> > Regarding disabling the user services - yeah, I'll add that to the wiki
> > page. Thanks for pointing that out!
> > 
> 
> Could you please provide a systemd service for system mode? I found
> serveral online, but opinions about their correctness differ. It would
> be best, if the official pulse team can give out a systemd service file.
> Even if it is just in the documentation, and not the package. But
> package would be better though.
> 
> (If it was already posted in the email list, I was unable to find it)

Creating the systemd service file is unlikely to become the highest
priority item at least for me in the foreseeable future. However, if
you submit a patch (testing first that it works), I will review it.

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

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

Re: [pulseaudio-discuss] [PATCH 3/4] move streams to new appeared sinks if they prefer these sinks

[Tanu Kaskinen]

On Wed, 2019-01-02 at 08:25 -0500, Joe wrote:
> On 1/2/19 7:55 AM, Hui Wang wrote:
> > On 2019/1/1 上午2:10, Tanu Kaskinen wrote:
> > > On Mon, 2018-12-31 at 20:01 +0200, Tanu Kaskinen wrote:
> > > > On Mon, 2018-11-05 at 09:47 +0800, Hui Wang wrote:
> > > > > diff --git a/src/pulsecore/sink.c b/src/pulsecore/sink.c
> > > > > index 63a3456e7..a2a390beb 100644
> > > > > --- a/src/pulsecore/sink.c
> > > > > +++ b/src/pulsecore/sink.c
> > > > > @@ -722,6 +722,8 @@ void pa_sink_put(pa_sink* s) {
> > > > >   /* This function must be called after the
> > > > > PA_CORE_HOOK_SINK_PUT hook,
> > > > >* because module-switch-on-connect needs to know the old
> > > > > default sink */
> > > > >   pa_core_update_default_sink(s->core, false);
> > > > > +
> > > > > +pa_sink_bind_preferred_stream_to_a_sink(s);
> > > > >   }
> > > > > /* Called from main context */
> > > > > @@ -3919,3 +3921,32 @@ void
> > > > > pa_sink_move_streams_from_oldsink_to_newsink(pa_sink *old_sink,
> > > > > pa_sink *ne
> > > > > return;
> > > > >   }
> > > > > +
> > > > > +void pa_sink_bind_preferred_stream_to_a_sink(pa_sink *s) {
> > > > "Bind" is new terminology, and I'd like to avoid introducing new
> > > > terminology if possible. Also, "preferred stream" as a term doesn't
> > > > really make sense. So some better name for the function would be
> > > > desirable, but I can't immediately think of any obvious names... The
> > > > function is about moving streams to a sink that just became available.
> > > > "Move" and "streams" should be included in the name... Maybe
> > > > "pa_sink_move_streams_to_newly_available_sink()"? I also suggest moving
> > > > it away from the pa_sink namespace, because the function operates on
> > > > streams, not on a sink.
> > > That last sentence can be objected to - the function takes the sink as
> > > an argument, so it can be said to operate on the sink. But then the
> > > verb should be something that the sink does, like "take" ("move" is
> > > something that streams do). So pa_sink_take_streams()? Or
> > > pa_sink_take_streams_that_prefer_it()? I don't know. My weak preference
> > > at this point is pa_core_move_streams_to_newly_available_sink(). It's
> > > quite descriptive, but unfortunately lacks the distinction that only
> > > those streams that prefer the newly available sink are moved.
> > > 
> > Understand what you mean here, will have a try to provide a new
> > function name and address the rest comments of this patch.
> > 
> > Thanks.
> 
> Don't know the code at all, but from a purely English standpoint, how about
> 
> "pa_sink_move_streams_to_newly_available_preferred_sink()"
> 
> if it's not too impossibly long for a name.

I'd be fine with that. It has the issue that the newly available sink
may not actually be preferred by any stream, so it's slightly
misleading, but it's nevertheless one of the better alternatives, if
not the best so far.

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

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

Re: [pulseaudio-discuss] [PATCH] alsa-mixer: Adding Jack of Front Headphone Front and Surround

[Tanu Kaskinen]

On Wed, 2019-01-02 at 20:23 +0800, Hui Wang wrote:
> On 2018/12/31 下午9:46, Tanu Kaskinen wrote:
> > On Fri, 2018-12-21 at 11:05 +0800, Hui Wang wrote:
> > > We have 2 HP desktop models which have one front headphone Jack and
> > > one front headset Jack, in the Linux kernel, these two jacks are
> > > named "Front Headphone Front Jack" and "Front Headphone Surround
> > > Jack", now adding them into the pathes conf file.
> > How do the kcontrols map to physical connectors? Is there only one
> > physical connector or two? How do different kinds of devices
> > (headphones, headsets, stand-alone mics) change the state of the two
> > kcontrols?
> There are 2 physical connectors/jacks, one is the pure headphone jack, 
> the other is the headset jack (headphone + mic).
> 
> For the headphone jack, the kcontrols are:  'Front Headphone Surround 
> Jack' and 'Headphone Playback Volume' index 1
> 
> For the headset jack, the kcontrols are: 'Front Headphone Front Jack',  
> 'Headphone Playback Volume' index 0, 'Mic Jack' and 'Mic Boost Volume'

The jack kcontrol names are unfortunate. They don't really make sense.
"Surround" normally refers to particular channels in multichannel
setup, and similarly the second "Front" in "Front Headphone Front"
would normally refer to the front channels in multichannel setup. I'm
not familiar with the kernel driver code - in case you know better,
would it be feasible to get these jack kcontrols renamed? Or are we
doomed to live with nonsensical kcontrol names forever?

I'd like to change the jack kcontrols to simply "Front Headphone Jack"
(or even simpler "Headphone Jack", since the volume element doesn't use
the "Front" prefix either). The headphone jack would use index 1 like
is done with the volume element. Or alternatively use "Headphone2" with
the headphone volume and jack kcontrols (this would be easier to
support in PulseAudio).

PulseAudio doesn't currently support any mixer controls with non-zero
index, so currently the headphone output won't have hardware volume. If
you're interested in improving that, it should be relatively easy to
fix this shortcoming. We just need a new "index" option for the
[Element] sections in the configuration files, and alsa-mixer.c then
needs to use that index instead of hardcoding the index to 0 like it
does now. We probably need also a new "alsa-name" option for the
[Element] sections, because there's probably need to have two [Element]
sections in one configuration file with the same alsa name but
different identifier. Like this:

[Element Headphone_1]
alsa-name = Headphone
volume = ...
mute = ...

[Element Headphone_2]
alsa-name = Headphone
volume = ...
mute = ...


> If we plug a headphone in either of the two jacks, the 'Surround Jack' 
> or 'Front Jack' will be true. If we plug a headset in the headset jack, 
> the 'Front Jack' and 'Mic Jack' will be true.
> 
> This is not the Dell machine, most Dell machines can't detect mic of 
> headset, so we add headset-mic, headphone-mic for them.  This HP machine 
> can detect mic of headset jack, and it doesn't support stand-alone mics too.
> 
> 
> > I think at least the headset-mic path configuration in your patch is
> > incorrect, but I don't know how it should be configured before knowing
> > how the two kcontrols behave.
> 
> After reading your comments above,  I think you are right.  And I think 
> I shouldn't touch analog-input-headset-mic.conf in the patch, since this 
> is a HP machine, and the headset jack of this machine has capability to 
> detect the mic on the headset and the kcontrols are "Mic Jack" and 
> "Headphone Front Jack". It is different from the Dell machines.

Yes, it seems that headset-mic can be left alone.

Since there are two physical connectors, I don't think we can use
analog-output-headphone for both. With your original patch, if you plug
in headphones to the headphone connector, PulseAudio will enable the
analog-output-headphone port. PulseAudio will also think that the port
has hardware volume, because the "Headphone" volume element exists, but
PulseAudio will only control the element with index 0, which has no
effect on the headphone output - it only affects the headset output. We
should assign the "Front Headphone Surround" jack to the analog-output-
headphone-2 path. That way volume control works with both connectors.

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

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

Re: [pulseaudio-discuss] [PATCH 4/4] move stream when the active_port changes

[Tanu Kaskinen]

On Mon, 2018-11-05 at 09:47 +0800, Hui Wang wrote:
> When the active port of a sink becomes unavailable, all streams from
> that sink should be moved to the default sink.
> 
> When the active port of an existing sink changes state from
> unavailable, all streams that have their "preferred_sink"
> set to the new sink should be moved to the new sink.
> 
> Signed-off-by: Hui Wang 
> ---
>  src/pulsecore/device-port.c | 16 
>  src/pulsecore/sink.c| 13 +
>  src/pulsecore/sink.h|  1 +
>  3 files changed, 30 insertions(+)
> 
> diff --git a/src/pulsecore/device-port.c b/src/pulsecore/device-port.c
> index 464c3f8a2..2604c9051 100644
> --- a/src/pulsecore/device-port.c
> +++ b/src/pulsecore/device-port.c
> @@ -92,6 +92,7 @@ void pa_device_port_set_available(pa_device_port *p, 
> pa_available_t status) {
>   * be created before port objects, and then p->card could be non-NULL for
>   * the whole lifecycle of pa_device_port. */
>  if (p->card && p->card->linked) {
> + pa_sink *sink;
>  /* A sink or source whose active port is unavailable can't be the
>   * default sink/source, so port availability changes may affect the
>   * default sink/source choice. */
> @@ -102,6 +103,21 @@ void pa_device_port_set_available(pa_device_port *p, 
> pa_available_t status) {
>  
>  pa_subscription_post(p->core, 
> PA_SUBSCRIPTION_EVENT_CARD|PA_SUBSCRIPTION_EVENT_CHANGE, p->card->index);
>  pa_hook_fire(>core->hooks[PA_CORE_HOOK_PORT_AVAILABLE_CHANGED], 
> p);
> +
> + sink = pa_sink_get_sink_from_device_port(p);
> + if (!sink)
> + return;
> + switch (p->direction) {
> +case PA_DIRECTION_OUTPUT:
> + if (sink->active_port->available == PA_AVAILABLE_NO)
> + pa_sink_move_streams_from_oldsink_to_newsink(sink, 
> p->core->default_sink, false);

This logic isn't quite right. We should move streams away from the sink
only if the active port is the same that just changed its availability
status. If the current port is something other than the port that
changed, then we should ignore the change event.

> + else
> + pa_sink_bind_preferred_stream_to_a_sink(sink);
> +
> +break;
> +case PA_DIRECTION_INPUT:
> + break;
> + }
>  }
>  }
>  
> diff --git a/src/pulsecore/sink.c b/src/pulsecore/sink.c
> index a2a390beb..9ebc18fa1 100644
> --- a/src/pulsecore/sink.c
> +++ b/src/pulsecore/sink.c
> @@ -3950,3 +3950,16 @@ void pa_sink_bind_preferred_stream_to_a_sink(pa_sink 
> *s) {
> pa_sink_input_move_to(si, s, false);
>  }
>  }
> +
> +pa_sink *pa_sink_get_sink_from_device_port(pa_device_port *p) {

This is a good helper function, but I think it would fit slightly
better in the pa_device_port namespace. So I'd rename it to
pa_device_port_get_sink().

> +pa_sink *rs = NULL;
> +pa_sink *sink;
> +uint32_t state;
> +
> +PA_IDXSET_FOREACH(sink, p->card->sinks, state)
> + if (p == pa_hashmap_get(sink->ports, p->name)) {
> + rs = sink;
> + break;
> + }
> +return rs;
> +}
> diff --git a/src/pulsecore/sink.h b/src/pulsecore/sink.h
> index 24e4678b1..693344ac3 100644
> --- a/src/pulsecore/sink.h
> +++ b/src/pulsecore/sink.h
> @@ -563,4 +563,5 @@ void pa_sink_set_reference_volume_direct(pa_sink *s, 
> const pa_cvolume *volume);
>  
>  void pa_sink_move_streams_from_oldsink_to_newsink(pa_sink *old_sink, pa_sink 
> *new_sink, bool from_user);
>  void pa_sink_bind_preferred_stream_to_a_sink(pa_sink *s);
> +pa_sink *pa_sink_get_sink_from_device_port(pa_device_port *p);
>  #endif

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

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

Re: [pulseaudio-discuss] [PATCH 3/4] move streams to new appeared sinks if they prefer these sinks

[Tanu Kaskinen]

On Mon, 2018-12-31 at 20:01 +0200, Tanu Kaskinen wrote:
> On Mon, 2018-11-05 at 09:47 +0800, Hui Wang wrote:
> > diff --git a/src/pulsecore/sink.c b/src/pulsecore/sink.c
> > index 63a3456e7..a2a390beb 100644
> > --- a/src/pulsecore/sink.c
> > +++ b/src/pulsecore/sink.c
> > @@ -722,6 +722,8 @@ void pa_sink_put(pa_sink* s) {
> >  /* This function must be called after the PA_CORE_HOOK_SINK_PUT hook,
> >   * because module-switch-on-connect needs to know the old default sink 
> > */
> >  pa_core_update_default_sink(s->core, false);
> > +
> > +pa_sink_bind_preferred_stream_to_a_sink(s);
> >  }
> >  
> >  /* Called from main context */
> > @@ -3919,3 +3921,32 @@ void 
> > pa_sink_move_streams_from_oldsink_to_newsink(pa_sink *old_sink, pa_sink *ne
> >  
> >  return;
> >  }
> > +
> > +void pa_sink_bind_preferred_stream_to_a_sink(pa_sink *s) {
> 
> "Bind" is new terminology, and I'd like to avoid introducing new
> terminology if possible. Also, "preferred stream" as a term doesn't
> really make sense. So some better name for the function would be
> desirable, but I can't immediately think of any obvious names... The
> function is about moving streams to a sink that just became available.
> "Move" and "streams" should be included in the name... Maybe
> "pa_sink_move_streams_to_newly_available_sink()"? I also suggest moving
> it away from the pa_sink namespace, because the function operates on
> streams, not on a sink.

That last sentence can be objected to - the function takes the sink as
an argument, so it can be said to operate on the sink. But then the
verb should be something that the sink does, like "take" ("move" is
something that streams do). So pa_sink_take_streams()? Or
pa_sink_take_streams_that_prefer_it()? I don't know. My weak preference
at this point is pa_core_move_streams_to_newly_available_sink(). It's
quite descriptive, but unfortunately lacks the distinction that only
those streams that prefer the newly available sink are moved.

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

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

Re: [pulseaudio-discuss] [PATCH 3/4] move streams to new appeared sinks if they prefer these sinks

[Tanu Kaskinen]

On Mon, 2018-11-05 at 09:47 +0800, Hui Wang wrote:
> When a new sink appears, all streams that have their "preferred_sink"
> set to the new sink should be moved to the new sink.
> Signed-off-by: Hui Wang 
> ---
>  src/pulsecore/sink.c | 31 +++
>  src/pulsecore/sink.h |  1 +
>  2 files changed, 32 insertions(+)

The sink_put_hook_callback() function in module-stream-restore.c is
obsolete after this change, so it should be removed.

> diff --git a/src/pulsecore/sink.c b/src/pulsecore/sink.c
> index 63a3456e7..a2a390beb 100644
> --- a/src/pulsecore/sink.c
> +++ b/src/pulsecore/sink.c
> @@ -722,6 +722,8 @@ void pa_sink_put(pa_sink* s) {
>  /* This function must be called after the PA_CORE_HOOK_SINK_PUT hook,
>   * because module-switch-on-connect needs to know the old default sink */
>  pa_core_update_default_sink(s->core, false);
> +
> +pa_sink_bind_preferred_stream_to_a_sink(s);
>  }
>  
>  /* Called from main context */
> @@ -3919,3 +3921,32 @@ void 
> pa_sink_move_streams_from_oldsink_to_newsink(pa_sink *old_sink, pa_sink *ne
>  
>  return;
>  }
> +
> +void pa_sink_bind_preferred_stream_to_a_sink(pa_sink *s) {

"Bind" is new terminology, and I'd like to avoid introducing new
terminology if possible. Also, "preferred stream" as a term doesn't
really make sense. So some better name for the function would be
desirable, but I can't immediately think of any obvious names... The
function is about moving streams to a sink that just became available.
"Move" and "streams" should be included in the name... Maybe
"pa_sink_move_streams_to_newly_available_sink()"? I also suggest moving
it away from the pa_sink namespace, because the function operates on
streams, not on a sink. It could be added to the pa_sink_input
namespace, but since the function operates on multiple streams rather
than just one, I think pa_core would be a bit better namespace (but I
don't have a very strong opinion on this).

> +pa_sink_input *si;
> +uint32_t idx;
> +pa_core *c;
> +
> +if (!s)

This should be an assertion.

> + return;
> +
> +c = s->core;
> +PA_IDXSET_FOREACH(si, c->sink_inputs, idx) {
> +if (si->sink == s)
> +continue;
> +
> +/* Skip this sink input if it is connecting a filter sink to
> + * the master */
> +if (si->origin_sink)
> +continue;

I think it't better to ensure that preferred_sink is not set when it
doesn't make sense (and it doesn't make sense with filter sinks, at
least in most cases). So rather than checking si->origin_sink here,
it's better to check this in the code that sets preferred_sink. There
are two situations where preferred_sink is set: when the user moves a
stream, and when module-stream-restore restores the user choice. It
should be sufficient to check this when the user moves the stream,
because module-stream-restore only replicates the moves done by the
user.

> +
> +/* It might happen that a stream and a sink are set up at the
> +   same time, in which case we want to make sure we don't
> +   interfere with that */
> + if (!PA_SINK_INPUT_IS_LINKED(si->state))
> +continue;
> +
> +if (si->preferred_sink != NULL && pa_streq(si->preferred_sink, 
> s->name))

pa_safe_streq() can be used to avoid the NULL check.

> +   pa_sink_input_move_to(si, s, false);
> +}
> +}
> diff --git a/src/pulsecore/sink.h b/src/pulsecore/sink.h
> index f207a094c..24e4678b1 100644
> --- a/src/pulsecore/sink.h
> +++ b/src/pulsecore/sink.h
> @@ -562,4 +562,5 @@ void pa_sink_set_reference_volume_direct(pa_sink *s, 
> const pa_cvolume *volume);
>  pa_assert(pa_thread_mq_get() || !PA_SINK_IS_LINKED((s)->state))
>  
>  void pa_sink_move_streams_from_oldsink_to_newsink(pa_sink *old_sink, pa_sink 
> *new_sink, bool from_user);
> +void pa_sink_bind_preferred_stream_to_a_sink(pa_sink *s);
>  #endif

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

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

Re: [pulseaudio-discuss] [PATCH] alsa-mixer: Adding Jack of Front Headphone Front and Surround

[Tanu Kaskinen]

On Fri, 2018-12-21 at 11:05 +0800, Hui Wang wrote:
> We have 2 HP desktop models which have one front headphone Jack and
> one front headset Jack, in the Linux kernel, these two jacks are
> named "Front Headphone Front Jack" and "Front Headphone Surround
> Jack", now adding them into the pathes conf file.

How do the kcontrols map to physical connectors? Is there only one
physical connector or two? How do different kinds of devices
(headphones, headsets, stand-alone mics) change the state of the two
kcontrols?

I think at least the headset-mic path configuration in your patch is
incorrect, but I don't know how it should be configured before knowing
how the two kcontrols behave.

(A sidenote: it would be awesome to have some documentation that
explains what combinations of headphone/headset/mic jacks exist in the
wild and how those combinations map to physical connectors. The details
of the headphone/headset/mic jack detection mess are impossible to
remember.)

> Without this change, if users plug a headset or headphone, the
> path of headphone will not be activated, and users can't see
> headphones from UI like gnome-control-center.
> 
> Signed-off-by: Hui Wang 
> ---
> For alsa-info.txt of one of machines, please access:
> https://pastebin.ubuntu.com/p/CjCGySMpM5/
> 
>  .../alsa/mixer/paths/analog-input-headset-mic.conf| 6 ++
>  .../alsa/mixer/paths/analog-output-headphones.conf| 6 ++
>  .../alsa/mixer/paths/analog-output-speaker-always.conf| 8 
>  src/modules/alsa/mixer/paths/analog-output-speaker.conf   | 8 
>  4 files changed, 28 insertions(+)
> 
> diff --git a/src/modules/alsa/mixer/paths/analog-input-headset-mic.conf 
> b/src/modules/alsa/mixer/paths/analog-input-headset-mic.conf
> index 579db6bb7..bc687b6e4 100644
> --- a/src/modules/alsa/mixer/paths/analog-input-headset-mic.conf
> +++ b/src/modules/alsa/mixer/paths/analog-input-headset-mic.conf
> @@ -35,6 +35,12 @@ state.plugged = unknown
>  [Jack Front Headphone]
>  state.plugged = unknown
>  
> +[Jack Front Headphone Front]
> +state.plugged = unknown
> +
> +[Jack Front Headphone Surround]
> +state.plugged = unknown
> +
>  [Jack Headphone Mic]
>  state.plugged = unknown
>  
> diff --git a/src/modules/alsa/mixer/paths/analog-output-headphones.conf 
> b/src/modules/alsa/mixer/paths/analog-output-headphones.conf
> index d2147c50f..2d751607c 100644
> --- a/src/modules/alsa/mixer/paths/analog-output-headphones.conf
> +++ b/src/modules/alsa/mixer/paths/analog-output-headphones.conf
> @@ -40,6 +40,12 @@ required-any = any
>  state.plugged = unknown
>  state.unplugged = unknown
>  
> +[Jack Front Headphone Front]
> +required-any = any
> +
> +[Jack Front Headphone Surround]
> +required-any = any
> +
>  [Jack Headphone]
>  required-any = any
>  
> diff --git a/src/modules/alsa/mixer/paths/analog-output-speaker-always.conf 
> b/src/modules/alsa/mixer/paths/analog-output-speaker-always.conf
> index 71f356dce..c9374e471 100644
> --- a/src/modules/alsa/mixer/paths/analog-output-speaker-always.conf
> +++ b/src/modules/alsa/mixer/paths/analog-output-speaker-always.conf
> @@ -33,6 +33,14 @@ state.unplugged = unknown
>  state.plugged = no
>  state.unplugged = unknown
>  
> +[Jack Front Headphone Front]
> +state.plugged = no
> +state.unplugged = unknown
> +
> +[Jack Front Headphone Surround]
> +state.plugged = no
> +state.unplugged = unknown
> +
>  [Jack Line Out]
>  state.plugged = no
>  state.unplugged = unknown
> diff --git a/src/modules/alsa/mixer/paths/analog-output-speaker.conf 
> b/src/modules/alsa/mixer/paths/analog-output-speaker.conf
> index 9f4dac414..536630d0a 100644
> --- a/src/modules/alsa/mixer/paths/analog-output-speaker.conf
> +++ b/src/modules/alsa/mixer/paths/analog-output-speaker.conf
> @@ -36,6 +36,14 @@ state.unplugged = unknown
>  state.plugged = no
>  state.unplugged = unknown
>  
> +[Jack Front Headphone Front]
> +state.plugged = no
> +state.unplugged = unknown
> +
> +[Jack Front Headphone Surround]
> +state.plugged = no
> +state.unplugged = unknown
> +
>  [Jack Line Out]
>  state.plugged = no
>  state.unplugged = unknown
-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

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

Re: [pulseaudio-discuss] [PATCH 1/4] change bool save_sink to char *preferred_sink

[Tanu Kaskinen]

On Sat, 2018-12-15 at 16:47 +0800, Hui Wang wrote:
> On 2018/12/12 下午9:39, Tanu Kaskinen wrote:
> > Thanks for working on this! Sorry for slow review, I hope I'll be much
> > quicker to comment on subsequent iterations.
> > 
> > On Mon, 2018-11-05 at 09:47 +0800, Hui Wang wrote:
> > > And don't move the stream in the module-stream-restore anymore,
> > > And the preferred_sink is only set when user is calling the
> > > move_to() and the module-stream-restore maintains the saving and
> > > deleting of preferred_sink.
> > > 
> > > If the target of move_to() is default_sink, preferred_sink will be
> > > cleared and the entry->device will be cleared too from database.
> > Can you split this so that the first patch only changes save_sink to
> > preferred_sink, without any changes in behaviour? That is, put the
> > "don't move the stream in the module-stream-restore" and "if the target
> > of move_to() is default_sink" logic into separate patches.
> > 
> > Also replace tabs with spaces.
> OK, got it, will addressed all comments.
> > > Signed-off-by: Hui Wang 
> [...]
> > >   }
> > >   }
> > > @@ -2176,9 +2190,10 @@ static int extension_cb(pa_native_protocol *p, 
> > > pa_module *m, pa_native_connectio
> > >   
> > >   entry->muted = muted;
> > >   entry->muted_valid = true;
> > > -
> > > -entry->device = pa_xstrdup(device);
> > > -entry->device_valid = device && !!entry->device[0];
> > > + if (device && !pa_streq(device, m->core->default_sink->name) && 
> > > !pa_streq(device, m->core->default_source->name)) {
> > > + entry->device = pa_xstrdup(device);
> > > + entry->device_valid = device && !!entry->device[0];
> > > + }
> > What's the goal here? The client tries to change an entry in the
> > stream-restore database, why should that change be ignored if the
> > current default sink happens to be the same as the new device? Maybe
> > you intended to set entry->device to NULL in this case. But I don't
> > think that's necessary either - if the client wants to unset the
> > device, it can just give NULL as the device name. I don't think you
> > need to change anything here.
> > 
> > By the way, m->core->default_sink can be NULL, so that would have to be
> > checked if this code was kept.
> 
> Actually I didn't change this part first, but I remember the stream bond 
> did not work as expected, after changed as above, it worked as expected.
> 
> Supposing sink0 is hdmi, and is playing a music over sink0, sink1 is 
> speaker,  after I unplugged the hdmi cable, the music is switched to 
> speaker,  but music->preferred_sink is still sink0-hdmi, after I plug 
> the hdmi cable again, the music should be switched back to sink0-hdmi.  
> I remember after I unplugged the cable, a user-space app call 
> extension_cb to set the music->preferred_sink to be sink1-speaker 
> (default_sink), then the music can't be switched back to hdmi anymore.
> 
> I will test it again, if it is really not needed, I will drop these code.

I would guess that it's gnome-control-center that sets the device to
speakers when you select speakers as the output. gnome-control-center
updates the routing in all stream-restore entries. Once these patches
are merged (and once a new release is made), gnome-control-center can
be fixed to not mess with the stream-restore database any more. I
believe the current gnome-control-center behaviour is a workaround for
the fact that PulseAudio hasn't so far automatically moved streams when
the default sink changes.

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

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

Re: [pulseaudio-discuss] [PATCH 2/4] move stream after default sink is changed.

[Tanu Kaskinen]

On Sat, 2018-12-15 at 14:48 +0800, Hui Wang wrote:
> On 2018/12/13 下午5:16, Tanu Kaskinen wrote:
> > On Mon, 2018-11-05 at 09:47 +0800, Hui Wang wrote:
> > > When default sink changes, the stream should be moved to new
> > > default_sink too.
> > Except if the stream's preferred sink is the old default sink.
> > 
> > > If it is user to call change default function,
> > > all stream will move to new default sink unconditionally; if it
> > > is not, will check if stream binds to old_default_sink and the
> > > active_port staus of old_default_sink, then it will move the
> > > stream conditionally.
> > Why does it matter if the default sink changed due to user request or
> > some other reason? I don't think streams should be moved
> > unconditionally when the user changes the default sink.
> 
> Supposing  the sink0 is hdmi, sink1 is analog-speaker,  and a music is 
> playing on sink0 (default_sink is sink0),  if users select the 
> analog-speaker from UI (gnome-sound-setting), the sink1 is default_sink 
> now, and the music should be played on sink1.  If the streams don't move 
> to new default_sink unconditionally, I have no idea how to let music be 
> played on sink1 here.

I don't see what the problem is - streams should by default move to the
new default sink, but if the user has at some point manually moved a
stream to sink0, making sink0 the preferred sink, then that stream
shouldn't be moved automatically. If the user doesn't want to keep that
old setting any more, they can move the stream manually to sink1, and
since sink1 is the default sink at this point, the preferred_sink will
be unset, so that stream will from then on behave like all other
streams.

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

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

Re: [pulseaudio-discuss] [PATCH 2/4] move stream after default sink is changed.

[Tanu Kaskinen]

On Mon, 2018-11-05 at 09:47 +0800, Hui Wang wrote:
> When default sink changes, the stream should be moved to new
> default_sink too.

Except if the stream's preferred sink is the old default sink.

> If it is user to call change default function,
> all stream will move to new default sink unconditionally; if it
> is not, will check if stream binds to old_default_sink and the
> active_port staus of old_default_sink, then it will move the
> stream conditionally.

Why does it matter if the default sink changed due to user request or
some other reason? I don't think streams should be moved
unconditionally when the user changes the default sink.

I think it would be logical to not care about the port unavailability
in this patch, because there's a separate patch for handling that.

> diff --git a/src/modules/module-switch-on-connect.c 
> b/src/modules/module-switch-on-connect.c
> index faa0f289f..4f01c701f 100644
> --- a/src/modules/module-switch-on-connect.c
> +++ b/src/modules/module-switch-on-connect.c

> @@ -100,29 +97,8 @@ static pa_hook_result_t sink_put_hook_callback(pa_core 
> *c, pa_sink *sink, void*
>  return PA_HOOK_OK;
>  }
>  
> -old_default_sink = c->default_sink;
> -
>  /* Actually do the switch to the new sink */

This comment isn't very helpful any more (not sure how helpful it was
before either), I'd remove it.

> -pa_core_set_configured_default_sink(c, sink->name);
> -
> -/* Now move all old inputs over */
> -if (pa_idxset_size(old_default_sink->inputs) <= 0) {
> -pa_log_debug("No sink inputs to move away.");
> -return PA_HOOK_OK;
> -}
> -
> -PA_IDXSET_FOREACH(i, old_default_sink->inputs, idx) {
> -if (i->preferred_sink != NULL || !PA_SINK_INPUT_IS_LINKED(i->state))
> -continue;
> -
> -if (pa_sink_input_move_to(i, sink, false) < 0)
> -pa_log_info("Failed to move sink input %u \"%s\" to %s.", 
> i->index,
> -pa_strnull(pa_proplist_gets(i->proplist, 
> PA_PROP_APPLICATION_NAME)), sink->name);
> -else
> -pa_log_info("Successfully moved sink input %u \"%s\" to %s.", 
> i->index,
> -pa_strnull(pa_proplist_gets(i->proplist, 
> PA_PROP_APPLICATION_NAME)), sink->name);
> -}
> -
> +pa_core_set_configured_default_sink(c, sink->name, false);
>  return PA_HOOK_OK;
>  }

> diff --git a/src/pulsecore/sink.c b/src/pulsecore/sink.c
> index 566367f9e..63a3456e7 100644
> --- a/src/pulsecore/sink.c
> +++ b/src/pulsecore/sink.c

> @@ -3886,3 +3886,36 @@ void pa_sink_set_reference_volume_direct(pa_sink *s, 
> const pa_cvolume *volume) {
>  pa_subscription_post(s->core, 
> PA_SUBSCRIPTION_EVENT_SINK|PA_SUBSCRIPTION_EVENT_CHANGE, s->index);
>  pa_hook_fire(>core->hooks[PA_CORE_HOOK_SINK_VOLUME_CHANGED], s);
>  }
> +
> +void pa_sink_move_streams_from_oldsink_to_newsink(pa_sink *old_sink, pa_sink 
> *new_sink, bool from_user) {

I think "pa_sink_move_streams_to_default_sink" would be a better name
for the function. It would also be good to have a comment explaining
when the function is used and which streams are not moved (that could
go to the header file).

> +pa_sink_input *i;
> +uint32_t idx;
> +pa_device_port *o_active_p;
> +
> +if (old_sink == new_sink)
> + return;
> +
> +if (old_sink == NULL)
> + return;

It doesn't make sense to call this function with NULL, so this check
should be an assertion instead.

> +
> +o_active_p = old_sink->active_port;

Note that not all sinks have ports, so this can be NULL.

Since we only care about the availability of the active port, I'd add a
"old_sink_is_unavailable" boolean to be used inside the loop.

> +if (pa_idxset_size(old_sink->inputs) > 0) {
> + PA_IDXSET_FOREACH(i, old_sink->inputs, idx) {
> + if (!PA_SINK_INPUT_IS_LINKED(i->state))
> + continue;
> +
> + if (!from_user && i->preferred_sink != NULL && 
> pa_safe_streq(old_sink->name, i->preferred_sink))

No need to check if i->preferred_sink is NULL, because pa_safe_streq()
checks that anyway.

> + if (o_active_p->available != PA_AVAILABLE_NO)
> + continue;
> +
> + if (pa_sink_input_move_to(i, new_sink, from_user) < 0)
> + pa_log_info("Failed to move sink input %u \"%s\" to %s.", 
> i->index,
> + pa_strnull(pa_proplist_gets(i->proplist, 
> PA_PROP_APPLICATION_NAME)), new_sink->name);
> + else
> + pa_log_info("Successfully moved sink input %u \"%s\" to 
> %s.", i->index,
> + pa_strnull(pa_proplist_gets(i->proplist, 
> PA_PROP_APPLICATION_NAME)), new_sink->name);

Logging the reason for moving the stream before calling
pa_sink_input_move_to() would be very useful.

Here's a suggestion you don't need to implement, but you can if you
want: it would be nice to have good enough logging in

Re: [pulseaudio-discuss] [PATCH 1/4] change bool save_sink to char *preferred_sink

[Tanu Kaskinen]

Thanks for working on this! Sorry for slow review, I hope I'll be much
quicker to comment on subsequent iterations.

On Mon, 2018-11-05 at 09:47 +0800, Hui Wang wrote:
> And don't move the stream in the module-stream-restore anymore,
> And the preferred_sink is only set when user is calling the
> move_to() and the module-stream-restore maintains the saving and
> deleting of preferred_sink.
> 
> If the target of move_to() is default_sink, preferred_sink will be
> cleared and the entry->device will be cleared too from database.

Can you split this so that the first patch only changes save_sink to
preferred_sink, without any changes in behaviour? That is, put the
"don't move the stream in the module-stream-restore" and "if the target
of move_to() is default_sink" logic into separate patches.

Also replace tabs with spaces.

> Signed-off-by: Hui Wang 
> ---
>  src/modules/module-device-manager.c|  2 +-
>  src/modules/module-intended-roles.c|  2 +-
>  src/modules/module-stream-restore.c| 47 +-
>  src/modules/module-switch-on-connect.c |  2 +-
>  src/pulsecore/sink-input.c | 25 +++---
>  src/pulsecore/sink-input.h |  7 ++--
>  6 files changed, 59 insertions(+), 26 deletions(-)
> 
> diff --git a/src/modules/module-device-manager.c 
> b/src/modules/module-device-manager.c
> index 15fd2..36e71584e 100644
> --- a/src/modules/module-device-manager.c
> +++ b/src/modules/module-device-manager.c
> @@ -657,7 +657,7 @@ static void route_sink_input(struct userdata *u, 
> pa_sink_input *si) {
>  pa_assert(u->do_routing);
>  
>  /* Don't override user or application routing requests. */
> -if (si->save_sink || si->sink_requested_by_application)
> +if (si->preferred_sink != NULL || si->sink_requested_by_application)

Just checking whether si->preferred_sink is set isn't enough - you need
to also check that the input is currently routed to the preferred sink.
Maybe we should have some helper, since this is a common thing to check
- perhaps pa_sink_input_is_routed_to_preferred_sink(). That's quite a
long name, though, so it's not that much better than just using
pa_safe_streq(si->sink->name, si->preferred_sink). I think the
pa_safe_streq() approach is good enough.

>  return;
>  
>  /* Skip this if it is already in the process of being moved anyway */
> diff --git a/src/modules/module-intended-roles.c 
> b/src/modules/module-intended-roles.c
> index adee51c20..98e4c241f 100644
> --- a/src/modules/module-intended-roles.c
> +++ b/src/modules/module-intended-roles.c
> @@ -175,7 +175,7 @@ static pa_hook_result_t sink_put_hook_callback(pa_core 
> *c, pa_sink *sink, struct
>  if (si->sink == sink)
>  continue;
>  
> -if (si->save_sink)
> +if (si->preferred_sink != NULL)

pa_safe_streq(si->sink->name, si->preferred_sink)

>  continue;
>  
>  /* Skip this if it is already in the process of being moved
> diff --git a/src/modules/module-stream-restore.c 
> b/src/modules/module-stream-restore.c
> index 228e9e447..276957c25 100644
> --- a/src/modules/module-stream-restore.c
> +++ b/src/modules/module-stream-restore.c
> @@ -1311,19 +1311,29 @@ static void subscribe_callback(pa_core *c, 
> pa_subscription_event_type_t t, uint3
>  mute_updated = !created_new_entry && (!old->muted_valid || 
> entry->muted != old->muted);
>  }
>  
> -if (sink_input->save_sink) {
> +if (sink_input->preferred_sink != NULL || !created_new_entry) {
>  pa_xfree(entry->device);
> -entry->device = pa_xstrdup(sink_input->sink->name);
> -entry->device_valid = true;
>  
> -device_updated = !created_new_entry && (!old->device_valid || 
> !pa_streq(entry->device, old->device));
> -if (sink_input->sink->card) {
> + if (sink_input->preferred_sink != NULL) {
> + entry->device = pa_xstrdup(sink_input->preferred_sink);
> + entry->device_valid = true;
> + } else {
> + entry->device = NULL;
> + entry->device_valid = false;
> + }
> +
> +device_updated = !created_new_entry && (!old->device_valid || 
> !entry->device_valid || !pa_streq(entry->device, old->device));

This sets device_updated to true if both old->device_valid and entry-
>device_valid are false. device_updated should be set to false in that
case.

> +
> + if (entry->device_valid == false) {
> +pa_xfree(entry->card);
> +entry->card = NULL;
> +entry->card_valid = false;
> + } else if (sink_input->sink->card) {
>  pa_xfree(entry->card);
>  entry->card = pa_xstrdup(sink_input->sink->card->name);
>  entry->card_valid = true;
>  }
>  }
> -
>  } else {
>  pa_source_output *source_output;
>  
> @@ -1641,7 +1651,7 @@ static pa_hook_result_t 

Re: [pulseaudio-discuss] [PATCH V2] introduce a special build flag to explicitly disables running from build tree

[Tanu Kaskinen]

On Fri, 2018-12-07 at 15:48 +0800, Hongxu Jia wrote:
> It is helpful to improve reproducibility build [1] since
> PA_SRCDIR/PA_BUILDDIR contains build path, disable running
> from build tree could drop these macros at precompilation.
> 
> [1] https://reproducible-builds.org/
> 
> Signed-off-by: Hongxu Jia 
> ---
>  configure.ac | 10 ++
>  src/daemon/daemon-conf.c |  6 --
>  src/daemon/main.c|  6 ++
>  src/modules/alsa/alsa-mixer.c|  4 
>  src/modules/gconf/module-gconf.c |  2 +-
>  src/modules/gsettings/module-gsettings.c |  2 +-
>  src/pulsecore/core-util.c|  4 +++-
>  7 files changed, 29 insertions(+), 5 deletions(-)

Thanks! I applied this with some minor edits in the commit message, and
I changed the "Running from build tree" log message so that it prints
the value returned by pa_run_from_build_tree() rather than printing
"yes" always.

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

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

Re: [pulseaudio-discuss] [PATCH] improve reproducibility build

[Tanu Kaskinen]

(Hongxu Jia is not subscribed to the list, so I added him to Cc.)

On Thu, 2018-12-06 at 14:17 +0500, Alexander E. Patrakov wrote:
> Hongxu Jia :
> > While running pulseaudio out of build dir (especially for cross
> > compiling), we should not expose pulseaudio build path[1], it is
> > helpful for reproducibility build[2].
> > 
> > As commit introduced [3cae4a0 doc: Add info about running pulseaudio
> > from the build dir], run pulseaudio from the build dir, __OPTIMIZE__
> > should be diabled, so add macro checking to drop PA_SRCDIR/PA_BUILDDIR
> > (in which contains build path) at precompilation.
> > 
> > [1] https://reproducible-builds.org/docs/build-path/
> > [2] https://reproducible-builds.org/
> > 
> > Signed-off-by: Hongxu Jia 
> 
> I don't believe that the doc that you are basing your decisions on is
> correct. Anyway, basing such decisions automagically on the
> optimization level is very non-obvious. Maybe it is a better idea to
> introduce a special build flag (for autotools it would be something
> like --disable-running-from-build-tree or --enable-reproducible-build)
> that explicitly disables running from build tree and thus enables a
> reproducible build?

Yes, adding a configure option with an associated define is much more
clear and reliable than using __OPTIMIZE__. I think --disable-running-
from-build-tree would be better than --enable-reproducible-build,
because the latter promises that the build will be reproducible, while
in reality there are reproducibility issues that aren't (at least yet)
addressed (PA_CFLAGS definition is one example that can cause problems,
and I wouldn't be surprised if there were other things too).

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

___
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

[Tanu Kaskinen]

On Wed, 2018-12-05 at 18:59 +0530, Arun Raghavan wrote:
> 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 defi

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

[Tanu Kaskinen]

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

> 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 now call
"rear" (which is what you seem to be suggesting), but we would have to
split the current "side" channels into "side" and "side in rear". I
don't see any practical reason for doing that separation. If we have
any real problem, it's that we sometimes incorrectly play 5.1 content
to the rear speakers (in 7.1 configuration), not that we don't
distinguish between two slightly different side channel positions.

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

___
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

[Tanu Kaskinen]

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

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

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

Re: [pulseaudio-discuss] [RFC PATCH 4/4] switch-on-connect: Do not ignore HDMI sinks

[Tanu Kaskinen]

On Wed, 2018-11-21 at 11:44 -0800, João Paulo Rechi Vita wrote:
> On Tue, Oct 9, 2018 at 2:35 AM Tanu Kaskinen  wrote:
> > On Tue, 2018-08-07 at 22:00 -0700, João Paulo Rechi Vita wrote:
> > > HDMI ports are normally present on cards connected to an internal bus,
> > > and module-switch-on-connect should switch to them when a HDMI monitor
> > > is plugged.
> > > 
> > > This is specially relevant on setups where the HDMI port of a machine is
> > > connected to a different audio card then the analog outputs, which is
> > > the case for machines with AMD graphics cards.
> > 
> > As I mentioned in an earlier mail, it's not generally a good idea to
> > switch to HDMI automatically, due to the possible lack of speakers on
> > the monitor, so do you really want to do this chage? I'm fine with this
> > patch, though, because if the decision to switch to a HDMI profile has
> > already been made, it's pretty logical to switch output to it in
> > module-switch-on-connect.
> > 
> 
> I see your point and I understand the implications. We recently
> checked the behavior on Windows and it always switches the audio to
> HDMI no matter what (even with headphones connected), so that tends to
> be the expectation from OEMs. We may change our mind at some point,
> but for now we are sticking with that policy downstream. Ideally all
> the changes we are making to support this case will be generic enough
> that they make sense upstream as well and we only have a small
> downstream patch set changing the ports / profiles priorities.
> 
> As you mentioned, when this code runs the decision to switch the card
> profile to HDMI has already been made. But on setups where one card
> has the analog ports and another card has only HDMI ports, the HDMI
> card will always switch to a HDMI profile when HDMI is connected, and
> (unless I'm missing something) the streams will be moved over to the
> HDMI sink.
> 
> Let me know if the above comment makes sense, and if you still want to
> have this patch upstream, in which case I can re-send it as a MR.

No need to re-send, I pushed this now :)

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

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