Re: [Qemu-devel] [PATCH] Document Qemu coding style

[David Turner <digit@google.com>]

[-- Attachment #1: Type: text/plain, Size: 3406 bytes --]

On Wed, Apr 1, 2009 at 12:38 AM, malc <av1474@comtv.ru> 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
>
>
>

[-- Attachment #2: Type: text/html, Size: 4838 bytes --]