From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37671) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZS8ht-0007MS-T6 for qemu-devel@nongnu.org; Wed, 19 Aug 2015 15:07:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZS8ho-0004Bg-P6 for qemu-devel@nongnu.org; Wed, 19 Aug 2015 15:07:29 -0400 Received: from mx1.redhat.com ([209.132.183.28]:34038) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZS8ho-0004Bb-HN for qemu-devel@nongnu.org; Wed, 19 Aug 2015 15:07:24 -0400 Message-ID: <1440011241.4246.32.camel@redhat.com> From: Gerd Hoffmann Date: Wed, 19 Aug 2015 21:07:21 +0200 In-Reply-To: <4b65a1903b217534f6222a45430c014de5b9bf3b.1438884611.git.DirtY.iCE.hu@gmail.com> References: <4b65a1903b217534f6222a45430c014de5b9bf3b.1438884611.git.DirtY.iCE.hu@gmail.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 20/25] audio: remove mixeng specific code from backends List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?Q?K=C5=91v=C3=A1g=C3=B3=2C_Zolt=C3=A1n?= Cc: qemu-devel@nongnu.org On Do, 2015-08-06 at 20:28 +0200, K=C5=91v=C3=A1g=C3=B3, Zolt=C3=A1n wrot= e: > Backends no longer have to deal with mixeng, they just receive a buffer > in the correct sample format, all mixeng logic is now in the audio.c > (and mixeng.c). Backends also do not have to deal with soft voices. >=20 > Backends now have two way to read/write sound: > * write and read functions: similar to old read/write functions, except > that they actually read/write the data to the backend instead of > placing it into the mixeng buffer. You no longer need run_in/run_out > afterwards. > * get_buffer_out/put_buffer_out: the first function returns a buffer > that can hold some audio data. The caller fills this buffer (maybe > partially) and calls put_buffer to actually write the data. This way > we can save copying the buffer in some cases (for example mmaped > audio). Similarly there's get_buffer_in/put_buffer_in for reading. >=20 > Backends only have to support one access method, but they can support > both if they have efficient implementation for both cases. Phew, this one became pretty big. Could this be splitted up? The s/int/size_t/ should be easy to separate. Also having individual patches for individual backends would be nice. Possibly you can first add the new interfaces, & helper functions, then switch backends over one by one, hooking the generic audio_pcm_hw_run_out() function into run_out callback, finally remove the old interfaces and call audio_pcm_hw_run_out directly. cheers, Gerd