[derwood]

Just upgraded from PPA build 16164 to PPA build 19954. System is Athlon LE1640 on Ubuntu 9.04 32bit.
Audio is on-board SPDIF to SPDIF on AltecLansing speakers.
On build 16164 I could control volume level of all audio streams using the XBMC remote. On 19954, volume control works on anything that is *not* an AC3 stream. Any AC3 stream, I can still see the volume slider moving left and right, but there is no change in the volume.

pastebin info here: http://pastebin.com/m6603ddaf

[Krieg]

You can't control the volume when you are doing pass-through. You have to do it in your receiver.

[derwood]

I could with build 16164. Why not now?
And, why only AC3 streams? Why not MP2, MP3, LPCM, etc also..
To people that are non-technical, using 2 different remotes for volume control depending on the type of audio doesn't make sense at all.
Doesn't seem logical.

[Jaco2k]

I could with build 16164. Why not now?
And, why only AC3 streams? Why not MP2, MP3, LPCM, etc also..
To people that are non-technical, using 2 different remotes for volume control depending on the type of audio doesn't make sense at all.
Doesn't seem logical.

It is a technological limitation of digital audio - this has been answered before but in order to control the volume of the digital stream some form of conversion would need to be done inside the XBMC box and that would interfere with the purity of the signal - the point is to pass through the digital stream untouched and let the receiver do it all.

[Krieg]

I could with build 16164. Why not now?

That's not possible, if you could then you were not doing pass-through and something was wrong.

Pass-through means that the program (XBMC) will not decode anything, it will just pass the stream completely untouch to the next device, in this case the receiver.

[gnif]

To give a more detailed reason why the volume control doesnt/cant work for passthrough.

SPDIF/IEC958 is ac3 encoded data, not raw PCM (sound). That means it is compressed with channel information that you receiver can understand. If we were to fiddle with the data by attenuating it, it would no longer be valid ac3 data, but a corrupt data stream.

To make it possible to attenuate ac3/dts data, XBMC would need to decode the ac3 back to pcm, attenuate each channel, then re-encode it back to ac3 to send to the reciever. This would be very CPU expensive, and with the current hardware around, only high end machines could cope with it. Also, this would decrease the audio quality due to the lossy nature of AC3 and DTS.

One day we might be able to add that feature, but for now, only realtime encoding is possible, not decode -> attenuate -> re-encode.