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

[malc <av1474@comtv.ru>]

On Wed, 1 Apr 2009, David Turner wrote:

> On Wed, Apr 1, 2009 at 1:49 AM, malc <av1474@comtv.ru> wrote:
> 
> > Hmm.. please define low-powered..
> 
> 
> No problem, people have been running the Android SDK on 700 MHz.
> I used to run it on a 900Hz Celeron or something like that.
> 
> Today, I'm doing all my "minimal performance" tests on a venerable
> 1 GHz Pentium III laptop with an integrated Intel audio chipset running
> Windows XP (and a Linux install under VMWare).
> 
> Just to be clear, I'm not suggesting to anyone to fix anything here..
> 
> 
> >
> > And FWIW nowadays it's MPC7447A at 1.3Ghz which is not speed demon
> > either. Not that i dont belive you, esp considering esd thrown into
> > equation, but it would be interesting to know what people deem
> > low-powered currently.
> >

This thing is actually slower than the old Athlon.. Perhaps on
par/slightly faster than 1Ghz Pentium III.. And if ARM Android
emulates is big-endian - Pentium has some advantage even..

> Regarding esd, I unfortunately have to support the emulator binary
> running on Ubuntu 6.06 installations where the sound server will
> frequently lock up when the Android emulator is run. In some cases,
> this also totally freezes the whole desktop, though it is possible
> to recover by perfoming a "killall -9 esd" from a console.

I have very hard time parsing that, you are suspecting emulator binary
locking up esd daemon?
 
> I initially thought that the main reason for that was that the esd
> client library could not handle the multiple SIGALRM-induced EINTR
> returned by write() and other system calls, and left the sound
> server in a sorry state (maybe because it was stuck waiting for some
> data that would never arrive). However, I protected all calls to the
> esd backend (playing with the signal mask to avoid that), but this
> still doesn't get rid of the problem. Fortunately, this doesn't seem
> to happen with later versions of Ubuntu.

esdaudio.c blocks all signals for both playback and recording.. So
hum..

> If anyone has an explanation for this behaviour (which doesn't seem
> to happen on later Ubuntu releases), I'd be happy to share more
> info.
> 
> > Well.. I certainly fail to see how adding some other clock would
> > overcome the fact that something can't keep up.. (rt priorties and
> > suchlike?)
> >
> 
> the main idea is to avoid filling up buffers by dropping some frames
> when that kind of thing happens. Or to introduce silence in the
> output under other conditions.  The main idea is to avoid increasing
> drift between the emulated and host system when it comes to
> audio. Again, I'm not suggesting to implement anything like that.
> 

Drift can only grow as big as the ring buffer in any case...

> > >
> > > - 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).
> >
> > I don't think this is worth it for QEMU, after all shipping binaries
> > is not what it's best known for.
> >
> 
> :-)
> 
> 
> >
> > > - modifying the sub-system to be able to use different backends for
> > >   audio input and output.
> >
> > Yeah i recall seeing this, and was wondering why Android needed this
> > functionality.
> >
> 
> this was to be able to get audio input from a wave file while
> sending the output to the host audio system. Turned out to be very
> useful to test the VoiceRecorder application. I also played with it
> to debug esd/also related problems.  It's not exactly something that
> is worth it for upstream QEMU.

Oh.. I never needed that, otherwise there would probably be a
wavplayback alongside wavcapture monitor command.

> 
> > Complexity notwithstanding i happen to like the way things are done in
> > DSound, the conceptually simple approach that is.
> >
> 
> I must admit I totally fail to see any simplicity in DirectSound :-)

Oh it's just overly complicated oss+mmap with locking and the ability
to get the current position, FMOD is almost exactly the same but the
wrapping is more palatable.

P.S. Your mails (raw text versions of them) have their lines wrapped
     weirdly.

-- 
mailto:av1474@comtv.ru