[Spice-commits] Changes to 'audio'

[Gerd Hoffmann]

New branch 'audio' available with the following commits:
commit 65d3ccf64029bf9a593992c9e8b1ae3fb87c0bff
Author: Gerd Hoffmann <kraxel at redhat.com>
Date:   Fri Oct 22 23:47:53 2010 +0200

    intel-hda #3, linux playing

commit b8ff380cecc92eb927bc77a47bde621a75d6d48e
Author: Gerd Hoffmann <kraxel at redhat.com>
Date:   Fri Oct 22 16:03:06 2010 +0200

    intel-hda #2

commit 81683c4b5479a0fe14631d02ac34d8e8f1cabb3b
Author: Gerd Hoffmann <kraxel at redhat.com>
Date:   Wed Oct 20 17:43:12 2010 +0200

    intel-hda

commit 66914eb709923a5c842933034b2e626b8881c949
Author: Gerd Hoffmann <kraxel at redhat.com>
Date:   Wed Oct 20 08:29:30 2010 +0200

    more usb-audio work

commit ff1d92c7486b53e754c437fe2a07e24424898814
Author: Gerd Hoffmann <kraxel at redhat.com>
Date:   Mon Oct 18 17:18:44 2010 +0200

    usb-audio worrk

commit 534e479c43512168dcef24984004faaba123c79b
Author: Gerd Hoffmann <kraxel at redhat.com>
Date:   Sat Oct 16 00:34:52 2010 +0200

    usb-audio: add 4k buffer.

commit dd5e0feeda6897675014d1a890c6fdd1dd66f786
Author: Gerd Hoffmann <kraxel at redhat.com>
Date:   Thu Oct 14 16:20:35 2010 +0200

    usb-audio fixups
    
    * zap invasive -soundhw integration.
    * compile it unconditionally.
    * fixup initialization so "-device usb-audio" works.
    * make string table 256 entries long so the sanity check works.
    * add debug property for debug logging.

commit 0b76781f66a514054c2cba59731cd803afb8e3dc
Author: H. Peter Anvin <hpa at linux.intel.com>
Date:   Fri Sep 10 14:47:56 2010 -0700

    Add support for a USB audio device model
    
    I discovered that none of the audio device models supported by current
    Qemu/KVM appear to be supported out of the box on Win7 64 bit (AC97
    works fine on 32 bit).  The most logical ways to fix that would be to
    add a long-term supportable audio device model.  Intel HD Audio and
    USB Audio seemed like the most reasonable options, but I opted for USB
    Audio for a few reasons:
    
    a) as an external plugin device, it is more likely that it will be
       supported across a large number of guest operating systems for a
       very long time.
    b) as a vendor-independent class device, it is supported by the OS
       developers directly without any of the potential strange issues
       involved with relying on a vendor driver.
    c) USB Audio is highly parameterizable, which would make it possible
       to export all kinds of different audio models to the guest.  Note
       that due to the software-scheduled nature of [UOE]HCI, however,
       surround sound support (more than 4 channels) would require a High
       Speed device model with EHCI, or the guest OS will reject it as
       unschedulable (since it will exceed the schedulable bandwidth of a
       Full Speed USB bus.)
    
    This patch adds support for a USB audio device model.  It is based
    mostly on the "USB Basic Audio Device Specification", which consists
    of a set of profiles for the much more general "USB Audio
    Specification".  In accordance with the above profile, it supports
    48 kHz, 16-bit stereo only.
    
    It does work, "so far, so good".  However, it doesn't really provide a
    fully acceptable audio quality, because it suffers from a fundamental
    problem -- the rate of data provided by UHCI may not match the
    consumption rate of the sink.  I don't understand the Qemu audio
    subsystem well enough to know how to deal with that, which is why I
    would like comments and/or help (I really have spent way more time
    than I should on this already).  The full USB Audio specification has
    an optional concept of synchronization packets (a reverse channel
    which carry data rate information to be used for rate matching); this
    is specified in section 5.12.4.2 of the USB 2.0 specification (or
    5.10.4.2 of USB 1.1).  However, it isn't very clear to me how to get
    the relevant information out of the Qemu audio system.
    
    From a device model point of view, a data packet will arrive once per
    1 ms of USB time; this can be the time basis.  Presumably this needs
    to be used to compare against the number of samples actually consumed
    to construct the functional sample rate on the USB clock, as long as
    that information can be acquired.
    
    Not-yet-signed-off-by: H. Peter Anvin <hpa at linux.intel.com>