From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LooHF-0006qG-31 for qemu-devel@nongnu.org; Tue, 31 Mar 2009 20:25:57 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LooH9-0006j9-FR for qemu-devel@nongnu.org; Tue, 31 Mar 2009 20:25:55 -0400 Received: from [199.232.76.173] (port=56557 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LooH9-0006j6-5v for qemu-devel@nongnu.org; Tue, 31 Mar 2009 20:25:51 -0400 Received: from smtp-out.google.com ([216.239.33.17]:55390) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LooH8-0006r5-LJ for qemu-devel@nongnu.org; Tue, 31 Mar 2009 20:25:51 -0400 Received: from zps75.corp.google.com (zps75.corp.google.com [172.25.146.75]) by smtp-out.google.com with ESMTP id n310Pmd8025227 for ; Wed, 1 Apr 2009 01:25:48 +0100 Received: from yx-out-2324.google.com (yxb8.prod.google.com [10.190.1.72]) by zps75.corp.google.com with ESMTP id n310PkXI007630 for ; Tue, 31 Mar 2009 17:25:46 -0700 Received: by yx-out-2324.google.com with SMTP id 8so1759464yxb.15 for ; Tue, 31 Mar 2009 17:25:45 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <20090330.161514.117919654.imp@bsdimp.com> <20090330233853.GT3795@csclub.uwaterloo.ca> <761ea48b0903302259p31b13c76s4c44396b8e33166b@mail.gmail.com> <60cad3f0903310558j554d6906q6f1244fd8a7449aa@mail.gmail.com> <60cad3f0903311448y7e826b6blecb015140fa09901@mail.gmail.com> <60cad3f0903311628o6ae85144tf1f9c425ff3bcecb@mail.gmail.com> Date: Wed, 1 Apr 2009 02:25:45 +0200 Message-ID: <60cad3f0903311725p1405aa0fm5b5f283700b99a78@mail.gmail.com> Subject: Re: [Qemu-devel] [PATCH] Document Qemu coding style From: David Turner Content-Type: multipart/alternative; boundary=00151751146c4b57120466735ba4 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 --00151751146c4b57120466735ba4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Wed, Apr 1, 2009 at 1:49 AM, malc 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. > 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 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. 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. > > > > - 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. > 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 :-) Regards --00151751146c4b57120466735ba4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Apr 1, 2009 at 1:49 AM, malc <av1474@comtv.ru&g= t; 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 900H= z 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&#= 39;m not suggesting to anyone to fix anything here..
=A0

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.

Regarding esd, I unfortunatel= y have to support the emulator binary running on
Ubuntu 6.06 installatio= ns where the sound server will frequently lock up when the
Android emula= tor 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 initially thought that the main reason for that wa= s that the esd client library could
not handle the multiple SIGALRM-indu= ced 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 pro= tected all
calls to the esd backend (playing with the signal mask to avo= id that), but this
still doesn't get rid of the problem. Fortunately, this doesn't see= m to happen with
later versions of Ubuntu.

If anyone has an expla= nation for this behaviour (which doesn't seem to happen on
later Ubu= ntu 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 fil= ling 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.


>
> - 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 binar= ies
is not what it's best known for.

:-)
=A0

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

Yeah i recall seeing this, and was wondering why Android needed this<= br> functionality.

this was to be able to get au= dio input from a wave file while sending the output
to the host audio sy= stem. 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.
=A0
Complexity no= twithstanding i happen to like the way things are done in
DSound, the conceptually simple approach that is.

I must admit I totally fail t= o see any simplicity in DirectSound :-)

Regards

<= br> --00151751146c4b57120466735ba4--