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

["Marc-André Lureau" <mlureau@redhat.com>]

Hi

----- Original Message -----
> 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%).

Very nice! It is way better indeed. I think your patch looks good too.

> 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.

That would be indeed a welcome improvement.

> 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.

Please send a git formatted patch to the ML:
http://wiki.qemu.org/Contribute/SubmitAPatch

thanks a lot