Volume control gets out of sync with the actual sound volume

Can you try to select in the canbus settings RZC/Toyota/Rav4/2013-2018.AMP to see if this is still happening?

It still happens, though, subjectively, divergence is a bit less severe, but it's still easily reproducible.
The reason I'm stuck with Prado is that it has camera view button working (along with everything else -- door open/close, AC status). With RAV4 selected OEM camera only switches on in reverse (and vehicle info app does not seem to support it and shows an empty screen).

do you notice volume differences when actively switching between apps?

I don't think so. Most of my audio comes from Android Auto, and I didn't test with other sources. Will try later today.

try to play with different protocols.

@MihaiFlorin What do you mean by "different protocols"? Different car selection in the canbus selection menu? If so, I've already tried a bunch of RAV4 and Prado models. Newer ones don't seem to work well (I think toyota made a major change in their canbus protocols around 2020). Among the older models (₂₀₁₀-2018) that do seem to work, all seem to have this issue.

According to Toyota docs (https://attachments.priuschat.com/attachment-files/2023/06/238345_cistsdes.pdf):

the CAN communication speed is
much faster than BEAN or AVC–LAN. When the vehicle control system uses BEAN or AVC–LAN, which have
a slower communication speed than CAN, it means that the system control could be delayed by the slow
speed.

This sounds exactly what I see -- head unit tells canbox to update the volume faster than canbox can talk to the amplifier, and some volume changes probalby get lost. If updates are slow enough, everything works. Based on how many volume "clicks" get missed, we're sending volume updates about 50% faster than the canbox can handle.

If there's a way to slow down auto-repeat rate on volume buttons, that may mitigate the issue.

I don't have JBL sound.

That's likely the culprit in my case as it's the link between the amp and the canbox that is slow. If the volume is changed directly on the head unit, the canbox is probably not involved at all other than, maybe, providing volume key signals.

On my box the series of events goes roughly like this:

• press the key on the wheel
• canbox sends key press event via serial port to the head unit.
• head unit sees that it's a vol+/vol- key, and kicks "change the volume" machinery to do the job.
• if the speakers are driven by the head unit, then all it needs to do is tweak the level directly on the head unit and we're done. I suspect that's the reason things work fine on your car, but not mine.
• if we need to deal with JBL amp, head unit sends a "set volume" command to canbox.
• canbox sends command to JBL amp over AVC-LAN
• JBL eventually responds. (no clue if that's the root cause of the issue)
• canbox considers things do be done. The extra roundtrip to canbox, to the amp, and back slows things down. It it takes longer than the time till the next volume change needs to be processed, we may have a problem.

All of the above is pure speculation on my part. I do not have the source code to either the canbox or the head unit apps responsible for the volume control.

I will try capturing canbus log when this happens, perhaps that would give me more details to confirm or refute my hunch.

I've seen a "save CAN log to a file" in the menu. Does anybody know where that log file gets saved? Does it go somewhere on a USB stick, or gets saved somewhere on head unit's internal flash?

I think I may be on to something. I've turned on canbus logging on the screen and I immediatelly notice something odd.
When I press volume control buttons I see the head unit sending two commands back to back:

@ WR 2e 84 02 07 XX Z1
@ WR 2e 84 02 07 YY Z2
@ FF

According to https://github.com/icarome/VwRaiseCanbox 2e is prefix, 84 is function ID (volume in this case) and 02 is the payload length. 07 is always the same, XX and YY correlate with the volume and Z1/Z2 are checksum values.

The funny part is that the XX in the first command has the wrong volume value, but YY in the second command always matches the correct value I see on the screen. @FF as far as I can tell is some sort of acknowledgement from the canbox, and that gets us to the interesting part.

The wrong value sent by the first commend acts rather oddly. At high hanges it decrements by 1, then by two and decrements by 3 at the low volume. That looks as if someone was implementing some sort of non-linear volume control and we somehow ended up trying to set both curves simultaneously. The fact that the canbox usually only acks the last command makes me think that the first command may have been sent unintentionally.

I wonder why the head unit is writing two commands with a different value back-to-back.

Vol  XX   YY comment
35 0x3e 0x23 OK
34 0x3d 0x22 OK
33 0x3c 0x21 OK 
32 0x3b 0x20 OK
31 0x3a 0x1f OK 
30 0x39 0x1e OK @ 4924
29 0x38 0x1d OK @ 4947
28 0x37 0x1c OK @ 4970
27 0x36 0x1b OK @ 4996
26 0x35 0x1a OK @ 5016 -- first time XX/YY commands are separated by another command and get separate FF ack.
25 0x34 0x19 OK @ 5039
24 0x33 0x18 OK @ 5063
23 0x32 0x17 OK @ 5085
22 0x30 0x16 OK @ 5107 -- XX decrements by 2. Why? Is XX linearly maps 0-0x38 range onto 0-0x24 used by onscreen volume?
21 0x2e 0x15 OK @ 5131 -- XX-=2, there's another reply before FF ack.
20 0x2c 0x14 OK @ 5152
19 0x2a 0x13 OK @ 5174
18 0x28 0x12 OK @ 5197
17 0x26 0x11 OK @ 5219
16 0x24 0x10 OK @ 5238
15 0x22 0x0f OK @ 5261
14 0x20 0x0e OK @ 5284
13 0x1e 0x0d OK @ 5309
12 0x1c 0x0c OK @ 5333
11 0x1a 0x0b OK @5355
10 0x18 0x0a OK @5375 -- again, XX/YY commands get separated, each with its own FF reply.
9  0x16 0x09 OK @5401 -- there's a pending command before XX, so there are two FF replies before YY is sent.
8 0x14 0x08 OK @ 5427 -- ditto, only now there's another write after XX
7 0x12 0x07 OK @ 5448
6 0x10 0x06 OK @ 5471 
5 0x0e 0x05 OK @ 5493
4 0x0c 0x04 OK @ 5517
3 0x09 0x03 OK @ 5540
2 0x06 0x02 OK @ 5562
1 0x03 0x01 OK @ 5585
0 0x00 0x00 OK @5606

Below are sample screenshots from the video.
Normal sequence -- volume=30, two writes with different values, one FF ack:

Volume=26 and volume=8 -- each write gets its own 0xFF ack:

The good news is that head unit does not seem to be bottlenecked by the communication with the canbox, so my theory that canbox can't keep up with the volume updates was wrong.

However, that double command sent with different values, and the fact that only one of them is usually acknowledged, suggests that one of them does get lost. Should only one of them be sent?

Here's the canbus log: