Re: [Qemu-devel] [RFC PATCH v2] qapi for audio backends

[Gerd Hoffmann <kraxel@redhat.com>]

  Hi,

> Plus currently only alsa an oss seem to care about this 
> option, so even if we keep it, we should probably move it into alsa's 
> and oss's backend options.

Makes sense.

> > Looks good to me as draft to start working with.  I expect we'll find
> > some details which need tweeking when implementing this.
> 
> Yeah, I've already hit a problem. The opts_visitor doesn't really handle 
> nested structs (it just flattens it into a single, non hierarchic 
> namespace), which is a problem because of the input and output options. 
> First I need to make them required (the in and out in Audiodev) if I 
> want the current visitor to visit them at all, but it's still not enough.

I think we should improve the visitor instead of making in & out
mandatory just because the current implementation (which simply
implements the stuff needed for Netdev) can't handle it.

> Doing something like -audiodev frequency=8000 sets the input frequency 
> to 8000 and leaves output frequency undefined. I think I should add an 
> additional syntax: -audiodev in.frequency=8000,out.frequency=16000 (of 
> course it should support deeper nesting like foo.bar.baz.asd=13). The 
> question is what should happen if the user specifies frequency=8000. I 
> see two alternatives:
> 
> 0. set every frequency field to 8000 (i.e. the same as 
> in.frequency=8000,out.frequency=8000 in this example)
> 1. bail out with a parameter ambiguous error
> 
> In the case of audiodev, the 0. approach seems more straightforward (if 
> the user sets frequency, he wants to set both input and output 
> frequency),

Agree.

>  but in more generic scenarios, the 1. is maybe better.

There is always the option to be more specific (in.frequency=...) if
setting all parameters named 'frequency' doesn't do what you want.  Also
I wouldn't worry too much about possible cases which don't exist right
now.  I'd suggest to go for (0).

cheers,
  Gerd