Hi, On Tue, Jun 21, 2011 at 10:48 AM, Christophe Fergeau <cferg...@redhat.com> wrote: > On Tue, Jun 21, 2011 at 12:05:56AM +0200, Marc-André Lureau wrote: >> So, the answer in short is that I don't know, but I know it can be >> addressed later, for example when we use dB, which is way better for >> emulated hw. But that needs even more work, I wanted the basics first. > > The thing is, once it's added to the protocol, we'll have to keep it around > forever. So do we have a clear way to go from what you suggest to the > future/better scale in dB? Ie will we add one more field in dB and fill > both the old and new values, will we add capabilities check to know the > format of the field, or is it something that you were planning to think > about later? >
The added volume/mute are not a criticial part of the protocol, it is optionnal. So we can simply change the message "volume" in % to "volume_db" in dB, if both parts say they have the capability to handle volume in dB. That's roughly what I had in mind. I don't see major problems with having both messages in % and dB simultaneously either, that's what PulseAudio does, afaik: pro-audio UI will use dB, while volume sliders for status & players use an arbitrary % scale. PA scale however, allows to amplify above 100%. But in our case, the emulated hardware doesn't allow this, and we could map Spice 0..100% to a different scale on the client side: 0..300%. The client is free to do whatever with the Spice scale basically. regards -- Marc-André Lureau _______________________________________________ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
