From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=44076 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1PhmDL-0002Kn-2j
	for qemu-devel@nongnu.org; Tue, 25 Jan 2011 11:57:56 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <av1474@comtv.ru>) id 1PhmDK-0007xZ-3Z
	for qemu-devel@nongnu.org; Tue, 25 Jan 2011 11:57:54 -0500
Received: from fe02x03-cgp.akado.ru ([77.232.31.165]:55884 helo=akado.ru)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <av1474@comtv.ru>) id 1PhmDJ-0007wt-SK
	for qemu-devel@nongnu.org; Tue, 25 Jan 2011 11:57:54 -0500
Date: Tue, 25 Jan 2011 19:57:32 +0300 (MSK)
From: malc <av1474@comtv.ru>
In-Reply-To: <1295903266-6458-1-git-send-email-kraxel@redhat.com>
Message-ID: <alpine.LNX.2.00.1101251957160.1657@linmac>
References: <1295903266-6458-1-git-send-email-kraxel@redhat.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: [Qemu-devel] Re: [RESEND PATCH 1/3] pulseaudio: process 1/4 buffer
	max at once
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: qemu-devel@nongnu.org

On Mon, 24 Jan 2011, Gerd Hoffmann wrote:

> Limit the size of data pieces processed by the pulseaudio worker
> threads.  Never ever process more than 1/4 of the buffer at once.
> 
> Background: The buffer area currently processed by the pulseaudio thread
> is blocked, i.e. the main thread (or iothread) can't fill in more data
> there.  The buffer processing time is roughly real-time due to the
> pa_simple_write() call blocking when the output queue to the pulse
> server is full.  Thus processing big chunks at once means blocking
> a large part of the buffer for a long time.  This brings high latency
> and can lead to dropouts.
> 
> When processing the buffer in smaller chunks the rpos handling becomes a
> problem though.  The thread reads hw->rpos without knowing whenever
> qpa_run_out has already seen the last (small) chunk processed and
> updated rpos accordingly.  There is no point in reading hw->rpos though,
> pa->rpos can be used instead.  We just need to take care to initialize
> pa->rpos before kicking the thread.
> 
[..snip...]

Thanks, applied.

-- 
mailto:av1474@comtv.ru