Bug 1305834

What's the spice-gtk version?
I do believe this bug may be duplicated of https://bugzilla.redhat.com/show_bug.cgi?id=1012868, which is already fixed by Victor.

(In reply to Andrei Stepanov from comment #0)
> Increasing sound volume in a GuestOS directly affects "Master volume" in
> Linux client.

Because that how flat-volume logic works with PulseAudio.

> 
> The bug is independent from GuestOS. GuestOS can be Linux or Windows.
> 
> There are two main problems:
> 
> A. Increasing volume in GuestOS works fine. As guest's volume goes up,
> client's Master volume also goes up. But, volume decreasing is broken. It is
> impossible to turn the volume down. When you turn volume down at guest's,
> client's volume stays at the same level. In conclusion: increasing works,
> decreasing doesn't.

We need to have two parameters for volume here, in order to understand the problem. I'll be using % as measurement to keep this easy. The % is always based in the 100% of master-volume.

A) If master-volume in the client is 40% and app-volume is 20%.
A.1) Increase volume in the GuestOS to 60%
A.2) Volume in the app-volume should be *around* 60%
A.3) Due the flat-volume logic, the master-volume also increases to the max app-volume which is not 60%
A.4) Decreasing the volume in the GuestOS will decrease the app-volume in the Client as well at somewhat similar degree.
A.5) We don't mess with client-side master-volume, that is pulseaudio.

> 
> B. The second problem is very-very irritating.
> Steps are:
> 1. Go to Linux client. Start some application, that can play sounds. Play
> natively any song.
> 2. At the same time, go to guest OS & turn volume up.
> 3. This doesn't affect the currently playing song. Any new
> sounds/application will have much higher volume. As a result, we have the
> song that has previous volume level, and new sounds that are much higher.
> 
> If you are using headphones, you really can be dazzled by this unexpected
> behaviour. 
> 
> virt-viewer-2.0-6.el7.x86_64
> spice-server-0.12.4-15.el7.x86_64

Same thing.

I'd close this as NOTABUG if I understood everything correctly

(In reply to Fabiano Fidêncio from comment #1)
> What's the spice-gtk version?
> I do believe this bug may be duplicated of
> https://bugzilla.redhat.com/show_bug.cgi?id=1012868, which is already fixed
> by Victor.

Yes, the volume-jumps should be fixed by volume-sync protocol.

The volume-sync protocol tries to sync app-volume from client (like virt-viewer volume given by pulseaudio) to the guest master volume. After the volume-sync is done, Guest master volume and Client app-volume should be somewhat paired*.

I rise UP volume on a GuestOS. __Immediately__ after that I turn down the volume in the same RV session. It stays on the maximum level. I cannot turn down volume. There are no excuses for this behaviour. <--- This is real bug.

About the second problem, I was a victim of this behaviour several times. My headphones made me real pain several times. <--- This is how we care about our customers.

(In reply to Andrei Stepanov from comment #5)
> I rise UP volume on a GuestOS. __Immediately__ after that I turn down the
> volume in the same RV session. It stays on the maximum level. I cannot turn
> down volume. There are no excuses for this behaviour. <--- This is real bug.
>

Could you open the Volume Control in the Applications Tab and check if the volume of remote-viewer decreases after you decrease in the Guest? If yes, then I don't see a bug in remote-viewer or spice-gtk

> About the second problem, I was a victim of this behaviour several times. My
> headphones made me real pain several times. <--- This is how we care about
> our customers.

Remote-Viewer should behave like a normal desktop application in this field. You can try with music App and video App and see if remote-viewer behaves the same.

Also, you could check if disabling flat-volume logic in the client does what you expect.

Volume increasing in a GuestOS has direct influence on Client's master Playback volume. As it is increased it cannot be reduced.

I can confirm that "Sound" from RHEL7->Settings shows that volume for remote-viewer decreases as I decrease volume in the Guest. But, main playback's volume on Client's stays the same. It was increased, but not decreased.

remote-viewer doesn't behave like any other app. For example, increasing volume in Firefox doesn't affect on main playback's volume level.

(In reply to Andrei Stepanov from comment #7)
> Volume increasing in a GuestOS has direct influence on Client's master
> Playback volume. As it is increased it cannot be reduced.

That's correct on flat-volume logic. Spice-gtk does not specify to change master volume in client-side, only the App volume for Playback and Record.
PulseAudio change the Playback/Record master volume when we increase the App volume and PulseAudio does not change it when we decrease App volume (due flat-volume logic)

> I can confirm that "Sound" from RHEL7->Settings shows that volume for
> remote-viewer decreases as I decrease volume in the Guest. But, main
> playback's volume on Client's stays the same. It was increased, but not
> decreased.

Try with totem and rhythmbox. Firefox is a browser, every tab could behave as a music player so they may have their reasons to handle that differently. This is not our case here.

Feel free to open yet another bug against flat-volume logic but so far, our App is a well-behaved App in volume.

I can confirm that Rhythmbox has the same behaviour as remote-viewer.

Can we fix this bug in the same way as Firefox controls sound volume? Just affect on a volume control within rv-connection? Firefox does this. Why we cannot take the same approach for remote-viewer? Personally, I take answer "Blame the flat-volume logic of pulseaudio" only as a excuse. Think about rv-session as a independent tab or window in Firefox.

(In reply to Andrei Stepanov from comment #11)
> Can we fix this bug in the same way as Firefox controls sound volume? Just
> affect on a volume control within rv-connection? Firefox does this. Why we
> cannot take the same approach for remote-viewer? Personally, I take answer
> "Blame the flat-volume logic of pulseaudio" only as a excuse.

I'm not blaming PulseAudio at all.  It is just how it works.  It has great benefits for our App, such as being able to have real 100% playback volume of the client when we set 100% of playback volume in the Guest.

This is the expected behavior.

There are a lot of complains about flat-volume logic, mostly due Apps not behaving well.  I know that this was a problem for browsers because it can load some flash that can set your audio to 100% for instance.

> Think about rv-session as a independent tab or window in Firefox.

But it is not:
- We only have one source of playback (Guest);
- We only have one volume app to control;

This is how desktop application works and I don't think is good idea to change this behavior; Otherwise we should change that for Totem, Rhythmbox and so on.

https://bugzilla.redhat.com/show_bug.cgi?id=1012868#c18 
+ 
https://bugzilla.redhat.com/show_bug.cgi?id=1012868#c10
explain the rationale around this

I can reproduce it following the steps in comment 0 on rhel7.2 release version with a Ubuntu guest.

$ rpm -q virt-viewer spice-server
virt-viewer-2.0-6.el7.x86_64
spice-server-0.12.4-15.el7.x86_64

(In reply to xiaodwan from comment #14)
> I can reproduce it following the steps in comment 0 on rhel7.2 release
> version with a Ubuntu guest.

Thanks. This bug should be solved when the dependency is also solved (bug 1264100)

When the volume-sync is in, we will have the volume of application and the volume of the guest synced upon connection. This would avoid volume jumps in the client (e.g: guest is playing music with 100% and when we connect with virt-viewer, the client master could raise up to 100% due flat-volume logic in pulseaudio).

However, from the comment 12, please note that raise the volume in the client with virt-viewer is expected like it does happen with other applications such as totem or rhythmbox

Andrei, could you please verify, based on comment #15 that this bug could be closed?

Minimum requirements for volume-sync are:
spice-protocol-0.12.11-1.el7
spice-vdagent-0.14.0-11.el7
spice-gtk-0.26-6.el7

and in case you are testing on migration:
spice-0.12.4-17.el7

It is not clear about the 'Minimum requirements'. I think that a solution should be independent from a guest OS, if this is the case, I am not interesting in : spice-vdagent-0.14.0-11.el7

Client is current RHEL7.3:

spice-glib-0.31-2.el7.x86_64
spice-gtk3-0.31-2.el7.x86_64
spice-protocol-0.12.11-1.el7.noarch
virt-viewer-2.0-7.el7.x86_64

Guest is current RHEL7.3:

spice-glib-0.31-2.el7.x86_64
spice-vdagent-0.14.0-13.el7.x86_64
spice-protocol-0.12.11-1.el7.noarch
spice-server-0.12.4-17.el7.x86_64
spice-gtk3-0.31-2.el7.x86_64

The problem exists.

(In reply to Andrei Stepanov from comment #17)
> It is not clear about the 'Minimum requirements'. I think that a solution
> should be independent from a guest OS, if this is the case, I am not
> interesting in : spice-vdagent-0.14.0-11.el7

The solution depends on the agent so it depends on the agent's version.

> 
> Client is current RHEL7.3:
> 
> spice-glib-0.31-2.el7.x86_64
> spice-gtk3-0.31-2.el7.x86_64
> spice-protocol-0.12.11-1.el7.noarch
> virt-viewer-2.0-7.el7.x86_64
> 
> Guest is current RHEL7.3:
> 
> spice-glib-0.31-2.el7.x86_64
> spice-vdagent-0.14.0-13.el7.x86_64
> spice-protocol-0.12.11-1.el7.noarch
> spice-server-0.12.4-17.el7.x86_64
> spice-gtk3-0.31-2.el7.x86_64
> 
> The problem exists.

Can you clarify your problem once more? We discussed this for a while now, comment #3 states that comment #0 is expected and we should close it as NOTABUG.
Please, re-read the comments and be sure that you don't want to fix pulseaudio behavior.

Based on discussions on IRC, comment #13 onward were related to volume-jumps due to lack of volume synchronization between client and guest.

Sticking to this original bug instead, this is not a bug but a expected behavior from a Desktop with pulseaudio backend which has flat-volume logic enabled. A step-by-step explanation of volume changes is on comment #3

An user that is bothered with this behavior should consider disabling flat-volume logic in pulseaudio configuration.

If one finds the volume in the client _jumping_ in any situation, please file a different bug for it.