Re: [Qemu-devel] [PATCH 0/6] The windows 7 audio support patch series.

[malc]

On Thu, 28 Oct 2010, Gerd Hoffmann wrote:

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

We (me, Wu Fengguang and Hans Peter Anvin) tried to do something about
usb-audio, to no avail.

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

DOS doesn't need drivers you know, anyhow:
http://mpxplay.sourceforge.net/

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

At the very least their code does work here (on a PPC with DOS and 
mpxplay) and yours doesn't. I'd have to check things on my x86_64 box
to ensure it's not a endianness issue of some sort, otherwise things
are hard to explain since mpxplay's hda handling is based on ALSA.

-- 
mailto:address@hidden