On Tue, Nov 21, 2017 at 01:25:33PM +0000, Daniel P. Berrange wrote:
> On Tue, Nov 14, 2017 at 02:45:09PM +0100, Pavel Hrdina wrote:
> > So far it was not possible to specify how the audio output from guest
> > should be presented to host/users. Now it will be possible to do so
> > via <output> element for <sound> device where you specify the output
> > "type".
> >
> > Signed-off-by: Pavel Hrdina <phrdina@xxxxxxxxxx>
> > ---
> > docs/formatdomain.html.in | 9 +++++++
> > docs/schemas/domaincommon.rng | 14 ++++++++++
> > src/conf/domain_conf.c | 61 +++++++++++++++++++++++++++++++++++++++++++
> > src/conf/domain_conf.h | 14 ++++++++++
> > src/libvirt_private.syms | 2 ++
> > 5 files changed, 100 insertions(+)
> >
>
> > +static int
> > +virDomainSoundOutputParseXML(xmlXPathContextPtr ctxt,
> > + virDomainSoundDefPtr sound)
> > +{
> > + int ret = -1;
> > + char *type = NULL;
> > + int typeVal;
> > + xmlNodePtr *outputNodes = NULL;
> > + int noutputs;
> > +
> > + noutputs = virXPathNodeSet("./output", ctxt, &outputNodes);
> > + if (noutputs < 0)
> > + return -1;
> > +
> > + if (noutputs > 1) {
> > + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
> > + _("sound device can have only one output configured"));
> > + goto cleanup;
> > + }
>
> The implication of this is that if you have multiple display backends enabled
> only one of them will ever be selectable as the audio backend. It is not
> unreasonable to consider that audio should go to all backends, or depending
> on which is in use. eg if QEMU has SDL + SPICE enabled, audio could
> conceptually go to SDL by default, and get dynamically switched to SPICE
> whenver there is a SPICE client actively connected. This is a risk of
> trying to design a configuration approach for this, without us asking
> QEMU to consider their corresponding design possibilities
Having this limitation now doesn't mean that we cannot remove it in the
future if QEMU implements a way how to configure multiple audio
backends. I can move it into qemuValidateCallback to make it QEMU
specific and if we need to remove it we can do so.
Pavel
Attachment:
signature.asc
Description: PGP signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
