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
