Standard PCM name?

Standard PCM name?

[Takashi Iwai]

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.

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.


Any comments?  Better names?


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

Re: Standard PCM name?

[Jaroslav Kysela]

On Thu, 13 Jan 2005, Takashi Iwai wrote:

> Any comments?  Better names?

cdefault ?

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs


-------------------------------------------------------
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

Re: Standard PCM name?

[Takashi Iwai]

At Thu, 13 Jan 2005 16:43:53 +0100 (CET),
Jaroslav wrote:
> 
> On Thu, 13 Jan 2005, Takashi Iwai wrote:
> 
> > Any comments?  Better names?
> 
> cdefault ?

I thought of an alike, but I feel it's a bit too long and too similar
with default.
Just a question of taste, though.


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

Re: Standard PCM name?

[Martin Habets]

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?

> 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"?

> Any comments?  Better names?

Maybe a name that is consistent with /dev/snd filenames, like "pcm"?

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. Applications play to "default"
   device.
2) Applications that do not specify a device play to "hw:0". (right?)

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.

Best regards,
-- 
Martin


-------------------------------------------------------
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

Re: Standard PCM name?

[Takashi Iwai]

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