From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JpBVU-0005ap-F9 for qemu-devel@nongnu.org; Thu, 24 Apr 2008 20:09:40 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JpBVS-0005ad-Vm for qemu-devel@nongnu.org; Thu, 24 Apr 2008 20:09:40 -0400 Received: from [199.232.76.173] (port=35465 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JpBVS-0005aa-Rl for qemu-devel@nongnu.org; Thu, 24 Apr 2008 20:09:38 -0400 Received: from fmmailgate02.web.de ([217.72.192.227]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JpBVS-00076P-7U for qemu-devel@nongnu.org; Thu, 24 Apr 2008 20:09:38 -0400 Received: from smtp07.web.de (fmsmtp07.dlan.cinetic.de [172.20.5.215]) by fmmailgate02.web.de (Postfix) with ESMTP id B32CBDA1F9D5 for ; Fri, 25 Apr 2008 02:09:35 +0200 (CEST) Received: from [88.65.242.3] (helo=[192.168.1.198]) by smtp07.web.de with asmtp (TLSv1:AES256-SHA:256) (WEB.DE 4.109 #226) id 1JpBVP-00019r-00 for qemu-devel@nongnu.org; Fri, 25 Apr 2008 02:09:35 +0200 Message-ID: <4811213C.7020507@web.de> Date: Fri, 25 Apr 2008 02:09:32 +0200 From: Jan Kiszka MIME-Version: 1.0 Subject: Re: [Qemu-devel] [4249] Improve audio api use in WM8750. References: <4810FBF9.1040308@web.de> <48111E61.9050002@web.de> In-Reply-To: <48111E61.9050002@web.de> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigAAC732CEDBC2BEC5A1DD9D05" Sender: jan.kiszka@web.de Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigAAC732CEDBC2BEC5A1DD9D05 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Jan Kiszka wrote: > andrzej zaborowski wrote: >> On 24/04/2008, Jan Kiszka wrote: >>> Hi Andrzej, >>> >>> Andrzej Zaborowski wrote: >>> > Revision: 4249 >>> ... >>> > static void wm8750_audio_out_cb(void *opaque, int free_b) >>> > { >>> > struct wm8750_s *s =3D (struct wm8750_s *) opaque; >>> > >>> > - s->req_out =3D free_b; >>> > - s->data_req(s->opaque, free_b >> 2, s->req_in >> 2); >>> > - wm8750_out_flush(s); >>> > + if (s->idx_out >=3D free_b) { >>> > + s->idx_out =3D free_b; >>> > + s->req_out =3D 0; >>> > + wm8750_out_flush(s); >>> > + } else >>> > + s->req_out =3D 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 flu= sh >>> (keep in mind: it may increase the amount of data that has to be flu= shed >>> 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 >=20 > Wrong ordering: If there has been a _relevant_ amount of data (not a fe= w > 10 bytes) hanging around in our internal buffer between the guest has > filled it during the last callbacks and the host reports demand via the= > new callback, that data was missing in the host's audio buffer! That's > what I saw (heard) with the old version (the current one even causes > total silence). >=20 >> 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. >=20 > Nothing is crawling here, just use a reasonable threshold for flushing > _after_ the callback. Need to check, but maybe we can even wait the a > full buffer. Of course not the full buffer, but its half is fine as it generally leaves enough time to the guest to refill the other half: Index: hw/wm8750.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- hw/wm8750.c (Revision 4250) +++ hw/wm8750.c (Arbeitskopie) @@ -73,14 +73,10 @@ static void wm8750_audio_out_cb(void *op { struct wm8750_s *s =3D (struct wm8750_s *) opaque; - if (s->idx_out >=3D free_b) { - s->idx_out =3D free_b; - s->req_out =3D 0; + s->req_out =3D free_b; + s->data_req(s->opaque, free_b >> 2, s->req_in >> 2); + if (s->idx_out >=3D sizeof(s->data_out)/2) wm8750_out_flush(s); - } else - s->req_out =3D free_b - s->idx_out; - - s->data_req(s->opaque, s->req_out >> 2, s->req_in >> 2); } struct wm_rate_s { Jan --------------enigAAC732CEDBC2BEC5A1DD9D05 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFIESE/niDOoMHTA+kRAgu0AJ4gjGPAhefNTdNl2r6fhGsA5R1WDACeKl34 Q1ZcxaZLK2/5yeqHMz0rVBA= =L9tv -----END PGP SIGNATURE----- --------------enigAAC732CEDBC2BEC5A1DD9D05--