Using Melody 5.x (specifically 5.6rc3), volume changes using the headset controls resulted in an ABS_VOL notification. Currently evaluating Melody 7.2 and this no longer appears to be the case – with A2DP and AVRCP profiles connected and after starting an A2DP stream, issuing VOLUME <LEVEL/UP/DOWN> commands to the module results in an ABS_VOL notification as expected, however using the headset controls changes the volume silently (volume change verified by querying the link volume using volume ).
Is this change by design, and is there a config parameter somewhere I can set to re-enable the notifications for remote volume changes?
Can you elaborate what you are testing against i.e. Android or iOS plus what you are using to stream the music with i.e. spotify, etc? Do you have a log file showing this?
So we’re using the BC127 as an A2DP source, connected to a Microchip dsPIC33 series MCU via a uart control link and I2s audio data link. Streaming audio to a set of AKG K845BT headphones.
For testing / development, we’ve implemented a USB->uart passthrough mode in the dsPIC firmware allowing us to interact directly with the BC127 module from a PC terminal app. Terminal log below from a session with the 7.2 firmware. The final two ‘volume 10’ commands were sent to query volume level after changing volume using the headset controls – you’ll notice that the volume level has been changed, but there was no ABS_VOL notification.
list LIST 0CA694528B7F A2DP AVRCP OK open 0CA694528B7F A2DP PENDING OPEN_OK 10 A2DP 0CA694528B7F ROLE_OK 0CA694528B7F M OPEN_OK 11 AVRCP 0CA694528B7F music 10 play OK AVRCP_PLAY 11 A2DP_STREAM_START 10 volume 10 10 A2DP 9 OK volume 10 up OK ABS_VOL 11 84 volume 10 10 A2DP A OK volume 10 down OK ABS_VOL 11 76 volume 10 10 A2DP 9 OK volume 10 10 A2DP 8 OK volume 10 10 A2DP 9 OK
The log from a 5.6rc3 session (which we’d been using previously) looks similar (apart from changes in notification format), except that we receive AVRCP notifications when volume is changed using the headset controls. These are very useful, as they allow us both to limit the volume adjustment range (our application is medical) by detecting and countermanding attempts to set volume levels out of range. Also allows to provide consistent UI notifications on our device for volume changes initiated from the controller and from the headset.
The final 3 ‘ABS_VOL=xx’ lines represent notifications of volume changes initiated using the headset controls.
list LIST 0CA694528B7F HFP A2DP AVRCP OK open 0CA694528B7F A2DP OPEN_OK A2DP ROLE_OK 0CA694528B7F M ROLE_OK 0CA694528B7F S OPEN_OK AVRCP music play OK AVRCP_PLAY volume up OK ABS_VOL=80 volume HFP=0 MIC_MUTE=OFF A2DP=10 OK volume down OK ABS_VOL=72 volume HFP=0 MIC_MUTE=OFF A2DP=9 OK ABS_VOL=80 ABS_VOL=72 ABS_VOL=64 volume HFP=0 MIC_MUTE=OFF A2DP=8 OK
I am not sure why you are not seeing the ABS_VOL responses using the 7.x firmware vs the 5.x. What I have confirmed using the below script is that the 7.x firmware is able to get and display the ABS_VOL responses on both sides of the link (source/sink), again log files are below.
BC127 - Absolute volume test.zip (483 Bytes)
These are the log files.
In that …source.txt, it looks like you’re setting the volume each time by sending commands to the BC127. That works fine for me too. The scenario I’m having difficulty with is when the BC127 is acting as source and the connected sink changes the volume via AVRCP (in my case, using two buttons on the AKG headset). If you take another look at the logs in my previous message, you’ll see that the old firmware provided ABS_VOL notifications when this happened, whereas the new firmware doesn’t. The volume change works, but you have to query the BC127 volume level explicitly to detect the change. We could do this by querying the volume periodically, but it’ll introduce some latency/complexity and shouldn’t be necessary.
I don’t have a device that I explicitly know sends ABS_VOL commands to the source but I have just tested
- BC127 (6.1.5 firmware) + Phillips SHB3165 headphones
- iPhone 4 + Phillips headphones
When testing between the BC127 and the headphones there were no volume notifications and when with the iPhone and headphones the volume adjustment on the headphone did not affect the level shown on the iPhone hence I am not convinced there is a reverse path.
The 5.x firmware is really old, can you test to see if the 6.x firmware outputs them? If it does not then whatever changed was a long time ago and it is unlikely to change back given we have not had anyone asking for it.
There has to be a reverse path, as the BC127 is aware of the volume changes when queried explicitly with both firmware versions – it just doesn’t issue a notification on 7.2
Don’t have any diskits to hand – just a few of our devices with embedded modules, and need a custom hardware jig to reprogram those that’s in an office on the other side of the country
Did evaluate 6x firmware a year or more back and don’t remember having this particular issue – didn’t bother going with it though, as didn’t offer any new features we needed at the time and we had a lot of validated miles on 5.6
The fine control over volume increments provided by 7.x IS useful to us however, so would like to make the change now.
May be over there next week, if so I’ll reprogram a device with 6x firmware and confirm either way.
@mlw playing with this some more, I see the headset play/pause controls both affect the stream state AND results in melody notifications in 7.2 (as they did in 5.6). Not doing so for the volume control notifications strikes me as a fairly glaring API inconsistency.
Can you test 6.1.5? This is effectively a reference release for which a lot of customers have been happy for several years, 5.x is probably 3/4 years old now.
Won’t have access to hardware to reprogram one of my boards until I visit the Dublin office later in the week, but did find a board running 6.0.32 from our last upgrade risk/benefit evaluation exercise. It behaves in a manner consistent with 5.6 – volume changes initiated using the headset controls result in a notification.
With both 5.6 and 6.0.32, I see that opening an A2DP link results in the following notifications
OPEN_OK 10 A2DP
ROLE_OK 0CA694528B7F M
ROLE_OK 0CA694528B7F S
OPEN_OK 11 AVRCP
I.e. I get notifications for both master and slave HCI roles.
With 7.2, I just get a single ROLE_OK notification – this may be ‘M’ or ‘S’ – the assignment seems fairly random. This may well be a red herring – 7.2 fails to provide notifications relating to volume changes initiated using headset controls, regardless of which HCI role is indicated.
I can’t actually find a mention/definition of the HCI roles in the bluetooth core spec, and the melody documentation is sparse on this. AVRCP protocol defines a controller and target – is this what is meant by HCI Master/Slave in the melody context, or is the HCI role some lower level concept?
Another update here. Playing with 7.2 firmware in a terminal window, I’ve twice had a situation where issuing local volume commands results in ackowledgements (‘OK’), but no ‘ABS_VOL’ notification. No obvious trigger for this condition, but in both cases it’s persisted until next device reset.
@mlw Got a chance to program another device with firmware 6.1.5 yesterday and I can confirm that the notification behaviour is consistent with 5.6 – i.e. volume changes initiated using headset controls result in an ABS_VOL notification.
So looks like the absence of corresponding notifications in 7.2 is a regression / undocumented API change of some sort?
It might be, we changed the ADK from CSR between the two releases so maybe something in there. Difficult to say without the firmware team specifically looking into it. You are going to need to raise this with your commercial channel to get a proper ticket raised. Otherwise use 6.1.5 as it is a solid build which a lot of people are using.
Thanks Matt - by commercial channel, I take it you mean our distributor? More concerned about the 44.1/48K issues raised in another thread – I’ll raise that with them.