From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51570) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y0Rsq-0008HT-Us for qemu-devel@nongnu.org; Mon, 15 Dec 2014 04:24:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y0Rsk-0000qy-Qb for qemu-devel@nongnu.org; Mon, 15 Dec 2014 04:24:04 -0500 Received: from mx1.redhat.com ([209.132.183.28]:53171) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y0Rsk-0000qs-IH for qemu-devel@nongnu.org; Mon, 15 Dec 2014 04:23:58 -0500 Message-ID: <1418635433.9400.5.camel@nilsson.home.kraxel.org> From: Gerd Hoffmann Date: Mon, 15 Dec 2014 10:23:53 +0100 In-Reply-To: <87fvchffgo.fsf@blackfin.pond.sub.org> References: <87fvchffgo.fsf@blackfin.pond.sub.org> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] paaudio race condition on close List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: Peter Maydell , QEMU Developers 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; > > glue (audio_pcm_hw_free_resources_ ,TYPE) (hw); > > glue (hw->pcm_ops->fini_, TYPE) (hw); > > > > So we end up freeing hw resources (like the conv_buf) before we > > give the pulseaudio backend a chance to actually shut down its > > helper thread. > > > > 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 ... The submitted patch looks fine to me. Do you just commit it yourself? I don't have any other audio stuff pending atm. cheers, Gerd