Bug 1305834 - Sound control from Linux client is not consistent
Sound control from Linux client is not consistent
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: virt-viewer (Show other bugs)
7.3
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Virt Viewer Maint
SPICE QE bug list
:
Depends On: 1264100
Blocks:
  Show dependency treegraph
 
Reported: 2016-02-09 06:16 EST by Andrei Stepanov
Modified: 2016-06-02 05:28 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-05-31 04:19:36 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 Andrei Stepanov 2016-02-09 06:16:14 EST
Increasing sound volume in a GuestOS directly affects "Master volume" in Linux client.

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.

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
Comment 1 Fabiano Fidêncio 2016-02-09 06:22:22 EST
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.
Comment 3 Victor Toso 2016-02-09 07:09:39 EST
(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
Comment 4 Victor Toso 2016-02-09 07:14:48 EST
(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*.
Comment 5 Andrei Stepanov 2016-02-09 07:36:55 EST
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.
Comment 6 Victor Toso 2016-02-09 07:46:41 EST
(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.
Comment 7 Andrei Stepanov 2016-02-09 08:07:32 EST
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.
Comment 8 Andrei Stepanov 2016-02-09 08:14:59 EST
remote-viewer doesn't behave like any other app. For example, increasing volume in Firefox doesn't affect on main playback's volume level.
Comment 9 Victor Toso 2016-02-09 08:25:15 EST
(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.
Comment 10 Andrei Stepanov 2016-02-09 08:33:00 EST
I can confirm that Rhythmbox has the same behaviour as remote-viewer.
Comment 11 Andrei Stepanov 2016-02-09 09:49:51 EST
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.
Comment 12 Victor Toso 2016-02-10 04:37:40 EST
(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.
Comment 13 Andrei Stepanov 2016-02-17 04:44:29 EST
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
Comment 14 xiaodwan 2016-02-23 01:46:27 EST
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
Comment 15 Victor Toso 2016-02-23 04:12:22 EST
(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
Comment 16 Victor Toso 2016-05-13 11:17:56 EDT
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
Comment 17 Andrei Stepanov 2016-05-30 11:46:41 EDT
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.
Comment 18 Victor Toso 2016-05-30 15:22:25 EDT
(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.
Comment 19 Victor Toso 2016-05-31 04:19:36 EDT
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.

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