From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1JpAxi-0003cl-51
	for qemu-devel@nongnu.org; Thu, 24 Apr 2008 19:34:46 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1JpAxg-0003Zj-Eh
	for qemu-devel@nongnu.org; Thu, 24 Apr 2008 19:34:45 -0400
Received: from [199.232.76.173] (port=50376 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1JpAxf-0003YL-RL
	for qemu-devel@nongnu.org; Thu, 24 Apr 2008 19:34:44 -0400
Received: from ug-out-1314.google.com ([66.249.92.170])
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <balrogg@gmail.com>) id 1JpAxf-0005Kx-AO
	for qemu-devel@nongnu.org; Thu, 24 Apr 2008 19:34:43 -0400
Received: by ug-out-1314.google.com with SMTP id m2so896365uge.4
	for <qemu-devel@nongnu.org>; Thu, 24 Apr 2008 16:34:40 -0700 (PDT)
Message-ID: <fb249edb0804241634q745bad0cpbce40f3087036f6a@mail.gmail.com>
Date: Fri, 25 Apr 2008 01:34:40 +0200
From: "andrzej zaborowski" <balrogg@gmail.com>
Subject: Re: [Qemu-devel] [4249] Improve audio api use in WM8750.
In-Reply-To: <4810FBF9.1040308@web.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <E1Jp8ZZ-0002f6-Ha@cvs.savannah.gnu.org> <4810FBF9.1040308@web.de>
Reply-To: qemu-devel@nongnu.org
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.gnu.org/pipermail/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: qemu-devel@nongnu.org

On 24/04/2008, Jan Kiszka <jan.kiszka@web.de> wrote:
> Hi Andrzej,
>
>  Andrzej Zaborowski wrote:
>  > Revision: 4249
>  ...
>  >  static void wm8750_audio_out_cb(void *opaque, int free_b)
>  >  {
>  >      struct wm8750_s *s = (struct wm8750_s *) opaque;
>  >
>  > -    s->req_out = free_b;
>  > -    s->data_req(s->opaque, free_b >> 2, s->req_in >> 2);
>  > -    wm8750_out_flush(s);
>  > +    if (s->idx_out >= free_b) {
>  > +        s->idx_out = free_b;
>  > +        s->req_out = 0;
>  > +        wm8750_out_flush(s);
>  > +    } else
>  > +        s->req_out = free_b - s->idx_out;
>  > +
>  > +    s->data_req(s->opaque, s->req_out >> 2, s->req_in >> 2);
>
>  Please make sure that the callback is always issued _before_ the flush
>  (keep in mind: it may increase the amount of data that has to be flushed
>  ASAP!). And this change also leaves the MusicPal broken.

The idea is to output free_b bytes immediately if we have that many in
the buffer (it could happen assuming that free_b value can change
between callbacks).  I'm not sure how this can break something: if
*inside* the data_req() callback we receive enough bytes to fill the
the whole buffer then dac_dat() will call out_flush().

Without that all buffering becomes useless because we flush every
sample we receive and we start to crawl.

Regards
-- 
Please do not print this email unless absolutely necessary. Spread
environmental awareness.