From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55387) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z0pK8-00033r-KQ for qemu-devel@nongnu.org; Fri, 05 Jun 2015 06:58:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z0pK4-0006o1-11 for qemu-devel@nongnu.org; Fri, 05 Jun 2015 06:58:04 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37106) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z0pK3-0006nQ-Sy for qemu-devel@nongnu.org; Fri, 05 Jun 2015 06:57:59 -0400 Message-ID: <1433501871.4142.9.camel@redhat.com> From: Gerd Hoffmann Date: Fri, 05 Jun 2015 12:57:51 +0200 In-Reply-To: <5570CC69.2060409@gmail.com> References: <2e2fabdd19c4c81d40535244813fe42646557089.1433424889.git.DirtY.iCE.hu@gmail.com> <1433431821.3736.52.camel@nilsson.home.kraxel.org> <5570CC69.2060409@gmail.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH v2] qapi for audio backends List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?Q?K=C5=91v=C3=A1g=C3=B3_Zolt=C3=A1n?= Cc: qemu-devel@nongnu.org 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