From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LonNX-00066L-Tg for qemu-devel@nongnu.org; Tue, 31 Mar 2009 19:28:23 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LonNT-00062D-C2 for qemu-devel@nongnu.org; Tue, 31 Mar 2009 19:28:23 -0400 Received: from [199.232.76.173] (port=58931 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LonNT-00061u-3n for qemu-devel@nongnu.org; Tue, 31 Mar 2009 19:28:19 -0400 Received: from smtp-out.google.com ([216.239.33.17]:50751) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LonNS-0005cV-Hd for qemu-devel@nongnu.org; Tue, 31 Mar 2009 19:28:18 -0400 Received: from wpaz13.hot.corp.google.com (wpaz13.hot.corp.google.com [172.24.198.77]) by smtp-out.google.com with ESMTP id n2VNSGPb032207 for ; Wed, 1 Apr 2009 00:28:16 +0100 Received: from gxk4 (gxk4.prod.google.com [10.202.11.4]) by wpaz13.hot.corp.google.com with ESMTP id n2VNSEwP016173 for ; Tue, 31 Mar 2009 16:28:15 -0700 Received: by gxk4 with SMTP id 4so3739896gxk.18 for ; Tue, 31 Mar 2009 16:28:14 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <49D12392.6040107@redhat.com> <20090330214321.GP3795@csclub.uwaterloo.ca> <20090330.161514.117919654.imp@bsdimp.com> <20090330233853.GT3795@csclub.uwaterloo.ca> <761ea48b0903302259p31b13c76s4c44396b8e33166b@mail.gmail.com> <60cad3f0903310558j554d6906q6f1244fd8a7449aa@mail.gmail.com> <60cad3f0903311448y7e826b6blecb015140fa09901@mail.gmail.com> Date: Wed, 1 Apr 2009 01:28:14 +0200 Message-ID: <60cad3f0903311628o6ae85144tf1f9c425ff3bcecb@mail.gmail.com> Subject: Re: [Qemu-devel] [PATCH] Document Qemu coding style From: David Turner Content-Type: multipart/alternative; boundary=00151750ec709730270466728d73 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 --00151750ec709730270466728d73 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Wed, Apr 1, 2009 at 12:38 AM, malc wrote: > > For starters you could have asked about things you believe are subtle. > True enough, but for a long time the project was confidential and alluding to it publicly was not recommended. I'll try to break the habit. > > Now to the part i do not understand: what do you mean by time-based(sic)? > There's one clock involved, as far as audio is concerned, and it's the > one dervied from the speed with which host audio can consume/produce > audio, anything else just doesn't work (for scenarios i was interested > in anyway) > I had some problems when running qemu on low-powered computers. If I remember correctly, the emulation part was taking so much of the CPU that audio could very well stutter in strange ways on some platforms. One of the reason for it was that the host audio output (e.g. esd) stopped consuming samples at a consistent rate, which forced SWVoiceOut buffers to fill up and delay audio production in the emulated system even more. In certain cases, there is also a non-trivial latency between the moment the emulated system produces audio-samples (e.g. sends them through dma to the emulated hardware), and the moment it is effectively sent to the host backend. This is mostly related to playing with the audio timer tick configuration which by default is so small that it should not matter. What I mean by time-based means a way to deal with varying latencies in both audio production and consumption. I agree it's a hard problem and is not totally required for QEMU. It's just that I spent some time trying to understand how the audio subsystem dealt with the problem, except that it didn't. > > As for the question of why everything just calls audio_pcm_sw_write > raised in AUDIO.txt, the reason, if my memory serves and it might as > well not do that all that well, things are the way they are for the > reason that any given driver can, theoretically, use the respective > audio subsystems/libraries own, less naive, st_rate_flow equivalent. > Interesting, thanks for the explanation, this makes it clear. > P.S. Last/only time i looked at Android couldn't help but notice that, > apart from other things, capture was implemented for coreaudio, > it would have been nice, if for nothing else but the sake of > completeness, to have that in main QEMU too. > Actually, the details of audio-related changes performed are: - adding audio input to the CoreAudio backend - adding dynamic linking support to the esd and alsa backends (using dlopen/dlsym allows the emulator to run on platforms where all the corresponding libraries / sound server are not available). - rewriting the sdl backend run_out() method. For some reason the old one tended to lock up QEMU in certain weird cases I could never completely understand. - modifying the sub-system to be able to use different backends for audio input and output. - adding a new "winaudio.c" backend for Windows that uses Wave functions instead of DirectX (mainly to be able to build on old versions of mingw that didn't provide directx-compatible headers, I'm not sure if it's still needed these days, but at least the code is 10x simpler than the dxaudio.c one, talk about a complex sound API). I plan to provide patches for all of these for upstream. Sorry if this hasn't been done yet. > -- > mailto:av1474@comtv.ru > > > --00151750ec709730270466728d73 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Apr 1, 2009 at 12:38 AM, malc <av1474@comtv.ru&= gt; wrote:

For starters you could have asked about things you believe are = subtle.

True enough, but for a long time the project was conf= idential and alluding to it publicly
was not recommended. I'll try t= o break the habit.
=A0

Now to the part i do not understand: what do you mean by time-based(sic)?= =A0
<= br> There's one clock involved, as far as audio is concerned, and it's = the
one dervied from the speed with which host audio can consume/produce
audio, anything else just doesn't work (for scenarios i was interested<= br> in anyway)

I had some problems when running qemu on low-powered = computers. If I remember
correctly, the emulation part was taking so muc= h of the CPU that audio could very
well stutter in strange ways on some = platforms. One of the reason for it was that the
host audio output (e.g. esd) stopped consuming samples at a consistent rate= , which
forced SWVoiceOut buffers to fill up and delay audio production = in the emulated
system even more.

In certain cases, there is also= a non-trivial latency between the moment the emulated
system produces audio-samples (e.g. sends them through dma to the emulated<= br>hardware), and the moment it is effectively sent to the host backend. Th= is is mostly
related to playing with the audio timer tick configuration = which by default is so small
that it should not matter.

What I mean by time-based means a way to = deal with varying latencies in both audio
production and consumption. I = agree it's a hard problem and is not totally required for
QEMU. It&#= 39;s just that I spent some time trying to understand how the audio subsyst= em
dealt with the problem, except that it didn't.
=A0

As for the question of why everything just calls audio_pcm_sw_write
raised in AUDIO.txt, the reason, if my memory serves and it might as
well not do that all that well, things are the way they are for the
reason that any given driver can, theoretically, use the respective
audio subsystems/libraries own, less naive, st_rate_flow equivalent.

Interesting, thanks for the explanation, this makes i= t clear.
=A0
P.S. Last/only time i looked at Android couldn't help but notice that,<= br> =A0 =A0 apart from other things, capture was implemented for coreaudio, =A0 =A0 it would have been nice, if for nothing else but the sake of
=A0 =A0 completeness, to have that in main QEMU too.

Actually, the details = of audio-related changes performed are:

- adding audio input to the = CoreAudio backend

- adding dynamic linking support to the esd and al= sa backends
(using dlopen/dlsym allows the emulator to run on platforms where
all th= e corresponding libraries / sound server are not available).

- rewri= ting the sdl backend run_out() method. For some reason the old one tended to lock up QEMU in certain weird cases I could never completely understand.=

- modifying the sub-system to be able to use different backends for= audio input
=A0 and output.

- adding a new "winaudio.c"= ; backend for Windows that uses Wave functions instead
=A0 of DirectX (mainly to be able to build on old versions of mingw that di= dn't provide
=A0 directx-compatible headers, I'm not sure if it&= #39;s still needed these days, but at least
=A0 the code is 10x simpler = than the dxaudio.c one, talk about a complex sound API).

I plan to provide patches for all of these for upstream. Sorry if this = hasn't been done yet.


--
mailto:av1474@comtv.ru



--00151750ec709730270466728d73--