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

Re: [libvirt] [PATCH 4/6] conf: introduce <output> element for <sound> devices



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 redhat com>
> > ---
> >  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


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