Retrieve volume from the connected bluetooth device #671
Replies: 5 comments 32 replies
-
|
I can possibly help with the BlueALSA setup, but I have no knowledge of camilladsp. To give specific help I would need to know which version of BlueALSA you are using. Also, please could you clarify what you want to happen when the volume buttons on the iphone are pressed. Should the pico ignore these volume requests, or should they be somehow sent to camilladsp?
|
Beta Was this translation helpful? Give feedback.
-
|
Sorry I sent my question after one more evening on the subject and I realize now that I wasn't clear at all. So, currently i'm running a gadget audio on a rasp pico 2W. So basically my rasp act as an USB audio sound card for my laptop. I would like to do something similar with a bluetooth audio input. I compiled the latest bluez-alsa commit in the master branch as I saw that aplay now offers volume option. I also tried to link bluealsa-aplay to a mixer using the option "--mixer-device=hw:CARD=2 --mixer-name=PCM" (also tried the version 4.1.1 in this case ). At the end, my question doesn't concern camiladsp, but to answer your question, I use the alsa loopback as sink for bluealsa-play, then as source for camiladsp. |
Beta Was this translation helpful? Give feedback.
-
|
OK, so first you need to read the manual pages for bluealsa and bluealsa-aplay. I am assuming that camilladsp does not implement its own ALSA mixer device, so you need to use a script similar to your usb one to read the Bluetooth volume setting from its ALSA mixer or from D-Bus and then "send it to camilladsp". When using the latest bluez-alsa sources, the simplest way to tell bluealsa-aplay to disable BlueALSA's internal volume management is with the option Now comes the hard part. I recommend you should read the bluealsa-plugins manual page to understand the options available to you when using the BlueALSA mixer. If you intend to use only one phone connected at a time, then you may find it easiest to use the mixer in single-device mode (this is explained in the manual). The main point to note is that when the phone disconnects, then its volume control disappears from the mixer, so your script needs to be able to cope with that event. An alternative to using the ALSA mixer is to use BlueALSA's D-Bus interface. python has a D-Bus module. See the org.bluealsa.PCM1 manual page for details of the D-Bus API. |
Beta Was this translation helpful? Give feedback.
-
|
If I understand correctly when using the command : I should not be able to change the volume from my phone ? But I can. I can open the mixer with I tried to add this in my ~/.asoundrc file Did I completly misunderstood the behaviour of the --volume=none option ? |
Beta Was this translation helpful? Give feedback.
-
|
At last I made some progress ! I found that the PDU 0x31 I see is a volume change event and it's dropped as the volume change event isn't in the supported event list ( In profiles/audio/avrcp.c:avrcp_handle_register_notification() ). Why ? Because profiles/audio/avrcp.c:target_init() is called twice (don't know why) , first version 0x0105 is find, then version 0x0103. I tried to change the code to allow volume event change whichever the version and it work! At last mixer is impacted when I change the volume on my phone ! So now, this is more an hack than a fix, and I have to figure out where this version came from. It's handled in sdp.c but it doesn't seem obvious at all . |
Beta Was this translation helpful? Give feedback.
-
That is version 1.4 of the bluetooth AVRCP specification, which is the version that first introduced absolute volume control. I don't have an Android phone, but I wonder if you can select which AVRCP version to use from somewhere (possibly in the developer options?) You may have to reboot the phone after changing such option before the change will take effect. |
Beta Was this translation helpful? Give feedback.
-
|
Sorry, just looked at the source code more carefully, and it appears that volume up/down events are ignored by the passthrough handler code. I can't test this here, but it looks as if my first reading of the code was wrong. |
Beta Was this translation helpful? Give feedback.
-
|
On android default version of AVRCP is 1.5. You can change it, but in my case it didn't change anything in my log, which is weird. |
Beta Was this translation helpful? Give feedback.
-
No, it is called only once. The first call you see is actually BTW the patch in the issue comment link I provided earlier is actually for the bluetooth daemon, not the kernel code as I incorrectly stated in that thread. It checks that the device is "Category 2" before enabling AbsoluteVolume control, so is more generally applicable than the patch you have used. Until this is fully understood, your best option is probably to continue to use a patched bluetooth daemon. If I can find a convincing explanation, and hopefully a work-around, then I will write a wiki page on the use of remote volume control with A2DP. But for now I don't know if the problem you are seeing is true of all Android devices, or only certain OS versions, or only certain vendors, nor do I know why it is happening or if there is any sequence of actions on the phone which can fix it. |
Beta Was this translation helpful? Give feedback.
-
|
I've had a look at the Android bluetooth source code, and found this commit: commit 397eabe64261b3bad5164b7deb472e33b79d283a
Author: Antoine SOULIER <[email protected]>
Date: Fri Apr 7 21:22:27 2023 +0000
[avrcp] Fix version of controller
The AVRCP controller version should be set to 1.4 when
absolute volume is supported. Android Car target reads
this attributes and match the version. Leads to unexpected
behaviour of disabling absolute volume control.
Bug: 258826589
Tag: #feature
Test: On device
Change-Id: Id54106d90027d81c19c131d1013920a0b8a74e4e
diff --git a/system/stack/avrc/avrc_api.cc b/system/stack/avrc/avrc_api.cc
index 8bf95942c9..762d6f9ac0 100644
--- a/system/stack/avrc/avrc_api.cc
+++ b/system/stack/avrc/avrc_api.cc
@@ -981,10 +981,14 @@ static BT_HDR* avrc_pass_msg(tAVRC_MSG_PASS* p_msg) {
*
*****************************************************************************/
uint16_t AVRC_GetControlProfileVersion() {
+ char volume_disabled[PROPERTY_VALUE_MAX] = {0};
+ osi_property_get("persist.bluetooth.disableabsvol", volume_disabled, "false");
+
uint16_t profile_version = AVRC_REV_1_3;
char avrcp_version[PROPERTY_VALUE_MAX] = {0};
osi_property_get(AVRC_CONTROL_VERSION_PROPERTY, avrcp_version,
- AVRC_1_3_STRING);
+ strncmp(volume_disabled, "true", 4) == 0 ? AVRC_1_3_STRING
+ : AVRC_1_4_STRING);
if (!strncmp(AVRC_1_6_STRING, avrcp_version, sizeof(AVRC_1_6_STRING))) {
profile_version = AVRC_REV_1_6;So basically any Android build before April 2023 will always report version 1.3 for its AVRCP controller. Any build which includes that commit (I don't know which releases or updates, if any, have been made since that date) will report version 1.4 if absolute volume is enabled, or 1.3 if it is disabled. So, for BlueALSA A2DP remote volume control to work with Android, the Android build must include that commit. That commit first appears in Android 14 |
Beta Was this translation helpful? Give feedback.
-
|
It seems that Android completeley changed its bluetooth implementation with Android 11, and then completely changed it again with Android 13. So its is possible that AbsoluteVolume was fixed in version 11, broken in version 13, then fixed again in version 14. That would fit with the problem reported here, the fix reported in #498 (comment), and my own reading of the Android source code. If anyone could test and confirm that suggestion , then please do report here. |
Beta Was this translation helpful? Give feedback.
-
|
Having looked some more at the Android source, and also LineageOS source, I'm now convinced that AVRCP absolute volume control from an Android phone to a Bluez sink has never worked, because Android has always reported its AVRCP controller service version as 1.3 (the version that is selected by the UI applies only to the AVRCP target service). Bluez always refuses to apply Absolute volume if the service version is less than 1.4. So I now believe that previous reports of it working may have been mistaken - perhaps they were actually seeing local volume control in the phone, as reported here. This may be changed in Android 14, depending on the effect of the commit referenced above. The Android code base is huge, and partitioned across very many repositories, so it is difficult to be certain of the effect of any code fragment in isolation without the ability to test. So my conclusions here may yet be completely wrong. However, I think the only workaround at present is to patch Bluez, at least until Android 14 has been tested. |
Beta Was this translation helpful? Give feedback.
-
That is 100% but for vanilla AOSP Android phones. Various vendors could modify that to workaround some issues. So, it might be true that someone has seen Android phone with working absolute volume - I've never seen such though. For me, volume control only has worked with iPhones. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for this precision. The linked patch looks like the modification I made in avrcp.c. |
Beta Was this translation helpful? Give feedback.
-
Hello.
I'm trying to setup a rasp pico 2W as an bluetooth receiver then use camilladsp to do some room equalization and finaly output the result through a DAC.
I setup almost everything correctly, but the volume need to be controlled by camilladsp ( for the loudness filter) and not from the bluetooth transmitter ( ie my phone ).
I tried a lot of options in bluealsa-aplay, like specify the mixer of an another device, but I didn't succed. The volume always seems to be like softwarely controlled in the bluetooth stream.
So is it possible to retrieve the volume from bluetooth device in any way ? :)
Regards
Beta Was this translation helpful? Give feedback.
All reactions