RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1549132 - Audio recording is discontinued after reconnection to VM
Summary: Audio recording is discontinued after reconnection to VM
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: spice
Version: 7.5
Hardware: Unspecified
OS: Unspecified
high
medium
Target Milestone: rc
: ---
Assignee: Default Assignee for SPICE Bugs
QA Contact: SPICE QE bug list
URL:
Whiteboard:
Depends On:
Blocks: 1582601
TreeView+ depends on / blocked
 
Reported: 2018-02-26 13:25 UTC by Radek Duda
Modified: 2018-10-30 08:07 UTC (History)
9 users (show)

Fixed In Version: spice-0.14.0-5.el7
Doc Type: Bug Fix
Doc Text:
Previously, reconnecting to a running guest virtual machine caused audio input devices attached to the guest, such as microphones, to stop working. This update fixes the handling of the guest recording channel, which prevents the described problem from occurring.
Clone Of:
: 1582084 1582601 (view as bug list)
Environment:
Last Closed: 2018-10-30 08:07:14 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
spice-debug log after reconnection (30.59 KB, text/plain)
2018-02-26 13:25 UTC, Radek Duda 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2018:3068 0 None None None 2018-10-30 08:07:59 UTC

Description Radek Duda 2018-02-26 13:25:48 UTC 
Created attachment 1400840 [details]
spice-debug log after reconnection

Description of problem:
No input audio signal is detected after reconnection to VM during audio recording session (within VM guest).

Version-Release number of selected component (if applicable):
client/host (rhel7.5):
spice-server-0.14.0-2.el7.x86_64
spice-glib-0.34-3.el7.x86_64
spice-gtk3-0.34-3.el7.x86_64
qemu-kvm-rhev-2.9.0-16.el7_4.14.x86_64.
virt-viewer-5.0-10.el7.x86_64

guest (rhel7.5), reproducible also for Win10 guest

How reproducible:
always

Steps to Reproduce:
1.Use remote-viewer and connect to guest with enabled audio. Have some recording device connected to client (usb webcam with microphone in my case)
2.run within guest 'arecord -vv' and make some noise to microphone (-> see input audio level increases within guest)
3. reconnect to guest VM
4. again make some noise to the microphone similar to that of the step 2

Actual results:
0% input audio level detected in guest VM even though I produce some noise to microphone.

Expected results:
Input audio level is roughly proportionate to the value detected before reconnection.

Additional info:
guest configuration:

/usr/libexec/qemu-kvm -name guest=rhel7.5,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-1-rhel7.5/master-key.aes -machine pc-i440fx-rhel7.4.0,accel=kvm,usb=off,dump-guest-core=off -cpu Broadwell,rtm=on,hle=on -m 2000 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -uuid e82c2e84-3325-4633-8e7a-61756a931fc5 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-1-rhel7.5/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive file=/home/rduda/virtualky/RHEL-7.5-20180219.n.0-Workstation-x86_64.qcow2,format=qcow2,if=none,id=drive-virtio-disk0 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=27,id=hostnet0,vhost=on,vhostfd=29 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:04:e5:26,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-1-rhel7.5/org.qemu.guest_agent.0,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 -chardev spicevmc,id=charchannel1,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=com.redhat.spice.0 -device usb-tablet,id=input0,bus=usb.0,port=1 -spice port=5900,addr=0.0.0.0,disable-ticketing,image-compression=off,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=2 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=3 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8 -msg timestamp=on
Comment 2 Victor Toso 2018-02-26 13:45:34 UTC 
Do you have your usb device being auto redirect upon connection?

Considering that this is an USB device being redirected, I'm not sure we currently support that microphone (or any ISOC device) would seamless work back on reconnection (e.g the same would be for a webcam that is currently being used by some application and you disconnect/reconnect).

If I understood correctly, this is not the same as spice-gtk's RecordChannel that gets the input from Client's backend (like Pulseaudio) and send it to the guest. With RecordChannel, we'll be sending data to the guest since early stage but with USB device, that's like plug in an USB device while you are already recording audio.
Comment 3 Radek Duda 2018-02-26 15:49:10 UTC 
I did not USB redirect this device (and I would write it in the reproducing steps if this was the case).
After reconnection to VM I can renew recording by restarting 'arecord' command.

I tried this again with built-in laptop microphone and I cannot reproduce, but I  can reproduce with 3.5 headphones microphone on my workstation (the only connected microphone).
Comment 4 Bill Sanford 2018-04-11 14:35:27 UTC 
I have also tested this and the USB headset/mic gets unloaded after virt-viewer is closed. The 3.5mm headset or mic does not have this issue.
Comment 5 Victor Toso 2018-05-22 12:36:55 UTC 
Bug was likely introduced by spice-server rebase.

I can see that qemu does the right thing, which is calling spice_server_record_start() in both situations:
1) When we are connected to the guest and then run arecord -v
2) When we connect to the guest that already has arecord -v running

In the situation (2) it seems that RedChannelClient from RecordChannel is not connected to the client in time (or is it outdated from previous connection?) which causes the RECORD_START message not be sent to the client.

So client does not receive 'ok' to send input from microphone.

It seems to be a regression and we should fix before 7.6 maybe add to 7.5.z too as a user with a ongoing record session (let's say, bluejeans) would lose microphone on disconnect/connect unless it request volume (from input) changes in the guest.
Comment 6 Christophe Fergeau 2018-05-22 16:42:26 UTC 
Something like this fixes this bug:
diff --git a/server/sound.c b/server/sound.c
index e3891d2cc..a81e4317b 100644
--- a/server/sound.c
+++ b/server/sound.c
@@ -1105,6 +1105,7 @@ static void snd_set_peer(RedChannel *red_channel, RedClient *client, RedStream *
                                 "caps", caps,
                                 NULL);
     g_warn_if_fail(snd_client != NULL);
+    snd_send(SND_CHANNEL_CLIENT(snd_client));
 }
 
 static void snd_set_playback_peer(RedChannel *red_channel, RedClient *client, RedStream *stream,

The snd_send() calls in record_channel_client_constructed() are too early to trigger a call to send_item() as the channel client won't be considered connected before the end of red_channel_client_initable_init(), and prepare_pipe_add() in red_channel_client_pipe_add() just drops the pipe items if the channel client is not connected, so snd_send() fails to queue any pipe item. This was broken in d8dc09b 'sound: Convert SndChannelClient to RedChannelClient'
Comment 7 Christophe Fergeau 2018-05-23 10:17:26 UTC 
https://lists.freedesktop.org/archives/spice-devel/2018-May/043629.htmlshould fix this.
Comment 8 Victor Toso 2018-05-24 07:10:42 UTC 
We have two possible solutions being discussed upstream, we can move this to POST.
Comment 12 Radek Duda 2018-09-14 11:53:06 UTC 
Verified with spice-server-0.14.0-6.el7.x86_64 and rhel7.6 client/host/guest.
Recording of microphone sound in guest VM continues after reconnection to it.
Comment 14 errata-xmlrpc 2018-10-30 08:07:14 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:3068
Note You need to log in before you can comment on or make changes to this bug.