<div dir="ltr"><div>Hi Victor,<br><br></div>It turns out that a "stop" message is sent by spice server during migration. Qemu audio_vm_change_state_handler() will disable all audio devices on finish migrate.  See backtrace:<br>#0  0x00007fffee057cd8 in spice_server_playback_stop (sin=0x555556bb44f8) at snd_worker.c:1055<br>#1  0x0000555555736240 in line_out_ctl (hw=0x555556bb4470, cmd=<optimized out>)    at audio/spiceaudio.c:219<br>#2  0x000055555572e874 in audio_vm_change_state_handler    (opaque=0x555555dccfc0 <glob_audio_state>, running=<opti<br>mized out>, state=<optimized out>) at audio/audio.c:1766<br>#3  0x0000555555718d0f in vm_state_notify (running=running@entry=0, state=state@entry=RUN_STATE_FINISH_MIGRATE)<br>at vl.c:1581<br>#4  0x000055555562937a in vm_stop (state=RUN_STATE_FINISH_MIGRATE) at /usr/src/debug/qemu-2.2.0/cpus.c:613<br>#5  0x000055555562937a in vm_stop (state=RUN_STATE_FINISH_MIGRATE) at /usr/src/debug/qemu-2.2.0/cpus.c:1300<br>#6  0x0000555555704c3b in migration_thread (opaque=0x555555d0ea00 <current_migration>) at migration.c:610<br><br>Playback is re-started on destination. Tbh, I don't think this is a big issue as the seamless-migration switch time is usually << 1s. Although you can notice a small audio glitch in some cases.<br><br>As explained earlier, this patch doesn't create or add another stop signal, so this should clear your concerns about it.<br clear="all"><div><div><div class="gmail_extra"><br>-- <br><div class="gmail_signature">Marc-André Lureau</div>
</div></div></div></div>