Bug 969432 - Sound volume in guest should not affect the host's volume
Sound volume in guest should not affect the host's volume
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: qemu (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Fedora Virtualization Maintainers
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-05-31 08:05 EDT by Vojtěch Boček
Modified: 2013-08-30 20:23 EDT (History)
20 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-08-30 20:23:02 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Vojtěch Boček 2013-05-31 08:05:11 EDT
Description of problem:
Sound volume in guest affects volume in host. This is very annoying when testing multiple installations, as the VM will set host's volume to about 80% after every installation or boot of live cd.

It only works if volume in guest is higher than volume in host.

Version-Release number of selected component (if applicable):
Fedora 19
libvirt-1.0.5.1-1.fc19.x86_64
pulseaudio-3.0-7.fc19.x86_64

How reproducible:
100%

Steps to Reproduce:
1. Set volume to host to 10% (don't mute it)
2. Start live.iso of F19 in guest
3. Use volume up key or the GUI slider in guest

Actual results:
Volume in host changes to value in the guest.

Expected results:
Volume in host should stay the same.
Comment 1 Kamil Páral 2013-05-31 08:56:15 EDT
Actually I see this very often even if I don't adjust the volume in the guest. It's very irritating, because one moment my sound volume is fine and the next moment my sound volume is deafening.
Comment 2 Cole Robinson 2013-06-11 16:03:18 EDT
I'm seeing this even with totem on F19: set host sound to 0, open totem, adjust app volume there, host volume changes as well. AFAIK it isn't supposed to work like that. (and I can reproduce with rhythmbox)

Maybe totally unrelated or maybe there's some pulseaudio issue that we are all hitting. Kamil, can you reproduce with totem or another audio app?
Comment 3 Kamil Páral 2013-06-12 05:21:55 EDT
(In reply to Cole Robinson from comment #2)
That is actually an expected behavior. Apps influence the master volume when over-exceeding it. It's called "flat volumes" and it controlled by /etc/pulse/daemon.conf and flat-volumes = yes. I never liked the implementation of this feature, but for apps it more or less works.

The major difference between apps and VMs is that:

1) The app remembers its previous volume and sets it on start, but only in a relative manner. E.g. if you have master volume 80% and Totem 80%, then quit Totem, lower master volume to 20% and start Totem, it has 20% volume (it was on 100% relative-to-master volume before, and it is on 100% relative volume again). Which means the app never increases your master volume on start.

This doesn't seem to work with VMs, the initial volume after boot is always the same in the guest.

2) Changes of master volume propagate into apps. If you lower your master volume from 100% to 50%, the volume in app decreases by half as well.

This doesn't seem to work with VMs, no changes are propagated. So if you decrease your host volume from 50% to 20%, the guest volume still displays 50%. If you touch it even slightly (moving to 49% or 51%), the host volume jumps up (for some reason not just to 51%, but something about 75%, which I do not understand at all).

3) The app never adjusts its volume by itself (I have never seen any), you need to do it manually. So if you manually increase the volume of Totem, the master volume goes up, everything is expected.

It seems that some processes in VMs adjust the volume sometimes, and thus your master volume jumps up automatically, without your action, making everything extra-loud. A default install of F19 raised my host volume to 75% during boot, and then to 100% when starting the GNOME initial experience video.



I am of that opinion that host volume and guest volume should not be interconnected in any way. I don't know whether an app can choose not to honor flat-volumes setting, but it definitely makes sense for VMs.

The other approach would be to set the guest volume on start in the same approach the apps do it - relatively, never exceed host volume. And also *make sure that no process increases that guest volume automatically*. This is much trickier approach to take, of course.

A guidance of someone from pulseaudio team would probably be beneficial here.
Comment 4 Cole Robinson 2013-06-12 12:46:26 EDT
elmarco, I know you've done qemu work WRT setting spice volume, do you know what's going on here, or what our options are?
Comment 5 Marc-Andre Lureau 2013-06-12 19:29:51 EDT
I think a VM audio shouldn't be treated differently from any other application. When raising the audio to the maximum from  inside the VM, I expect to hear the audio at maximum loudness: this is in essence what flat-volume provides. I don't understand the need for special casing here, quite the contrary because we want the VM to be as real as possible.
Comment 6 Kamil Páral 2013-06-13 05:40:06 EDT
Hello Marc,

I have summarized the different behavior between apps and VMs in comment 3. If VMs behaved exactly as apps, I would have no problem. But no other app increases my master volume unsolicitedly, just the VMs.

Is is possible to force the guest system to work in the same way as a usual app does (both way volume synchronization, no automatic volume changes, the previous volume restored on boot)?
Comment 7 Marc-Andre Lureau 2013-06-13 05:57:29 EDT
(In reply to Kamil Páral from comment #6)
> Hello Marc,
> 
> I have summarized the different behavior between apps and VMs in comment 3.
> If VMs behaved exactly as apps, I would have no problem. But no other app
> increases my master volume unsolicitedly, just the VMs.

All GNOME (using GStreamers) and PulseAudio based application should. What apps are you talking about?

> Is is possible to force the guest system to work in the same way as a usual
> app does (both way volume synchronization, no automatic volume changes, the
> previous volume restored on boot)?

The guest volume is restored on boot (this is guest issue anyway)

You should be able to disable flat-volumes in /etc/pulse/daemon.conf
Comment 8 Kamil Páral 2013-06-13 07:14:48 EDT
(In reply to Marc-Andre Lureau from comment #7)
> All GNOME (using GStreamers) and PulseAudio based application should. What
> apps are you talking about?

Citing from comment 3:
It seems that some processes in VMs adjust the volume sometimes, and thus your master volume jumps up automatically, without your action, making everything extra-loud. A default install of F19 raised my host volume to 75% during boot, and then to 100% when starting the GNOME initial experience video.

I investigated more deeply. Say I have a master volume at 20% and rhythmbox at 20%. After I boot such VM (and touch its volume bar or it adjusts automatically, as mentioned above), my master volume jumps say to 75%. The rhythmbox is still at 20%, so it is not louder. Any audio played after this time, e.g. sound notification from IM client, is of course very loud, at 75%. If I move the master volume back to 20%, the rhythmbox level adjusts accordingly, to 5%. So I need to make it manually in sync again with the master volume. This makes Rhythmbox + virt-manager combination a total showstopper. I need to shuffle the volume bars all day long.


Also, don't we forget that not all guest systems work with gstreamer and/or pulseaudio? Will they affect my host volume? Can we even fix it there somehow?

> 
> > Is is possible to force the guest system to work in the same way as a usual
> > app does (both way volume synchronization, no automatic volume changes, the
> > previous volume restored on boot)?
> 
> The guest volume is restored on boot (this is guest issue anyway)

I know these are guest issues. That's why I think the flat-volumes should be disabled in VMs, because you can never fix all guest issues. And why the user should be punished for incorrect implementation or bugs in their VM guests?

You see, my end user problem is that if I use VMs, my volume is jumping insanely. My sound is very loud out of the blue, my apps are quieter relative to the master volume, it's irritating. I should not be punished for having flat volumes.

> 
> You should be able to disable flat-volumes in /etc/pulse/daemon.conf

Yes I can. I'm talking about the default here.
Comment 9 Marc-Andre Lureau 2013-06-13 09:53:29 EDT
(In reply to Kamil Páral from comment #8)
> > You should be able to disable flat-volumes in /etc/pulse/daemon.conf
> 
> Yes I can. I'm talking about the default here.

I disagree, a guest or an app should be able to reach 100% volume if it has volume at 100%. Configure your VM properly or disable flat-volume if it doesn't work for you.
Comment 10 Kamil Páral 2013-06-13 11:21:51 EDT
Even if I hadn't usually dealt with Fedora in a default state (LiveCD -> fresh install), there would be hardly anything to "configure". I can report a multitude of bugs, of course. But I imagine some of them will end up like this:

me: please don't increase volume on initial login
gnome: why? we want to make sure you hear the introductory video properly
me: yes, that would make sense on bare metal, but I'm using virtualization and I have the sound level already set to a pleasant level. I don't need adjustments in the guest, they are propagated into host and it makes it very loud
gnome: we don't want to distinguish between bare metal and virtualized systems. this is something your VM hypervisor should take care about.

I have a feeling that flat-volume approach is targeted at applications. The misbehaving apps can be easily fixed. But to target a whole operating system with it? There are too many components, this can never work in a way it is supposed to.

I'd like to stress out that I don't care that much _personally_, because I know how to work around this easily (by disabling flat-volumes on the host). But I pity all the general users who don't know that (VirtualBox users are not affected by this problem, by the way). And I believe we could/should do better, "DIY" approach won't help them much. But I'm not seeing any constructive ideas here, and I am not experienced enough in this area to suggest anything better than I already did.
Comment 11 Marc-Andre Lureau 2013-06-13 11:39:08 EDT
You seem to agree that a system already configured with the right volume should keep its volume settings. I don't see why VM should be further muted by the client and be a special case.

It seems to me that your problem is mainly with Fedora/Gnome starting with 100% volume... which can be equally annoing on bare metal or inside a VM. But as you said, there might be a good reason to make the audio loud during initial setup.
Comment 12 Kamil Páral 2013-06-13 12:00:20 EDT
I'll start reporting the individual issues (host volume not propagated into guest - neither initial volume nor its changes; gnome raising volume on first boot; guest volume changes adjusting host volume incorrectly) and reference them here. I first wanted to know whether they is an interest to solve this "globally", e.g. by disabling flat-volumes or by some other trick. Solving this on a system component level will be much more difficult. But I'll at least try.
Comment 13 Cole Robinson 2013-08-30 20:23:02 EDT
Since elmarco has basically said WONTFIX and he's the expert here, I don't think continuing to track this report is useful. Closing

Note You need to log in before you can comment on or make changes to this bug.