On Mo, 2014-12-15 at 15:37 +, Peter Maydell wrote:
> On 15 December 2014 at 09:23, Gerd Hoffmann wrote:
>
> >> > Does anybody know how this is supposed to work? Is the fix as
> >> > simple as just moving the free_resources call below the fini?
> >
> > I suspect the code simply wasn't written
On 15 December 2014 at 09:23, Gerd Hoffmann wrote:
>> > Does anybody know how this is supposed to work? Is the fix as
>> > simple as just moving the free_resources call below the fini?
>
> I suspect the code simply wasn't written with threads in mind and the
> fix actually is that simple ...
>
>
Hi,
> > Usually this works. Unfortunately if the input thread is in the
> > middle of actually writing to the buffer then things can go pear
> > shaped, because the sample buffer itself is freed earlier, by
> > audio_pcm_hw_gc_in():
> >
> > glue (s->nb_hw_voices_, TYPE) += 1;
> >
If Gerd (cc'ed) doesn't know, then I'm afraid nobody around here does.
Peter Maydell writes:
> There seems to be a race condition in the pulseaudio backend on
> closing of a voice...
>
> There are two threads involved here. The first one is a worker
> thread that just sits executing our qpa_thre
There seems to be a race condition in the pulseaudio backend on
closing of a voice...
There are two threads involved here. The first one is a worker
thread that just sits executing our qpa_thread_in() function
to get input audio from PA and feed it to us. The second thread
is QEMU itself (the cpu
