From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: Standard PCM name? Date: Fri, 14 Jan 2005 13:06:41 +0100 Message-ID: References: <20050114113038.GA23735@palantir8> Mime-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Return-path: In-Reply-To: <20050114113038.GA23735@palantir8> Sender: alsa-devel-admin@lists.sourceforge.net Errors-To: alsa-devel-admin@lists.sourceforge.net List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: To: Martin Habets Cc: alsa-devel@lists.sourceforge.net List-Id: alsa-devel@alsa-project.org At Fri, 14 Jan 2005 11:30:39 +0000, Martin Habets wrote: > > On Thu, Jan 13, 2005 at 02:59:32PM +0100, Takashi Iwai wrote: > > Hi, > > > > on alsa-lib 1.0.8, I redefined the "default" PCM so that the > > card-specific definition can override. Together with this change, > > I added a feature to pass the card number for this pcm. > > i.e. > > aplay -Ddefault:1 foo.wav > > > > will play with the default PCM definition on the second card. > > > > I think this stuff itself, the card-specific default PCM definition, > > is nice. But it (e.g. default:1) won't work always if user overrides > > the default pcm via ~/.asoundrc. > > Could you give an example of this, please? Use '!' prefix: pcm.!default { type plug slave.pcm dmix } > > So, I'd like to propose a new set of PCM definition. > > > > - "default" doesn't take arguments (e.g. card number) but it defines > > the system default one. There is only one "default" for a system. > > > > - A new PCM, "std", is defined for each card. User shouldn't override > > this definition. When no card-specific definition is provided, it's > > defined as plughw:$CARD,$DEV. > > > > - The default "default" is std:0. > > > > The merit to split "default" and "std" is that std:X should always > > work regardless how default PCM is defined. > > How is "std:1" different from "hw:0"? "hw" always accesses directly to the hardware. If the hardware doesn't support the requested format, rate, etc, it fails. Although this can be absorbed via "plughw", still it isn't perfect. If the hardware requires some initialization/filter work for a certain setup (e.g. SPDIF output or software volume control), hw nor plughw can't do it properly. So, I do _not_ recommend to use "hw" or "plughw" at all unless you're sure what you're doing. (The exception is the system like JACK. It prefers to handle the hardware stuff directly, so it should be "hw" instead of "std".) OTOH, "std" is the standard definition for the card. It includes the necessary setup for most purposes. When the hardware doesn't have multi-play function, it goes through dmix. If the hardware doesn't have PCM volume control, it gotes through softvol. All these setups are included in std. std:1 means that the standard PCM for the secondary card (note that ALSA number os zero-based). > > Any comments? Better names? > > Maybe a name that is consistent with /dev/snd filenames, like "pcm"? Not bad. IMO, pcm.pcm (you write so when you define it) looks confusing, though. Or, how about "card"? Well it's also confusing, but the meaning is clear. % aplay -Dcard:1 foo.wav > It is not clear to me how you'd ultimately like to see user configure > their Alsa setup, and as a consequence what device sound applications > should use. From my limited knowledge I think this is your goal: > > 1) User sets default to "std:X" in .asoundrc. Only if user wants. "default" is the alias of std:0 unless overwritten. (Conceptually, the number 0 should be re-defined if user wants to use another card as default, instead of redefining "default" PCM itself.) I think the normal apps need only two PCM types: std and spdif. The std corresponds to the normal output. For the SPDIF output, "spdif" is probed. Or, even better, we can define the list of standard PCMs to be used in each card's definition. Then, the app just looks up these lists, ane let users choose in the configuration dialog. > Applications play to "default" device. Yes. > 2) Applications that do not specify a device play to "hw:0". (right?) No, hw:0 shouldn't be accessed normally. > After thinking about it, I'm getting pretty confused by it all. The best > approach for applications I think is not to specify a device at all, but > let .asoundrc and something like aconnect decide. It's a different concept. In the case of ALSA sequencer, the connection is open. You can change it on the fly. But, the current design of PCM interface needs the explicit destination for input/output. Of course, we can implement this kind of "virtual" PCM in future. But this isn't the matter we discuss here. Takashi ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt