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

[Kővágó Zoltán]

Hi,

2015-06-04 17:30 keltezéssel, Gerd Hoffmann írta:
> > Not sure about this one, so it's not yet in this patch:
> > * remove poll_mode: another obscure setting, and it's only matter of time until
> >    the code bitrots enough to break it.
>
> I'd tend to drop this too, but it's probably good to check what exactly
> it is doing and to test whenever it actually works.

In my quick test it actually worked (but that was with pulseaudio's alsa 
emulation). 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.

> > Any comment is appreciated.
>
> 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.

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), but in more generic scenarios, the 1. is maybe better.

Thanks,
Zoltan