[Spice-devel] [RFC/PATCH] Bad volume scaling with Win7 guest, spice audio, and Qemu Intel HDA codec

[Wilck, Martin]

Hello,

I see a problem with input volume control on a Windows7 guest
using the qemu Intel HDA codec. In short, moving the volume slider for
the input volume from 0% to 1% under Windows results in 
the "gain" values in the emulated HW to jump from 0 to 40 (out of 74)
(looking at "st->gain_[left|right]" in hda_audio_command()). This makes
it impossible to control sound volume in the low-gain range using the
windows guest.

Here is a table of Windows slider position vs. actual gain value to
illustrate the problem ("0.5" is a slider position between 0 and 1 that
can be reached with skillful slider shifting, windows still displays the
numerical value "0"):

        slider  gain
        0.5     34
        1       40
        2       43
        3       46
        5       48
        10      54
        20      60
        50      68
        75      71
        89      73
        99      73
        100     74

For output, the situation is similar but less (1% on Win7 corresponds to
a gain value of 19/74).

I am using the spice driver connected to pulseaudio to control the
volume in the host (PA adds another level of complication which I am
going to address in a posting to pulseaudio-discuss soon). The spice-



I am using a Win7(32bit) guest on a Fedora 21 host.
  qemu-system-x86-2.1.3-6.fc21.x86_64
  spice-gtk3-0.27-6.fc21.x86_64
  pulseaudio-6.0-2.fc21.1.x86_64

By using low-level controls in a Linux VM (e.g. "amixer -c 0 set Capture
$x), I was able to set the gain levels to any value $x between 0 and 74,
just as one would expect. So this is not a problem of QEMU alone.
Rather, it's related to how the Windows HDA codec driver and the QEMU
emulated HW interact. For the Windows side I can only guess, but it
seems that Windows uses a ~30dB overall scale for the min-max range of
the input volume slider (and ~60dB for output). I'm not sure if that's
general Win7 behavior or related to the driver. According to
https://msdn.microsoft.com/en-us/library/windows/hardware/ff536251%
28v=vs.85%29.aspx, audio drivers can set volume-related registry values,
but I didn't find any of those on my system.

I experimentally changed the value of QEMU_HDA_AMP_STEPS in
hw/audio/hda-codec.c from 74 to 32, artificially reducing the dynamic
range of the HDA codec to 32 dB. This improved matters much, allowing me
to set a gain value as low as 4 (-28dB / 12.5%) from the Windows guest
at 1%. Going one step further and using 32dB dynamic range with a 0.5 dB
step size, I could even set a gain value of 5 (-29.5dB / 8%).

The "right" solution for this problem would probably be to implement
proper dB scaling in the the spice client code, as the note in the git
commit suggests
(http://cgit.freedesktop.org/spice/spice/commit/server/snd_worker.c?id=d1758b328811979beb58ff9ddb9cf4f318fa28f7).
I am not sure how difficult this might be. AFAICS it would require
changes in the general QEMU audio API to deal with dB.

While this clean solution is not available, I would suggest to decrease
the dynamic range for the the emulated Amps in the QEMU hda codec code.
AFAICS, that would also match the dynamic range of actual HD Audio HW
better. I am attaching a tentative patch that does exactly that for
input, changing nothing for output (the output volume setting behaves
acceptably for the default QEMU settings, see above). Please comment.

Regards
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: qemu-hda-codec-amp-1.patch
Type: text/x-patch
Size: 4371 bytes
Desc: qemu-hda-codec-amp-1.patch
URL: <http://lists.freedesktop.org/archives/spice-devel/attachments/20150420/4b53ba48/attachment.bin>