qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 12/25] audio: basic support for multi backend au


From: Kővágó Zoltán
Subject: Re: [Qemu-devel] [PATCH 12/25] audio: basic support for multi backend audio
Date: Fri, 21 Aug 2015 14:23:10 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0

Hi

2015-08-20 20:01 keltezéssel, Marc-André Lureau írta:
[snip]
diff --git a/qemu-options.hx b/qemu-options.hx
index efd57e6..60a3563 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -1538,6 +1538,11 @@ everybody else.  'ignore' completely ignores the shared 
flag and
  allows everybody connect unconditionally.  Doesn't conform to the rfb
  spec but is traditional QEMU behavior.

address@hidden address@hidden
+
+Use the specified @var{audiodev} when the VNC client requests audio
+transmission.

That doesn't make much sense to me, vnc (or spice) should be connected
to the guest device, not to the audiodev. Same for for the wavcapture.

Hmm. Maybe it would make more sense, but it's not how the audio system works. The situation cyrrently (before my patch) is the following: VNC/spice/wavcapture attaches a capture to the global AudioState and starts recording/transmitting the mixed together audio of all connected guest sound cards.

Now with more audiodevs, you have to specify which one you wan't to capture from. If there's multiple sound cards attached to a single audiodev (AudioState), then we will transmit the mix of them. (If there's only one attached though, then we will only transmit that...)

To support capture from a single guest device would require some rewriting of the audio capture logic, in a backward compatible way (which would mean support both capturing form a single card and capturing a mix of all cards. And in the latter case we still need some way to specify audiodev...)

Zoltan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]