Re: [PATCH spice-gtk 1/5] audio: emit stop when the channels are reset

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Victor,

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:
#0  0x00007fffee057cd8 in spice_server_playback_stop (sin=0x555556bb44f8) at snd_worker.c:1055
#1  0x0000555555736240 in line_out_ctl (hw=0x555556bb4470, cmd=<optimized out>)    at audio/spiceaudio.c:219
#2  0x000055555572e874 in audio_vm_change_state_handler    (opaque=0x555555dccfc0 <glob_audio_state>, running=<opti
mized out>, state=<optimized out>) at audio/audio.c:1766
#3  0x0000555555718d0f in vm_state_notify (running=running@entry=0, state=state@entry=RUN_STATE_FINISH_MIGRATE)
at vl.c:1581
#4  0x000055555562937a in vm_stop (state=RUN_STATE_FINISH_MIGRATE) at /usr/src/debug/qemu-2.2.0/cpus.c:613
#5  0x000055555562937a in vm_stop (state=RUN_STATE_FINISH_MIGRATE) at /usr/src/debug/qemu-2.2.0/cpus.c:1300
#6  0x0000555555704c3b in migration_thread (opaque=0x555555d0ea00 <current_migration>) at migration.c:610

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.

As explained earlier, this patch doesn't create or add another stop signal, so this should clear your concerns about it.

--
Marc-André Lureau
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/spice-devel

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]     [Monitors]