From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=54189 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PBO8s-000102-DQ for qemu-devel@nongnu.org; Thu, 28 Oct 2010 04:47:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PBO8r-0004K4-6r for qemu-devel@nongnu.org; Thu, 28 Oct 2010 04:47:26 -0400 Received: from mx1.redhat.com ([209.132.183.28]:27017) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PBO8r-0004Js-0O for qemu-devel@nongnu.org; Thu, 28 Oct 2010 04:47:25 -0400 Message-ID: <4CC93894.3030008@redhat.com> Date: Thu, 28 Oct 2010 10:47:16 +0200 From: Gerd Hoffmann MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 0/6] The windows 7 audio support patch series. References: <1288195475-3807-1-git-send-email-kraxel@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: malc Cc: qemu-devel@nongnu.org Hi, > Nice timing there. I wonder how long it took bright folks at redhat to > code this HDA stuff? A bunch of days. Played with the usb-audio patch first. But I suspect getting timing-sensitive isochronous usb devices emulated reasonable well is pretty hard due to the latency requirements. And it isn't just the usb subsytem, all qemu must improve here. Example: enabling the threaded vnc server improves usb-audio sound quality, you don't get dropouts on every bulky screen update then. But for now I tried HDA route instead. > Since yesterday i was contacted by folks who wanted > to pay money to get VirtualBox's HDA ported to QEMU, and it took me from > 16:00 today till basically 15 minutes ago to get the sound pumping from > DOS and Linux.. Oh, there is a HDA driver for DOS? /me looks surprised ... > Regardless of the answer to my question the NIH is such a nice thing, eh? Sure ;) I don't do that just for fun though. I *have* looked at the vbox driver first. The fundamental problem is the qemu world didn't stop at the point where vbox forked off, and of course in vbox things are changing too. We have alot of infrastructure for drivers which isn't in vbox, and likewise the other way around. Most notable difference is qemu's qdev is quite useful to model the HDA bus. So there are basically two options: (1) Port the vbox driver to qemu, then to tons of changes and cleanups to properly integrate into modern qemu. (2) Start over from scratch. I believe in the end it wouldn't have saved work to use the vbox code as starting point. cheers, Gerd