mixer device

mixer device

[Ronald S. Bultje]

Hi,

for a given alsa device ("default", "dmix", "plughw:N", "hw:N,M",
"dspN", etc.), how do I automatically obtain the right device to use as
a audio mixer with that device? So far, it seems I can only attach to
"hw:N" mixer devices.

Thanks,

Ronald


-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver
higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Re: mixer device

[Clemens Ladisch]

Ronald S. Bultje wrote:
> for a given alsa device ("default", "dmix", "plughw:N", "hw:N,M",
> "dspN", etc.), how do I automatically obtain the right device to use as
> a audio mixer with that device?

Depends on your definition of "right device".  In the general case
this isn't possible because many cards don't have any mixer controls,
or don't have the controls you want to use.  Or the pcm device uses
several cards, or none.

What do you want to do with the mixer?

> So far, it seems I can only attach to "hw:N" mixer devices.

You can use any control device that is defined in your .asoundrc with
something like:

  ctl.xxxxx {
    type hw
    card N
  }


Regards,
Clemens




-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver
higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Re: mixer device

[Adam Tla/lka]

On Wed, May 12, 2004 at 05:40:55PM +0200, Clemens Ladisch wrote:
> Ronald S. Bultje wrote:
> > for a given alsa device ("default", "dmix", "plughw:N", "hw:N,M",
> > "dspN", etc.), how do I automatically obtain the right device to use as
> > a audio mixer with that device?
> 
> Depends on your definition of "right device".  In the general case
> this isn't possible because many cards don't have any mixer controls,
> or don't have the controls you want to use.  Or the pcm device uses
> several cards, or none.
> 
> What do you want to do with the mixer?
Hmm - typically people just want to control PCM volume.
When using OSS you can just do mixer ioctl's on the opened PCM fd.
Simple and clear. With many virtual PCM streams it is working
too (non-free version).
If we haven't hardware volume control this function is emulated.
It is not working with ALSA OSS emulation nor aoss.
So how a program could in a simple way obtain information which control to
use to set the volume level of particular stream?

ALSA is complicated and we have no good manual describing proper use
of its api. You can easily prove this: many programs have ALSA output
modules but they are working worse then when using OSS.
For example mplayer with OSS synchronizes video and sound much faster
in case of network streaming. XMMS is broken too.
In ALSA you could play/record samples in many ways: just read/write,
callbacks, poll, memory mapping. Not all ways are good working.
Some are working poorly in some conditions. So maybe we should have
simpler API but working good enough. My opinion is that lib can be
written no so clearly but API shuld be as clean and easy to use
as possible. It should be constructed from user point of view.
How easy is to use it and which functionality it gives us.

Regards
-- 
Adam Tla/lka      mailto:atlka@pg.gda.pl    ^v^ ^v^ ^v^
System  & Network Administration Group           ~~~~~~
Computer Center,  Gdansk University of Technology, Poland
PGP public key:   finger atlka@sunrise.pg.gda.pl


-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click

Re: mixer device

[Paul Davis]

>When using OSS you can just do mixer ioctl's on the opened PCM fd.

When using OSS, you can't model a lot of the functionality present in
contemporary audio interface hardware mixers.

So there's a choice: a limited, simple API that fails to support card
features, or a complex API that over time gets a simpler version added
to it.

Right now, ALSA is following the second path, but is not very far
along the "simpler API" part of it.

>as possible. It should be constructed from user point of view.

What user? A programmer? A home theater owner who wants to move AC3
data from a DVD through their 5.1 system? A professional studio owner
with 48 channels of digital I/O? A game player? A web browser?

I think that *applications* needs to be designed from a user point of
view, not APIs. And APIs need to, in those famous words, "make easy
things easy, hard things simple and the impossible a little difficult".

>How easy is to use it and which functionality it gives us.

I have never been a big fan of the way that the ALSA API has turned
out, but as someone who has followed it all the way from 0.4 onwards,
I have to acknowledge that there are good reasons, mostly very good
reasons, for nearly every aspect of its design.

I wrote JACK to massively simplify the abstraction used by audio
applications, but it doesn't address the mixer situation. 


-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click

Re: mixer device

[Giuliano Pochini]

On 13-May-2004 Adam Tla/lka wrote:

>> What do you want to do with the mixer?
> Hmm - typically people just want to control PCM volume.
> When using OSS you can just do mixer ioctl's on the opened PCM fd.
> Simple and clear.

No, it's not simple, unless the driver makes it simple
removing some capabilities of the card. For example the
Echoaudio Mia hasn't a PCM volume control. It has a mixer
that mixes 8 PCM channels into 4 physical channels. In
order to change the PCM volume of one of the eight
channels you have to change the levels of a whole row of
the mixer. Similarly, all other Echoaudio cards don't
have a line-out volume control and to change the volume
of one output channel you have to change the PCM volume
of that channel *and* a whole column of the monitor mixer.
I guess there are some cards that are more complex than
those. I exported the raw controls and I handle everything
in user-space with a dedicated "console" program similar
to the one shipped with the windos drivers.


> So how a program could in a simple way obtain information which
> control to use to set the volume level of particular stream?

Good question. The current approach is based on the control
names but sometimes they're not enough. What do you suggest ?



--
Giuliano.


-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click

Re: mixer device

[Adam Tla/lka]

On Thu, May 13, 2004 at 06:28:17PM +0200, Giuliano Pochini wrote:
> Good question. The current approach is based on the control
> names but sometimes they're not enough. What do you suggest ?
I am testing changed aoss lib which uses dmix plugin 
to play simultaniously many stereo sound sources.
Now I can use JavaSoundDemo, sound in Flash pages in mozilla,
Q1, Q2 and Q3, xmms and mplayer at once. Of course playing 
simulaniously many Quake games is resource consuming and has no 
practical sense but for demonstration purposes its ok.

OK - there is many different hardware on the market and some cards
are multichannel, some are not, some of them have limited mixers or none.

So maybe we could create an abstract sound card which has a mixer and is
a multichannel one (and could mix many 5.1 sources too ;-)).
Now if a real card has ability to do this we use hardware, and if not
we emulate functionality in software. Example of doing mixer functions
on open PCM stream is a good one. Typical sound program just opens
it's PCM stream, sets the volume level, plays sounds and exits closing
stream. Of course we have programs which need know more about hardware.
OK and this all should be supported too. But typical desktop usage
is to play a few sounds simultaniously (desktop events, Internet music,
browser sounds etc..) and set their volume independently.
There are some sound daemons of course. But we have different daemons
working with different desktops (KDE, GNOME) and even supporting
particular group of programs. All of this is a big mess. So maybe better
solution is to implement this functions at the sound card level.

Regards

-- 
Adam Tla/lka      mailto:atlka@pg.gda.pl    ^v^ ^v^ ^v^
System  & Network Administration Group           ~~~~~~
Computer Center,  Gdansk University of Technology, Poland
PGP public key:   finger atlka@sunrise.pg.gda.pl


-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click

Re: mixer device

[Ronald S. Bultje]

On Wed, 2004-05-12 at 17:40, Clemens Ladisch wrote:
> Ronald S. Bultje wrote:
> > for a given alsa device ("default", "dmix", "plughw:N", "hw:N,M",
> > "dspN", etc.), how do I automatically obtain the right device to use as
> > a audio mixer with that device?
> 
> Depends on your definition of "right device".  In the general case
> this isn't possible because many cards don't have any mixer controls,
> or don't have the controls you want to use.  Or the pcm device uses
> several cards, or none.
> 
> What do you want to do with the mixer?

Change the volume, as hinted by others.

So, given your .asoundrc hint, is it possible for me to get the
cardnumber (and thereby the hw:N entry) for a given non-hw device (e.g.
dspN, hw:N,M, dmix, ...)? Either via libalsa or by manually parsing the
asoundrc or whatever interface is provided to do that for me? This
should be possible for at least plughw:N and hw:N,M card entries (well,
that's simple, I can just parse the string, but I'm looking for
something inside libalsa).

Ronald


-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click

Re: mixer device

[Clemens Ladisch]

Ronald S. Bultje wrote:
> is it possible for me to get the cardnumber (and thereby the hw:N
> entry) for a given non-hw device (e.g. dspN, hw:N,M, dmix, ...)?

Try something like this:

/* Get the slave pcm of a pcm node.  Caller must free the result. */
static snd_config_t *get_pcm_slave_pcm(snd_config_t *pcm)
{
	snd_config_t *slave;
	snd_config_t *result = NULL;
	int free_slave = 0;
	const char *str;

	if (snd_config_search(pcm, "slave", &slave) < 0)
		goto _exit;
	if (snd_config_get_string(slave, &str) >= 0) {
		if (snd_config_search_definition(snd_config, "pcm_slave", str, &slave) < 0)
			goto _exit;
		free_slave = 1;
	}
	if (snd_config_get_type(slave) != SND_CONFIG_TYPE_COMPOUND)
		goto _exit;

	if (snd_config_search(slave, "pcm", &pcm) < 0)
		goto _exit;
	if (snd_config_get_string(pcm, &str) >= 0) {
		if (snd_config_search_definition(snd_config, "pcm", str, &pcm) >= 0)
			result = pcm;
	} else {
		/* always make a dynamic copy, because the caller frees it */
		if (snd_config_copy(&pcm, pcm) >= 0)
			result = pcm;
	}
_exit:
	if (free_slave)
		snd_config_delete(slave);
	return result;
}

/* Get the card number from a pcm node.  Searches recursively. */
static int get_pcm_card(snd_config_t *pcm)
{
	snd_config_t *slave_pcm;
	snd_config_t *card_node;
	long card;

	if (snd_config_get_type(pcm) != SND_CONFIG_TYPE_COMPOUND)
		return -1;
	slave_pcm = get_pcm_slave_pcm(pcm);
	if (slave_pcm) {
		card = get_pcm_card(slave_pcm);
		snd_config_delete(slave_pcm);
		return card;
	} else if (snd_config_search(pcm, "card", &card_node) >= 0) {
		const char *str;
		if (snd_config_get_integer(card_node, &card) >= 0)
			return card;
		if (snd_config_get_string(card_node, &str) >= 0)
			return snd_card_get_index(str);
	}
	return -1;
}

/* Get the card number from a pcm device name. */
static int get_named_pcm_card(const char *pcm_name)
{
	snd_config_t *pcm;
	int card;

	if (snd_config_update() < 0)
		return -1;

	if (snd_config_search_definition(snd_config, "pcm", pcm_name, &pcm) < 0)
		return -1;
	card = get_pcm_card(pcm);
	snd_config_delete(pcm);
	return card;
}


/* ... */
card = get_named_pcm_card(pcm_name);
if (card >= 0)
	sprintf(ctl_name, "hw:CARD=%d", card);
else
	/* unknown card */


HTH
Clemens




-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click

ALSA lib application compatibility [was] Re: mixer device

[Manuel Jander]

Hi,

On Tue, 2004-05-18 at 15:46 +0200, barat@medien.uni-weimar.de wrote:
> On Thu, 13 May 2004, Adam Tla/lka wrote:
> 
> > On Wed, May 12, 2004 at 05:40:55PM +0200, Clemens Ladisch wrote:
> > 
> > ALSA is complicated and we have no good manual describing proper use
> > of its api. You can easily prove this: many programs have ALSA output
> > modules but they are working worse then when using OSS.
> > For example mplayer with OSS synchronizes video and sound much faster
> > in case of network streaming. XMMS is broken too.
> ?? mplayer isn't broken in any way with alsa. it supports alsa since the 
> early days and also current versions very well. please don't talk 
> bullshit.
> it probably does av-sync faster at some particular streams (what ever you 
> mean with that) with oss, but i never ever saw some significant 
> performance differences compared to oss.
> at least it supports real mmaped-io for up to 2 channels.
> 

Unfortunately i have to agree with Clemens. In my opinion the ALSA API
is giving the applications too much freedom in choosing parameters and
does not enforce any restrictions on hardware that can't support them.

As the main author of the Aureal Vortex driver, its very stupid having
to handle arbitrary period sizes, introducing a lot of overhead and
complexity in the driver, while the hardware just is not designed to
handle period sizes that are not powers of two, due to page boundary
overlapping trouble. Obviously as a result, OSS works much better, since
it almost ever chooses the biggest buffer possible, resulting in a sane
period size. Period sizes of 314.15.14 bytes are just silly, plain
stupid. The user won't notice any difference if its 256 instead, but
since the app insist in such period sizes it just fails, and the user
gets no sound all. The behaviour of the user application in the end
depends too much on the hardware it is running on.

AFAIK, the ICE1712 has exactly the same hardware restriction. I know
that the via driver does cope with this, but that particular hardware
has special hardware resources for such a thing, where other hardware
don't.
The cost of allowing any parameter value is not worth it in my opinion.
Its actually causing a lot of trouble.

Well, i don't ask for changes in the ALSA API, but for teaching
application developers to -please- be polite to the ALSA drivers, and to
take into account the possible restriction they apply.

Best Regards

Manuel Jander




-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click

Re: mixer device

[barat]

On Thu, 13 May 2004, Adam Tla/lka wrote:

> On Wed, May 12, 2004 at 05:40:55PM +0200, Clemens Ladisch wrote:
> > Ronald S. Bultje wrote:
> > > for a given alsa device ("default", "dmix", "plughw:N", "hw:N,M",
> > > "dspN", etc.), how do I automatically obtain the right device to use as
> > > a audio mixer with that device?
> > 
> > Depends on your definition of "right device".  In the general case
> > this isn't possible because many cards don't have any mixer controls,
> > or don't have the controls you want to use.  Or the pcm device uses
> > several cards, or none.
> > 
> > What do you want to do with the mixer?
> Hmm - typically people just want to control PCM volume.
> When using OSS you can just do mixer ioctl's on the opened PCM fd.
> Simple and clear. With many virtual PCM streams it is working
> too (non-free version).
> If we haven't hardware volume control this function is emulated.
> It is not working with ALSA OSS emulation nor aoss.
> So how a program could in a simple way obtain information which control to
> use to set the volume level of particular stream?
> 
> ALSA is complicated and we have no good manual describing proper use
> of its api. You can easily prove this: many programs have ALSA output
> modules but they are working worse then when using OSS.
> For example mplayer with OSS synchronizes video and sound much faster
> in case of network streaming. XMMS is broken too.
?? mplayer isn't broken in any way with alsa. it supports alsa since the 
early days and also current versions very well. please don't talk 
bullshit.
it probably does av-sync faster at some particular streams (what ever you 
mean with that) with oss, but i never ever saw some significant 
performance differences compared to oss.
at least it supports real mmaped-io for up to 2 channels.

best regards / mit freundlichen gruessen

Zsolt Barat



-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click

Re: ALSA lib application compatibility [was] Re: [Alsa-devel] mixer device

[Manuel Jander]

Hi,

On Tue, 2004-05-18 at 17:00 +0200, Takashi Iwai wrote:
> At Tue, 18 May 2004 09:30:54 -0400,
> Manuel Jander wrote:
> > 
> > Hi,
> > 
> > On Tue, 2004-05-18 at 15:46 +0200, barat@medien.uni-weimar.de wrote:
> > > On Thu, 13 May 2004, Adam Tla/lka wrote:
> > > 
> > > > On Wed, May 12, 2004 at 05:40:55PM +0200, Clemens Ladisch wrote:
> > > > 
> > > > ALSA is complicated and we have no good manual describing proper use
> > > > of its api. You can easily prove this: many programs have ALSA output
> > > > modules but they are working worse then when using OSS.
> > > > For example mplayer with OSS synchronizes video and sound much faster
> > > > in case of network streaming. XMMS is broken too.
> > > ?? mplayer isn't broken in any way with alsa. it supports alsa since the 
> > > early days and also current versions very well. please don't talk 
> > > bullshit.
> > > it probably does av-sync faster at some particular streams (what ever you 
> > > mean with that) with oss, but i never ever saw some significant 
> > > performance differences compared to oss.
> > > at least it supports real mmaped-io for up to 2 channels.
> > > 
> > 
> > Unfortunately i have to agree with Clemens. In my opinion the ALSA API
> > is giving the applications too much freedom in choosing parameters and
> > does not enforce any restrictions on hardware that can't support them.
> 
> basically, such a restriction is up to the driver.  in the ideal
> world, hw_constraints should be able to handle these cases
> properly...

Yeah, right, but many application just fail. Even aplay is very picky
about impossible period sizes sometimes.

> > As the main author of the Aureal Vortex driver, its very stupid having
> > to handle arbitrary period sizes, introducing a lot of overhead and
> > complexity in the driver, while the hardware just is not designed to
> > handle period sizes that are not powers of two, due to page boundary
> > overlapping trouble. Obviously as a result, OSS works much better, since
> > it almost ever chooses the biggest buffer possible, resulting in a sane
> > period size. Period sizes of 314.15.14 bytes are just silly, plain
> > stupid. The user won't notice any difference if its 256 instead, but
> > since the app insist in such period sizes it just fails, and the user
> > gets no sound all. The behaviour of the user application in the end
> > depends too much on the hardware it is running on.
> 
> first, the power of two is not a golden rule for every sound chip.
> for some chips, it's difficult to handle such period/buffer sizes.

Yes, it just a particular case in the chip took as example...

> in theory, we can set the hw_constraint for the buffer/period sizes in
> power of two.  yes, i tried it, but it failed.  this is because ALSA
> handles the buffer/period sizes in two different units, frames and
> time in msec.  IMO, it was a wrong decision to use different units for
> the single purpose.  maybe we need a workaround not to mix up these
> units in the configurator.

Yes, i think that the hardware constraint scheme of ALSA is very
powerful, but the problem is that it fails. It would be great if it
could be mopified to be failproof, that is, allow the application to
work somehow regardless of what restrictions must be taken.

> > AFAIK, the ICE1712 has exactly the same hardware restriction. I know
> > that the via driver does cope with this, but that particular hardware
> > has special hardware resources for such a thing, where other hardware
> > don't.
> 
> ICE1712 has no problem regarding this.  its problem is that the
> max. buffer size is 64k even though it always uses 32bit x 10
> channels.
> 
> > The cost of allowing any parameter value is not worth it in my opinion.
> > Its actually causing a lot of trouble.
> 
> not all parameters are accepted.  it depends on the driver
> implementation.

That right, but applications should be able to cope with that, and use
alternative fallback values.

> please don't misunderstand:  i don't mean that the current ALSA design
> is perfect.  it's not at all, as you know :)
> however, the basic design of ALSA is that it leaves such a
> reststriction purely to the driver implementation.  if your driver
> allows everyhing, it's the driver's responsibility to support
> everyhing.

Thats why i'm trying to contribute some feedback :D

> unfortunately, the power-of-two restriction doesn't work well because
> of the failure of configurator.  it's an exceptional case.

Thats bad luck :(

Best Regards

Manuel Jander





-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click

Re: ALSA lib application compatibility [was] Re: mixer device

[James Courtier-Dutton]

Manuel Jander wrote:
> 
> As the main author of the Aureal Vortex driver, its very stupid having
> to handle arbitrary period sizes, introducing a lot of overhead and
> complexity in the driver, while the hardware just is not designed to
> handle period sizes that are not powers of two, due to page boundary
> overlapping trouble. 

You don't have to handle arbitary period sizes in the alsa-driver.
Here is an example from the emu10k1 driver, that restricts what period 
sizes the application can use for caputure.

static unsigned int capture_period_sizes[31] = {
         384,    448,    512,    640,
         384*2,  448*2,  512*2,  640*2,
         384*4,  448*4,  512*4,  640*4,
         384*8,  448*8,  512*8,  640*8,
         384*16, 448*16, 512*16, 640*16,
         384*32, 448*32, 512*32, 640*32,
         384*64, 448*64, 512*64, 640*64,
         384*128,448*128,512*128
};

static snd_pcm_hw_constraint_list_t hw_constraints_capture_period_sizes = {
         .count = 31,
         .list = capture_period_sizes,
         .mask = 0
};

static int snd_emu10k1_capture_open(snd_pcm_substream_t * substream)
{
<snip>
snd_pcm_hw_constraint_list(runtime, 0, SNDRV_PCM_HW_PARAM_PERIOD_SIZE, 
&hw_constraints_capture_period_sizes);

<snip>

Has a driver writer, you have full control over these sorts of things.

Cheers
James


-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click

Re: ALSA lib application compatibility [was] Re: mixer device

[Takashi Iwai]

At Tue, 18 May 2004 09:30:54 -0400,
Manuel Jander wrote:
> 
> Hi,
> 
> On Tue, 2004-05-18 at 15:46 +0200, barat@medien.uni-weimar.de wrote:
> > On Thu, 13 May 2004, Adam Tla/lka wrote:
> > 
> > > On Wed, May 12, 2004 at 05:40:55PM +0200, Clemens Ladisch wrote:
> > > 
> > > ALSA is complicated and we have no good manual describing proper use
> > > of its api. You can easily prove this: many programs have ALSA output
> > > modules but they are working worse then when using OSS.
> > > For example mplayer with OSS synchronizes video and sound much faster
> > > in case of network streaming. XMMS is broken too.
> > ?? mplayer isn't broken in any way with alsa. it supports alsa since the 
> > early days and also current versions very well. please don't talk 
> > bullshit.
> > it probably does av-sync faster at some particular streams (what ever you 
> > mean with that) with oss, but i never ever saw some significant 
> > performance differences compared to oss.
> > at least it supports real mmaped-io for up to 2 channels.
> > 
> 
> Unfortunately i have to agree with Clemens. In my opinion the ALSA API
> is giving the applications too much freedom in choosing parameters and
> does not enforce any restrictions on hardware that can't support them.

basically, such a restriction is up to the driver.  in the ideal
world, hw_constraints should be able to handle these cases
properly...

> As the main author of the Aureal Vortex driver, its very stupid having
> to handle arbitrary period sizes, introducing a lot of overhead and
> complexity in the driver, while the hardware just is not designed to
> handle period sizes that are not powers of two, due to page boundary
> overlapping trouble. Obviously as a result, OSS works much better, since
> it almost ever chooses the biggest buffer possible, resulting in a sane
> period size. Period sizes of 314.15.14 bytes are just silly, plain
> stupid. The user won't notice any difference if its 256 instead, but
> since the app insist in such period sizes it just fails, and the user
> gets no sound all. The behaviour of the user application in the end
> depends too much on the hardware it is running on.

first, the power of two is not a golden rule for every sound chip.
for some chips, it's difficult to handle such period/buffer sizes.

in theory, we can set the hw_constraint for the buffer/period sizes in
power of two.  yes, i tried it, but it failed.  this is because ALSA
handles the buffer/period sizes in two different units, frames and
time in msec.  IMO, it was a wrong decision to use different units for
the single purpose.  maybe we need a workaround not to mix up these
units in the configurator.


> AFAIK, the ICE1712 has exactly the same hardware restriction. I know
> that the via driver does cope with this, but that particular hardware
> has special hardware resources for such a thing, where other hardware
> don't.

ICE1712 has no problem regarding this.  its problem is that the
max. buffer size is 64k even though it always uses 32bit x 10
channels.

> The cost of allowing any parameter value is not worth it in my opinion.
> Its actually causing a lot of trouble.

not all parameters are accepted.  it depends on the driver
implementation.


please don't misunderstand:  i don't mean that the current ALSA design
is perfect.  it's not at all, as you know :)
however, the basic design of ALSA is that it leaves such a
reststriction purely to the driver implementation.  if your driver
allows everyhing, it's the driver's responsibility to support
everyhing.

unfortunately, the power-of-two restriction doesn't work well because
of the failure of configurator.  it's an exceptional case.


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click

RE: ALSA lib application compatibility [was] Re: mi

[Giuliano Pochini]

On 18-May-2004 Manuel Jander wrote:

> Unfortunately i have to agree with Clemens. In my opinion the ALSA API
> is giving the applications too much freedom in choosing parameters and
> does not enforce any restrictions on hardware that can't support them.

I don't thing that freedom is a bad thing.


> As the main author of the Aureal Vortex driver, its very stupid having
> to handle arbitrary period sizes, introducing a lot of overhead and
> complexity in the driver, while the hardware just is not designed to
> handle period sizes that are not powers of two, due to page boundary
> overlapping trouble.

If the hw can't do something, the driver shouldn't try to do it. The
lowlevel driver is supposed to be "low level", ie. it's not a complete
HAL and it shouldn't emulate functions the hw can't do itself.


> Obviously as a result, OSS works much better, since
> it almost ever chooses the biggest buffer possible, resulting in a sane
> period size. Period sizes of 314.15.14 bytes are just silly, plain
> stupid. The user won't notice any difference if its 256 instead, but
> since the app insist in such period sizes it just fails, and the user
> gets no sound all. The behaviour of the user application in the end
> depends too much on the hardware it is running on.

On broken applications, yes, it is. Because when an app does
snd_pcm_hw_param_set_xyz_near() and then it crashes if the
retured settings are not what the app expects, please blame the
application, not alsa.
IMHO the problems are: 1) lack of good documentation and 2) ALSA is a
new interface and people is not as experienced with it as with OSS yet
3) ALSA is more generic and pushes the hw more than OSS, exposing hw
quirks and unknown "features" that causes troubles. I took two months
to find what made my Gina24 go berserk sometimes in unpredictable
and hardly reproducible ways. :-/


> Well, i don't ask for changes in the ALSA API, but for teaching
> application developers to -please- be polite to the ALSA drivers,
> and to take into account the possible restriction they apply.

I agree.


--
Giuliano.


-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click

Re: Re: ALSA lib application compatibility [was] Re: [Alsa-devel] mixer device

[Jaroslav Kysela]

On Tue, 18 May 2004, Manuel Jander wrote:

> Yes, i think that the hardware constraint scheme of ALSA is very
> powerful, but the problem is that it fails. It would be great if it
> could be mopified to be failproof, that is, allow the application to
> work somehow regardless of what restrictions must be taken.

The simplified parameter initization routine (simple PCM extension) will 
take care about this in alsa-lib. This routine should find the "right" 
period/buffer sizes specified with the requested latency for any hardware.
It is possible that we'll have some workarounds for very specific hardware
there.

						Jaroslav

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


-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click