Re: [pulseaudio-discuss] [PATCH v9 0/8] Bluetooth A2DP codecs
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. So above change to PA_AVAILABLE_UNKNOWN seems like a good idea. But why idle/suspended transports have PA_AVAILABLE_UNKNOWN? Should not it be PA_AVAILABLE_YES? Because transport is activated and can be used. It is known that connection is working. > > > which hopefully it is just a matter doing the > > >
Re: [pulseaudio-discuss] [PATCH v9 0/8] Bluetooth A2DP codecs
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.
> > which hopefully it is just a matter doing the
> > following changes (not tested):
> >
> > diff --git a/src/modules/bluetooth/bluez5-util.c
> > b/src/modules/bluetooth/bluez5-util.c
> > index 4e4ab0cb8..429914328 100644
> > --- a/src/modules/bluetooth/bluez5-util.c
> > +++ b/src/modules/bluetooth/bluez5-util.c
> > @@ -1837,6 +1837,7 @@ static DBusMessage
> > *endpoint_set_configuration(DBusConnection *conn, DBusMessage
> > t->acquire = bluez5_transport_acquire_cb;
> > t->release = bluez5_transport_release_cb;
> > pa_bluetooth_transport_put(t);
> > +pa_bluetooth_transport_set_state(t,
> > PA_BLUETOOTH_TRANSPORT_STATE_PLAYING);
> >
> > pa_log_debug("Transport %s available for profile %s", t->path,
> > pa_bluetooth_profile_to_string(t->profile));
> >
> >
>
--
Pali Rohár
pali.ro...@gmail.com
signature.asc
Description: PGP signature
___
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
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.
> which hopefully it is just a matter doing the
> following changes (not tested):
>
> diff --git a/src/modules/bluetooth/bluez5-util.c
> b/src/modules/bluetooth/bluez5-util.c
> index 4e4ab0cb8..429914328 100644
> --- a/src/modules/bluetooth/bluez5-util.c
> +++ b/src/modules/bluetooth/bluez5-util.c
> @@ -1837,6 +1837,7 @@ static DBusMessage
> *endpoint_set_configuration(DBusConnection *conn, DBusMessage
> t->acquire = bluez5_transport_acquire_cb;
> t->release = bluez5_transport_release_cb;
> pa_bluetooth_transport_put(t);
> +pa_bluetooth_transport_set_state(t,
> PA_BLUETOOTH_TRANSPORT_STATE_PLAYING);
>
> pa_log_debug("Transport %s available for profile %s", t->path,
> pa_bluetooth_profile_to_string(t->profile));
>
>
--
Pali Rohár
pali.ro...@gmail.com
signature.asc
Description: PGP signature
___
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
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, so now we have to set the initial
transport to playing which hopefully it is just a matter doing the
following changes (not tested):
diff --git a/src/modules/bluetooth/bluez5-util.c
b/src/modules/bluetooth/bluez5-util.c
index 4e4ab0cb8..429914328 100644
--- a/src/modules/bluetooth/bluez5-util.c
+++ b/src/modules/bluetooth/bluez5-util.c
@@ -1837,6 +1837,7 @@ static DBusMessage
*endpoint_set_configuration(DBusConnection *conn, DBusMessage
t->acquire = bluez5_transport_acquire_cb;
t->release = bluez5_transport_release_cb;
pa_bluetooth_transport_put(t);
+pa_bluetooth_transport_set_state(t, PA_BLUETOOTH_TRANSPORT_STATE_PLAYING);
pa_log_debug("Transport %s available for profile %s", t->path,
pa_bluetooth_profile_to_string(t->profile));
--
Luiz Augusto von Dentz
___
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
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. -- Luiz Augusto von Dentz ___ 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
Hi Pali, On Mon, Apr 22, 2019 at 4:40 PM Pali Rohár wrote: > > In this patch series was dropped all patches which are already applied > in git master branch. > > There are 2 new patches: "Fix A2DP codec API to provide information about > data buffer" and "policy: Set initial A2DP profile which bluez already > activated". > > So with profile/codec switching we can relay on bluez functionality of > remembering the last used codec. > > Changes in v9: > * Fix parsing uuids of remote SEP endpoints > * Remove wrong assert in FastStream codec > * Fix logic in SBC codec for checking if two config/capabilities are >compatible > * Split SBC UHQ into two sub-codecs - it is needed to ensure that >remote endpoint does not choose bitpool for dualchannel configuration >(38) and channel mode for stereo configuration -- which is SBC middle >quality configuration > * Simplify encode and decode functions for aptX codec > * Change FastStream codec code which handles bugs in firmware > * Fix A2DP codec API to provide information about data buffer > * Ensure that module-bluez5-discover does not unload >module-bluez5-device when codec switching operation is in progress > * Set initial A2DP profile which bluez already activated > > Pali Rohár (8): > bluetooth: Fix A2DP codec API to provide information about data buffer > bluetooth: Add A2DP aptX and aptX HD codecs support > bluetooth: Add A2DP FastStream codec support > bluetooth: Add more variants of SBC codec > bluetooth: policy: Reflect a2dp profile names > bluetooth: Implement A2DP codec switching and backchannel support > bluetooth: policy: Treat bi-directional A2DP profiles as suitable for > VOIP > bluetooth: policy: Set initial A2DP profile which bluez already > activated > > configure.ac| 36 ++ > src/Makefile.am | 8 + > src/modules/bluetooth/a2dp-codec-api.h | 17 +- > src/modules/bluetooth/a2dp-codec-aptx.c | 400 + > src/modules/bluetooth/a2dp-codec-faststream.c | 453 ++ > src/modules/bluetooth/a2dp-codec-sbc.c | 751 > +++- > src/modules/bluetooth/a2dp-codec-util.c | 26 +- > src/modules/bluetooth/bluez5-util.c | 476 ++- > src/modules/bluetooth/bluez5-util.h | 39 +- > src/modules/bluetooth/module-bluetooth-policy.c | 152 +++-- > src/modules/bluetooth/module-bluez5-device.c| 440 +- > src/modules/bluetooth/module-bluez5-discover.c | 3 +- > 12 files changed, 2416 insertions(+), 385 deletions(-) > create mode 100644 src/modules/bluetooth/a2dp-codec-aptx.c > create mode 100644 src/modules/bluetooth/a2dp-codec-faststream.c > > -- > 2.11.0 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), I recommend to leave the last used endpoint when reconnecting and not try to revert it to back to the highest priority, well in fact I don't think we need to evaluate priorities anymore since the policy in BlueZ will be to always connect to the last endpoint (in case of being the initiator), except perhaps for the very first time we had connected in which case there is no last used in which case BlueZ will use the registration order as priority. -- Luiz Augusto von Dentz ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
