Creating this bug to track volume-change issues between guest and client. I believe that big part of these issues are in QEMU that calls spice-server with the wrong volume value (proportionally) but the solution could be done in the using vdagent to check/sync audio properly; This is also related to https://bugzilla.redhat.com/show_bug.cgi?id=1012868 as we are trying to sync volume between client and guest using the agent but the server sends volume-change with different value of the one just set by the agent and usually higher then the right value. Main issues when setting guest volume; 1) F21(client) and F21(guest) - The value sent by spice-server is always higher then the updated value in the guest; 2) F21(client) and Windows 7(guest) - Same as 1) 3) Windows 7(client) to Windows XP(guest): Setting 100% in the guest is 74% in the client; Example: client: Fedora 21 (all spice components from git master) guest: Fedora 21 (latests from f21) volume in both before: 32768 or -18.06 dB (50%) setting volume with `pacmd set-sink-volume 0 volume` setting 10000 (around 15%), spice-gtk receives 22102 (33%) setting 40000 (around 61%), spice-gtk receives 53970 (82%) setting 50000 (around 76%), spice-gtk receives 59110 (90%) setting 60000 (around 91%), spice-gtk receives 63736 (97%) setting 65000 hits the maximum in the client (65536)
The main problem is that the volume value is without unit. It's probably never been written, but it is in our TODO list to use dB instead.
(In reply to Marc-Andre Lureau from comment #1) > The main problem is that the volume value is without unit. It's probably > never been written, but it is in our TODO list to use dB instead. Great. That means that spice_server_playback_set_volume would also need to change to dB as well, correct?
(In reply to Victor Toso from comment #2) > Great. That means that spice_server_playback_set_volume would also need to > change to dB as well, correct? yes, although we need API compatibility, so we can add functions or flags on the interfaces. I'd try with iface flags (like spice_char_device_flags), also need to bump major/minor for new fields. I would keep the volume uint16 representation, but it needs a db mapping, probably similar to PulseAudio (see pa_sw_volume_from/to_dB family)
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/spice/spice-server/issues/29.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.