linux-bluetooth.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
To: Marijn Suijten <marijn.suijten@somainline.org>
Cc: "linux-bluetooth@vger.kernel.org"
	<linux-bluetooth@vger.kernel.org>,
	Sonny Sasaka <sonnysasaka@chromium.org>
Subject: Re: [PATCH BlueZ] audio/transport: Only store volume when also emitting DBus prop change
Date: Mon, 9 Aug 2021 11:37:00 -0700	[thread overview]
Message-ID: <CABBYNZK9Hsf3zL7t62hnOkF1hm=UZNvVj_SQDx2Hxj7d0sB0sA@mail.gmail.com> (raw)
In-Reply-To: <20210808143555.100258-1-marijn.suijten@somainline.org>

Hi Marijn,

On Sun, Aug 8, 2021 at 7:35 AM Marijn Suijten
<marijn.suijten@somainline.org> wrote:
>
> By setting a2dp->volume early in set_volume() the resulting call to
> media_transport_update_volume() when an AVRCP reply is received will
> likely see the same volume received (unless the peer rounded it to
> another value) and bail on equality, before emitting a DBus property
> change.  This results in DBus clients not being made aware of the change
> unless the peer is an audio source (that receives a notification about
> changed volume, instead of a command to _set_ a new volume), where
> set_volume() immediately raises the DBus signal.
>
> This issue is observed when playing back audio to headphones through an
> AbsoluteVolume-enabled audio server like PulseAudio, which does not
> receive the "Volume" change (while the peer does change volume) when
> setting this property externally using ie. dbus-send.

Have you confirmed this works with the likes of PulseAudio, afaik
there was some problem when introducing this because the event may
cause a double change on the volume so the server needs to be able to
handle the volume == local volume, anyway if the headset rounds and
the values doesn't match I guess the server will need to be smart
enough to not trigger another volume change otherwise it could cause a
loop where the server request x but the headset rounds to y over and
over. If the server never reacts if volume != local volume and instead
just updates the local volume, which is probably the behavior we want,
then I should be safe to apply this change.

> ---
>  profiles/audio/transport.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/profiles/audio/transport.c b/profiles/audio/transport.c
> index 8248014ae..d158fc97a 100644
> --- a/profiles/audio/transport.c
> +++ b/profiles/audio/transport.c
> @@ -659,14 +659,14 @@ static void set_volume(const GDBusPropertyTable *property,
>         if (a2dp->volume == volume)
>                 return;
>
> -       a2dp->volume = volume;
> -
>         notify = transport->source_watch ? true : false;
> -       if (notify)
> +       if (notify) {
> +               a2dp->volume = volume;
>                 g_dbus_emit_property_changed(btd_get_dbus_connection(),
>                                                 transport->path,
>                                                 MEDIA_TRANSPORT_INTERFACE,
>                                                 "Volume");
> +       }
>
>         avrcp_set_volume(transport->device, volume, notify);
>         return;
> --
> 2.32.0
>


-- 
Luiz Augusto von Dentz

  parent reply	other threads:[~2021-08-09 18:37 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-08 14:35 [PATCH BlueZ] audio/transport: Only store volume when also emitting DBus prop change Marijn Suijten
2021-08-08 14:54 ` [BlueZ] " bluez.test.bot
2021-08-09 18:37 ` Luiz Augusto von Dentz [this message]
2021-08-09 20:26   ` [PATCH BlueZ] " Marijn Suijten
2021-08-09 20:35     ` Luiz Augusto von Dentz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CABBYNZK9Hsf3zL7t62hnOkF1hm=UZNvVj_SQDx2Hxj7d0sB0sA@mail.gmail.com' \
    --to=luiz.dentz@gmail.com \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=marijn.suijten@somainline.org \
    --cc=sonnysasaka@chromium.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).