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 > > >