Bug 1012868 - missing client --> guest audio volume synchronization may cause volume jumps on seamless migration or volume change in guest
missing client --> guest audio volume synchronization may cause volume jumps ...
Status: CLOSED DEFERRED
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: spice-gtk (Show other bugs)
6.5
Unspecified Unspecified
medium Severity medium
: rc
: 6.8
Assigned To: Victor Toso
SPICE QE bug list
:
Depends On:
Blocks: 1259442 1259446
  Show dependency treegraph
 
Reported: 2013-09-27 05:43 EDT by mazhang
Modified: 2016-09-20 00:41 EDT (History)
16 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1259442 1259446 (view as bug list)
Environment:
Last Closed: 2015-10-08 09:36:06 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)
spice debug (157.66 KB, text/plain)
2013-09-27 05:54 EDT, mazhang
no flags Details

  None (edit)
Description mazhang 2013-09-27 05:43:11 EDT
Description of problem:
Doing seamless migration between RHEL6U5 host, client sound gets louder after migration done.

Version-Release number of selected component (if applicable):

host:
RHEL6U5
qemu-kvm-0.12.1.2-2.404.el6.x86_64

client:
FC18
virt-viewer-0.5.4-3.fc18.x86_64

How reproducible:
100%

Steps to Reproduce:
1.boot up guest
#/usr/libexec/qemu-kvm \
-M rhel6.5.0 \
-cpu Opteron_G4 \
-m 2G \
-smp 2,sockets=1,cores=2,threads=1 \
-enable-kvm \
-name rhel6u5 \
-uuid 990ea161-6b67-47b2-b803-19fb01d30d12 \
-smbios type=1,manufacturer='Red Hat',product='RHEV Hypervisor',version=el6,serial=koTUXQrb,uuid=feebc8fd-f8b0-4e75-abc3-e63fcdb67170 \
-k en-us \
-rtc base=localtime,clock=host,driftfix=slew \
-nodefaults \
-monitor stdio \
-qmp tcp:0:6666,server,nowait \
-boot menu=on \
-bios /usr/share/seabios/bios.bin \
-global PIIX4_PM.disable_s3=0 \
-global PIIX4_PM.disable_s4=0 \
-drive file=/home/rhel6u5.raw,if=none,id=drive-scsi-disk,format=raw,cache=none,werror=stop,rerror=stop \
-device virtio-scsi-pci,id=scsi0 \
-device scsi-disk,drive=drive-scsi-disk,bus=scsi0.0,scsi-id=0,lun=0,id=scsi-disk,bootindex=1 \
-netdev tap,id=hostnet0,vhost=on \
-device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:39:13:2c \
-device virtio-balloon-pci,id=balloon0 \
-vga qxl \
-spice port=5900,disable-ticketing,seamless-migration=on \
-device intel-hda,id=sound0,bus=pci.0 \
-device hda-duplex \

2.do seamless migration with play a song in guest.
(qemu) client_migrate_info spice 10.66.106.9 5900
(qemu) migrate -d tcp:10.66.106.9:5800,spiceport=5900,spicehost=10.66.106.9

3.

Actual results:
after migration done, client sound gets louder.

Expected results:
keeping client sound.

Additional info:
virt-viewer-0.5.6-7.el6.x86_64 also hit this problem.
Comment 1 mazhang 2013-09-27 05:54:38 EDT
Created attachment 803853 [details]
spice debug
Comment 3 RHEL Product and Program Management 2013-10-13 21:54:30 EDT
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.
Comment 4 CongDong 2013-10-24 06:17:42 EDT
I can't reproduce this with 
virt-viewer-0.5.6-8.el6.x86_64.

Steps:
1. Prepare two rhel6.5 hosts.
   On host-A:
    1). create nfs server, add the nfs server to the storage pool.
    2). create a guest "fedora" with spice listen on 0.0.0.0 + qxl + spicevmc and a sound device, configure the image file on the nfs-pool
    3). Add the connection to host-B with virt-manager
    4). # setsebool virt_use_nfs 1
   On host-B:
    1). Add the nfs server on host-A to the storage pool
    2). Add the connection to host-A with virt-manager
    3). # setsebool virt_use_nfs 1

2. On host-A, Start the guest and play a song.
3. On host-A, Connect the guest with virt-viewer, make sure can hear the song.
  #  virt-viewer fedora
4. Migrate the guest to host-B

Result:
After the migration, the sound didn't change.

Could you test it with virt-viewer-0.5.6-8.el6.x86_64?
Comment 5 mazhang 2013-10-30 23:05:58 EDT
Hi Cong,

Just test with virt-viewer-0.5.6-8.el6.x86_64, also hit this problem.

qemu-kvm-0.12.1.2-2.415.el6.x86_64
guest:rhel6u5

Thanks,
Mazhang.
Comment 6 CongDong 2013-10-31 00:59:12 EDT
(In reply to mazhang from comment #5)
> Hi Cong,
> 
> Just test with virt-viewer-0.5.6-8.el6.x86_64, also hit this problem.
> 
> qemu-kvm-0.12.1.2-2.415.el6.x86_64
> guest:rhel6u5
> 
> Thanks,
> Mazhang.

Thanks , I can reproduce the problem now.


Version:
virt-viewer-0.5.6-8.el6.x86_64


Steps:

1. Prepare two rhel6.5 hosts(A and B) for the migration.
Configure bridge network "br0" on A and B.

2. edit "/etc/qemu-ifup" on A and B
#!/bin/sh
switch=br0
/sbin/ifconfig $1 0.0.0.0 up
/usr/sbin/brctl addif ${switch} $1

3. Prepare the guest img file on a nfs-server, and mount it on A and B
A: # mount <nfs-server>/$dir  /NFS
B: # mount <nfs-server>/$dir  /NFS

4. Run the guest on A:
#/usr/libexec/qemu-kvm -M rhel6.5.0 -cpu Opteron_G4 -m 2G -smp 2,sockets=1,cores=2,threads=1-enable-kvm -name rhel6u5 -uuid 990ea161-6b67-47b2-b803-19fb01d30d12 -smbios type=1,manufacturer='Red Hat',product='RHEV Hypervisor',version=el6,serial=koTUXQrb,uuid=feebc8fd-f8b0-4e75-abc3-e63fcdb67170 -k en-us -rtc base=localtime,clock=host,driftfix=slew -nodefaults -monitor stdio -qmp tcp:0:6666,server,nowait -boot menu=on -bios /usr/share/seabios/bios.bin -global PIIX4_PM.disable_s3=0 -global PIIX4_PM.disable_s4=0 -drive file=/NFS/s.img,if=none,id=drive-scsi-disk,format=raw,cache=none,werror=stop,rerror=stop -device virtio-scsi-pci,id=scsi0 -device scsi-disk,drive=drive-scsi-disk,bus=scsi0.0,scsi-id=0,lun=0,id=scsi-disk,bootindex=1 -netdev tap,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:80:7e:6f -device virtio-balloon-pci,id=balloon0 -vga qxl -spice port=5900,addr=0.0.0.0,disable-ticketing,seamless-migration=on -device intel-hda,id=sound0,bus=pci.0 -device hda-duplex

5. Prepare the host B:
# /usr/libexec/qemu-kvm -M rhel6.5.0 -cpu Opteron_G4 -m 2G -smp 2,sockets=1,cores=2,threads=1-enable-kvm -name rhel6u5 -uuid 990ea161-6b67-47b2-b803-19fb01d30d12 -smbios type=1,manufacturer='Red Hat',product='RHEV Hypervisor',version=el6,serial=koTUXQrb,uuid=feebc8fd-f8b0-4e75-abc3-e63fcdb67170 -k en-us -rtc base=localtime,clock=host,driftfix=slew -nodefaults -monitor stdio -qmp tcp:0:6666,server,nowait -boot menu=on -bios /usr/share/seabios/bios.bin -global PIIX4_PM.disable_s3=0 -global PIIX4_PM.disable_s4=0 -drive file=/NFS/s.img,if=none,id=drive-scsi-disk,format=raw,cache=none,werror=stop,rerror=stop -device virtio-scsi-pci,id=scsi0 -device scsi-disk,drive=drive-scsi-disk,bus=scsi0.0,scsi-id=0,lun=0,id=scsi-disk,bootindex=1 -netdev tap,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:80:7e:6f -device virtio-balloon-pci,id=balloon0 -vga qxl -spice port=5900,addr=0.0.0.0,disable-ticketing,seamless-migration=on -device intel-hda,id=sound0,bus=pci.0 -device hda-duplex -incoming tcp:0:5800

6. Connect the guest on Client machine with remote-viewer
# remote-viewer spice://$A-ip:5900
Play a song in the guest, make sure can hear the sound.

7. Do the migrate on A:
(qemu) client_migrate_info spice $B-ip 5900
(qemu) migrate -d tcp:$B-ip:5800,spiceport=5900,spicehost=$B-ip

Result:
After the migration, the sound gets louder

Additional info:
The effect is not obvious every time.
Comment 7 CongDong 2013-10-31 01:35:20 EDT
This can be reproduce with virt-manager too, the steps is same with comment 4.
The effect is not obvious every time, so can trun the sound down firstly.
Comment 8 David Jaša 2013-11-20 11:09:26 EST
the issue seems to boil down to client <--> guest volume synchronization that appears to work just in guest --> client direction and migration is one of two ways to trigger it:
1) have a guest with some audio playing in it (not necessary but it helps)
2) set the guest volume to say 90 % (client volume gets also adjusted*)
3) set the client volume to say 50 % (*)
4) do one of these two actions:
     * migrate the guest
     * in guest, lower the volume just one step (to say ~ 85 %)
what happens: client volume gets synced to ~85 %*, too, effectively doing the opposite of user wish (big volume increase instead of small decrease)
what should happen: in step 3), the guest volume should be adjusted as well.


* NOTE: all of these apply in rhel/fedora to pulseaudio default of flat-volumes = yes. If you change it in /etc/pulse/daemon.conf to "flat-volumes = no" and restart PA (pulseaudio -k; pulseaudio --start), then all the client volume references apply to per-application volumes of (virt|remote)-viewer, in gnome visible in Sound Properties --> Applications.
Comment 9 Marc-Andre Lureau 2013-11-20 11:17:44 EST
In practice, I think if migration wouldn't send extra unnecessary volume back to client, this bug would be mostly unnoticeable. It would only get adjusted when guest volume is changed, which is the expected result, to avoid volume change.
Comment 10 David Jaša 2013-11-20 12:40:08 EST
(In reply to Marc-Andre Lureau from comment #9)
> In practice, I think if migration wouldn't send extra unnecessary volume
> back to client, this bug would be mostly unnoticeable. It would only get
> adjusted when guest volume is changed, which is the expected result, to
> avoid volume change.

It's not just migration. I forgot one more scenario (linux client only):
1) have a disconnected guest with 100 % volume
2) connect to the guest from client with 30 % volume
3) play some music in the guest
4) decrease volume in the guest
result: your ears are likely to pop if the volume was at acceptable level at point 3)
Windows clients behave better: XP seems to ignore volume changes completely and 7 has somehow better implementation of PA's flat-volumes counterpart

There is a bit more to this issue:
  * users of full-screen clients are unlikely to use client software volume control
  * OTOH users who prefer volume keys adjust just client volume
  * linux users are more likely to use software controls as just scrolling over volume icon changes volume

To sum up, the best long term solution is two-way sync with some handling of different volumes at client launch. The best interim solution IMHO is to disable volume synchronization for linux clients till it works both-ways: no users will get surprise volume jups, experience of users with default settings will pretty much mirror the one of users with "flat-volumes = no".
Comment 11 Marc-Andre Lureau 2014-02-20 11:41:23 EST
(In reply to David Jaša from comment #10)
> (In reply to Marc-Andre Lureau from comment #9)
> > In practice, I think if migration wouldn't send extra unnecessary volume
> > back to client, this bug would be mostly unnoticeable. It would only get
> > adjusted when guest volume is changed, which is the expected result, to
> > avoid volume change.
> 
> It's not just migration. I forgot one more scenario (linux client only):
> 1) have a disconnected guest with 100 % volume
> 2) connect to the guest from client with 30 % volume
> 3) play some music in the guest
> 4) decrease volume in the guest
> result: your ears are likely to pop if the volume was at acceptable level at
> point 3)
> Windows clients behave better: XP seems to ignore volume changes completely
> and 7 has somehow better implementation of PA's flat-volumes counterpart

What you describe is a spice-gtk bug, that the volume isn't sync upon stream creation, sent a fix for that:

http://lists.freedesktop.org/archives/spice-devel/2014-February/016198.html

> There is a bit more to this issue:
>   * users of full-screen clients are unlikely to use client software volume
> control

yes

>   * OTOH users who prefer volume keys adjust just client volume

volume keys are redirected to guest too, if they are not for you, file a bug.

>   * linux users are more likely to use software controls as just scrolling
> over volume icon changes volume
> 
> To sum up, the best long term solution is two-way sync with some handling of
> different volumes at client launch. The best interim solution IMHO is to
> disable volume synchronization for linux clients till it works both-ways: no
> users will get surprise volume jups, experience of users with default
> settings will pretty much mirror the one of users with "flat-volumes = no".

I disagree, I think volume of the guest should be set on the client like if I plug my headphone or my speaker in a computer.

The rest of the bug looks like qemu or spice-server side issue to me, not client side (extra volume events), imho it should be moved/reassigned.
Comment 12 David Jaša 2014-02-20 12:23:47 EST
(In reply to Marc-Andre Lureau from comment #11)
...
> > Windows clients behave better: XP seems to ignore volume changes completely
> > and 7 has somehow better implementation of PA's flat-volumes counterpart
> 
> What you describe is a spice-gtk bug, that the volume isn't sync upon stream
> creation, sent a fix for that:
> 
> http://lists.freedesktop.org/archives/spice-devel/2014-February/016198.html
> 

Great!

> > There is a bit more to this issue:
> >   * users of full-screen clients are unlikely to use client software volume
> > control
> 
> yes
> 
> >   * OTOH users who prefer volume keys adjust just client volume
> 
> volume keys are redirected to guest too, if they are not for you, file a bug.
> 

OK

> >   * linux users are more likely to use software controls as just scrolling
> > over volume icon changes volume
> > 
> > To sum up, the best long term solution is two-way sync with some handling of
> > different volumes at client launch. The best interim solution IMHO is to
> > disable volume synchronization for linux clients till it works both-ways: no
> > users will get surprise volume jups, experience of users with default
> > settings will pretty much mirror the one of users with "flat-volumes = no".
> 
> I disagree, I think volume of the guest should be set on the client like if
> I plug my headphone or my speaker in a computer.
> 

Let's see how will things work with your new patch.
Comment 13 Marc-Andre Lureau 2014-07-10 16:39:40 EDT
*** Bug 1118365 has been marked as a duplicate of this bug. ***
Comment 14 Christophe Fergeau 2014-12-12 08:03:18 EST
I think the patch in that bug got stuck on http://lists.freedesktop.org/archives/spice-devel/2014-February/016198.html :( Would be nice to get this in for 6.7.
Comment 15 Marc-Andre Lureau 2014-12-12 09:22:36 EST
the patch is not yet upstream, I would rather not ack this bug yet.
Comment 17 David Blechter 2015-04-10 10:42:21 EDT
now is correct status
Comment 18 Victor Toso 2015-04-24 12:11:54 EDT
There are two different problems reported here:
1-) the volume jump during migration;
2-) the volume jump that can occur during normal use (comment #10);

The (1) has a patch in the ml in the spice-server:
http://lists.freedesktop.org/archives/spice-devel/2015-April/019608.html

The (2) should be fixed by new volume synchronization protocol; When the client connects, the volume in the client application is sent to the guest agent and the agent set the master volume.
ml: http://lists.freedesktop.org/archives/spice-devel/2015-April/019546.html

spice-gtk:
8c50e1a2b9f243a7da9b538cc1438b6a9d8e5671
aa8d044417bbf60685f59163b874ecb4f157c3c9
37ba949716ebf4411103308f4dbde75e81c7a9b3
29a6a342da427005c1f84c705a9435535c26d5e9

spice-protocol:
9acfaa66df90cb1475db7c09da09b6e9b5f5dd00

linux vdagent:
9b0eb8b1246ccb422ccecc3679b0bb6b477ba6cb
010dc21f35fb3997ade6717e10c6a3b52a1737ba
Comment 19 Marc-Andre Lureau 2015-04-24 13:08:54 EDT
Posted this too:
http://lists.freedesktop.org/archives/spice-devel/2015-April/019608.html
Comment 20 Victor Toso 2015-04-30 05:14:51 EDT
The following commits upstream are also necessary for rhel6.

spice-gtk:
bac48297211258b6527ef03d71fee4c275d779b8
60a8a3543c9206727a907d0db42c1870dbd21a37
0a50d2c1aca61772b6522b74eb2324fd5378a60e
Comment 22 Victor Toso 2015-10-08 09:36:06 EDT
This feature is not going to land in RHEL6 which is quite stable at the moment but it is expected to be on RHEL7:

spice-protocol: https://bugzilla.redhat.com/show_bug.cgi?id=1264100
spice-gtk: https://bugzilla.redhat.com/show_bug.cgi?id=1264105
spice-server: https://bugzilla.redhat.com/show_bug.cgi?id=1264107
spice-vdagent: https://bugzilla.redhat.com/show_bug.cgi?id=1264102

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