Received-SPF: pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
From:   Marek Czerski <ma.czerski@gmail.com>
Date:   Mon, 19 Oct 2020 12:08:24 +0200
Message-ID: <CAOOgLvqcSoaM7hgdzUA+JK0qgHfjhKKcLS2ScWNvsEiEj4xkoQ@mail.gmail.com>
Subject: avrcp: possible race condition during connection establishment
To:     linux-bluetooth@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Hi all,

I was looking into, so called, absolute volume control that was
introduced in AVRCP v1.4. What I want to achieve is to send audio from
android smartphone to linux based device running bluez and make the
volume control on the smartphone side to control the volume on the
device. So the device is the a2dp sink + avrcp CT/TG and the phone is
a2dp source + avrcp CT/TG.

I assume that if all is working correctly then on the dbus the Volume
property of the org.bluez.MediaTransport1 will be changed by the
volume control of the phone and changes made to this property from the
device would propagate to the phone volume slider.

This is not happening and what I believe is the cause is that
AVRCP_EVENT_VOLUME_CHANGED event registration request sent from the
phone is rejected by the bluez. I can see that on the wireshark snoop
from the device's bluetooth adapter. And on wireshark I see that
AVRCP_EVENT_VOLUME_CHANGED event registration is sent by the phone
before bluez initializes session->supported_events variable (not
really sure about that). I think that this rejection makes the phone
to not send SetAbsoluteVolume commands to the device on volume change.

To test my theory i changed the session_init_control function in the
profiles/audio/avrcp.c to call first target_init and then
controller_init. This caused  the AVRCP_EVENT_VOLUME_CHANGED event not
been rejected and the volume control from the phone works as expected.

After reading AVRCP specification I did not find any reason for the CT
on the phone side not to send event registration immediately after the
AVCTP connection establishment. So I believe that bluez should not
reject event registration in this case.

Best Regards,
Marek Czerski