This thread veered; I'd like to bring it back, if I can.
I've got a clear case of thread unsafety in XSpice.
spice_server_playback_put_samples is called from a different thread than
the main thread. If the main thread calls
main_dispatcher_handle_mm_time_latency while we're putting samples, very
bad things result. (I get a spin loop in the X server, mostly; there is
a fairly easy way to get snd_worker.c to infinite loop in
snd_send_data() with a little help from a malicious thread; if n != 0 at
the end of that loop, and spice_marshaller_fill_iovec returns 0).
This is a bug, and I think it's well understood (even if the best fix is
not).
We were hoping that I may have also exposed an issue in the qemu case,
but the jury is out on that.
We've got a lot of complaints of video/audio sync, and general video
quality, but nothing that struck me as fitting the result I would expect
from this bug. So I think they are unrelated issues.
As an aside, to any of the people suffering with audio/video issues,
that seem to be clear regressions, if any of you have the ability to do
a git bisect, that would be a very powerful way to help us understand
that issue.
But, back to *my* thread <grin>:
I was hoping that someone who knew qemu better than I could answer the
question: does the qemu audio processing loop run in it's own thread?
The equivalent call in qemu/spiceaudio.c (i.e. the call to
spice_server_playback_put_samples) happens in qemu/audio/spiceaudio.c.
That, in turn, appears to be called from run_out/then timer_run in
qemu/audio/aduio.c. That timer seems to be established by a call to
timer_new_ns in audio/audio.c, which devolves into a timer_init call.
But, afaict, timer_init just sets up the structure, and doesn't actually
start anything running.
I'm hoping a qemu expert can tap me with a clue bat and just help me
answer that question.
Cheers,
Jeremy
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/spice-devel