_test_channels() / plug:surround51 / Hardware Mixing And dmix / SW or HW Resampling / Volume Control

_test_channels() / plug:surround51 / Hardware Mixing And dmix / SW or HW Resampling / Volume Control

[Daniel Yek]

[-- Attachment #1.1: Type: text/plain, Size: 2510 bytes --]

Hi,

I have a lot of questions here; please feel free to pick and choose while 
answering them. I hope all questions will eventually be answered.

(A) Test Channels:

I have the following sound card.
Card: Intel ICH7
Chip: Analog Devices AD1981B
(AD1981B is AC '97 2.3 Compliant CODEC, 2 Channels of Audio with SPDIF)

Why the following code reports that the system supports 6 channels audio 
when the "default" device is used?
   channels = 6;
   snd_pcm_hw_params_test_channels( PCMHandle, hwparams, channels);

As a result, many channels were simply lost, not being heard. The same 
happens even on a 5.1 system if "default" device is used.

(B) Plug:

If opening "surround51" device failed, does it make sense for a media 
application to try to open "plug:surround51"?

Would "plug" play 5.1 channels content without losing any channel?

Or would it make more sense for the application to mix the channels into a 
2 channels output (in software)?

(C)  dmix:

Does ALSA use dmix if the sound card supports hardware mixing?

Are there different levels of hardware mixing supports? That is, if a sound 
card has hardware mixing support, does it always has 5.1 channel hardware 
mixing support?

ALSA library version 1.0.9rc2 and later is using dmix by default.
In the case of the sound card supporting hardware mixing, should a 
demanding media application prefers another device name because "default" 
is now configured with dmix?

If an application opens "surround51" device, would it hold the device 
exclusively and preventing other media application from using it?

If so, are they any standard dmix device name for surround51?


(D) Sampling Rate:

What is the best Sampling Rate to be produced by a media application for 
ALSA and ALSA dmix device?

The following page claimed that dmix write directly to the soundcard's DMA 
buffer.
Does that implicitly referring to sound card with hardware mixer?
http://www.alsa-project.org/alsa-doc/doc-php/asoundrc.php

The same page says that ALSA dmix device is default to RATE=48000.
With sound quality in mind, should a media application with resampling 
capability tries to resample to 48000Hz in software or should it let dmix 
or the hardware handle resampling?


(E) Volume Control:

How can I use ALSA's Playback controls volume level interface?
Is it for the application to use or more for alsa-lib?
Refer to http://www.sabi.co.uk/Notes/linuxSoundALSA.html

Are there any per-process Volume Control interface available?

Thanks very much.

-- 
Daniel

[-- Attachment #1.2: Type: text/html, Size: 2908 bytes --]

[-- Attachment #2: Type: text/plain, Size: 348 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: _test_channels() / plug:surround51 / Hardware Mixing And dmix / SW or HW Resampling / Volume Control

[Takashi Iwai]

At Thu, 28 Sep 2006 01:54:47 -0700,
Daniel Yek wrote:
> 
> Hi,
> 
> I have a lot of questions here; please feel free to pick and choose while answering
> them. I hope all questions will eventually be answered.
> 
> (A) Test Channels:
> 
> I have the following sound card.
> Card: Intel ICH7
> Chip: Analog Devices AD1981B
> (AD1981B is AC '97 2.3 Compliant CODEC, 2 Channels of Audio with SPDIF)
> 
> Why the following code reports that the system supports 6 channels audio
> when the "default" device is used? 
>   channels = 6;
>   snd_pcm_hw_params_test_channels( PCMHandle, hwparams, channels);
> 
> As a result, many channels were simply lost, not being heard. The same happens even on
> a 5.1 system if "default" device is used.

This function returns whether the sound system _accepts_ the given
number of channels.  It doesn't care whether it's really played or
not.  Since "default" PCM uses plug layer, it accepts any number of
channels.

> (B)
> 
> Plug:
> 
> If opening "surround51" device failed, does it make sense for a
> media application to try to open "plug:surround51"?
> 
> Would "plug" play 5.1 channels content without losing any
> channel? 

If _opening_ surround51 fails, it's usually a problem of device
assignment (e.g. the device is already in use).  The surround51
usually doesn't do softmixing unlike "default" PCM.

The plug layer would be useful if you play sample formats that the
hardware doesn't support, for example, playing 16bit format on ICE1712
boards.  Basically, it's safe to use "plug:surround51" when you know
you are going to play 5.1 sound.  But, this doesn't guarantee that the
device can be opened (because of non-dmix nature).

> Or would it make more sense for the application to mix the channels into
> a 2 channels output (in software)?

No.

> (C) 
> 
> dmix:
> 
> Does ALSA use dmix if the sound card supports hardware mixing?

No (usually).  The configuration file for each driver is written to
use the appropriate hw or plughw for such a hardware (e.g. emu10k1).

> Are there different levels of hardware mixing supports? That is, if a
> sound card has hardware mixing support, does it always has 5.1 channel
> hardware mixing support?

Not really.  Currently, surround* and iec958 (spdif) are supposed to
be non-mixing devices unless the hardware supports.
The setup of 5.1-dmix isn't provided in the standard configuration
yet.

> ALSA library version 1.0.9rc2 and later is using dmix by default.
> In the case of the sound card supporting hardware mixing, should a
> demanding media application prefers another device name because
> "default" is now configured with dmix?

Yes.

> If an application opens "surround51" device, would it hold the
> device exclusively and preventing other media application from using it?

Yes (in most cases).

> If so, are they any standard dmix device name for surround51?

Not yet.  It's one of TODOs.

> (D)
> 
> Sampling Rate:
> 
> What is the best Sampling Rate to be produced by a media application for
> ALSA and ALSA dmix device?

48000.  In the recent version, it can be changed via a system-wide
setup (defaults.pcm.dmix_rate), though.

> The following page claimed that dmix write directly to the soundcard's
> DMA buffer. 
> Does that implicitly referring to sound card with hardware mixer?
> 
> http://www.alsa-project.org/alsa-doc/doc-php/asoundrc.php

No.

> The same page says that ALSA dmix device is default to RATE=48000.
> With sound quality in mind, should a media application with resampling
> capability tries to resample to 48000Hz in software or should it let dmix
> or the hardware handle resampling?

The dmix cannot use the hardware resampling because the hardware _is_
running on 48kHz.

Once ago I made an experimental patch to change dmix code to accept
both 44.1 and 48kHz depending on the first application.  But it's
racy, so isn't a good solution yet...


> (E)
> 
> Volume Control:
> 
> How can I use ALSA's Playback controls volume level interface?
> Is it for the application to use or more for alsa-lib?
> Refer to
> 
> http://www.sabi.co.uk/Notes/linuxSoundALSA.html

Every ALSA-native mixer app uses the mixer API.
Also, some media players use it, too.

> Are there any per-process Volume Control interface available?

Not yet.  It's on my TODO list.

Currently, a player needs to pick up either "Master", "PCM" or
whatever existing volume element.


Takashi

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: _test_channels() / plug:surround51 / Hardware Mixing And dmix / SW or HW Resampling / Volume Control

[Lee Revell]

On Thu, 2006-09-28 at 15:17 +0200, Takashi Iwai wrote:
> > ALSA library version 1.0.9rc2 and later is using dmix by default.
> > In the case of the sound card supporting hardware mixing, should a
> > demanding media application prefers another device name because
> > "default" is now configured with dmix?
> 
> Yes.
> 

Really?  I thought the "default" device was supposed to do the right
thing, hardware mixing or not.

Lee


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: _test_channels() / plug:surround51 / Hardware Mixing And dmix / SW or HW Resampling / Volume Control

[Takashi Iwai]

At Thu, 28 Sep 2006 10:40:59 -0400,
Lee Revell wrote:
> 
> On Thu, 2006-09-28 at 15:17 +0200, Takashi Iwai wrote:
> > > ALSA library version 1.0.9rc2 and later is using dmix by default.
> > > In the case of the sound card supporting hardware mixing, should a
> > > demanding media application prefers another device name because
> > > "default" is now configured with dmix?
> > 
> > Yes.
> > 
> 
> Really?  I thought the "default" device was supposed to do the right
> thing, hardware mixing or not.

Grr, I misread the question completely.  Sorry.

A mediaplayer can/should use "default" PCM (unless wants explicitly
5.1 sounds etc).  The default PCM skips dmix is hw-mixing is
available.

BTW, for the secondary card, you can use like the style like
"default:1".  This will choose the default PCM of the secondary card.


Takashi

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: _test_channels() / plug:surround51 / Hardware Mixing And dmix / SW or HW Resampling / Volume Control

[Takashi Iwai]

At Thu, 28 Sep 2006 16:46:55 +0200,
I wrote:
> 
> At Thu, 28 Sep 2006 10:40:59 -0400,
> Lee Revell wrote:
> > 
> > On Thu, 2006-09-28 at 15:17 +0200, Takashi Iwai wrote:
> > > > ALSA library version 1.0.9rc2 and later is using dmix by default.
> > > > In the case of the sound card supporting hardware mixing, should a
> > > > demanding media application prefers another device name because
> > > > "default" is now configured with dmix?
> > > 
> > > Yes.
> > > 
> > 
> > Really?  I thought the "default" device was supposed to do the right
> > thing, hardware mixing or not.
> 
> Grr, I misread the question completely.  Sorry.
> 
> A mediaplayer can/should use "default" PCM (unless wants explicitly
> 5.1 sounds etc).  The default PCM skips dmix is hw-mixing is
> available.

s/is hw-mixing/if hw-mixing/


Takashi

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Default soundcard (UDEV?)

[Jaroslav Kysela]

On Thu, 28 Sep 2006, Takashi Iwai wrote:

> BTW, for the secondary card, you can use like the style like
> "default:1".  This will choose the default PCM of the secondary card.

Note that perhaps we should change what the default card means. In the 
sense of udev mechanism, devices should be detected and enumerated in 
system. We have actually no way (and it will be very problematic) to 
change the soundcard number in the ALSA driver. Fortunately, we have extra 
card id (which is not very much used) which can be perfectly used for this 
purpose and it can be also changed at runtime (so udev rules can reassing 
for example the default card).

I would propose that "default" will refer always to a card with id 
"default" (and if no card will have this id, first soundcard will be used 
as now). At driver initialization, first card becomes as "default", then 
user or udev can rename it to something else.

Also, extra udev support should be added to match devices from longname or 
shortname (see control API and SYSFS{}).

Opinions (except that we should learn users to use "logical 
identification" not card numbers)?

						Jaroslav

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

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: Default soundcard (UDEV?)

[Lee Revell]

On Thu, 2006-09-28 at 17:06 +0200, Jaroslav Kysela wrote:
> Opinions (except that we should learn users to use "logical 
> identification" not card numbers)? 

ALSA device naming is a constant FAQ.  There's no document anywhere that
explains the syntax or even basic things like 'apps should always use
"default" device', '"default:x" can be used to address the second card',
that cards can be addressed by name, etc.  Look at how many apps only
enumerate the hw:x devices.

One paragraph of documentation on device naming could greatly reduce
user confusion and improve the level of ALSA support in applications.

I think a great start would be to write up Takashi-san's answers to
Daniel Yek in the recent thread.

Lee


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: Default soundcard (UDEV?)

[Takashi Iwai]

At Thu, 28 Sep 2006 17:06:08 +0200 (CEST),
Jaroslav Kysela wrote:
> 
> On Thu, 28 Sep 2006, Takashi Iwai wrote:
> 
> > BTW, for the secondary card, you can use like the style like
> > "default:1".  This will choose the default PCM of the secondary card.
> 
> Note that perhaps we should change what the default card means. In the 
> sense of udev mechanism, devices should be detected and enumerated in 
> system. We have actually no way (and it will be very problematic) to 
> change the soundcard number in the ALSA driver. Fortunately, we have extra 
> card id (which is not very much used) which can be perfectly used for this 
> purpose and it can be also changed at runtime (so udev rules can reassing 
> for example the default card).
> 
> I would propose that "default" will refer always to a card with id 
> "default" (and if no card will have this id, first soundcard will be used 
> as now). At driver initialization, first card becomes as "default", then 
> user or udev can rename it to something else.
> 
> Also, extra udev support should be added to match devices from longname or 
> shortname (see control API and SYSFS{}).
> 
> Opinions (except that we should learn users to use "logical 
> identification" not card numbers)?

The logical id (aka persistent name) is a good invention, but actually
it forces apps to change its code.  This is not easy.  Thus, we can
never drop the style like "hw:1" while we may provide the new support
of logical id.

That is, we'd need eventually an internal map between the logical id
and the numerical id.  Currently it's in the driver side, but this
could be in alsa-lib once if the device connection is moved to the
persistent device-file names.

(BTW, I very much agree with changing the semantics of "default:1".
 Originally I proposed to use a different name, but we didn't get
 consensus to a solid name, so "default" was chosen as compromise.)


IMO, the first thing we have to do above the things above is to
provide an easy-to-use device enumeration API.  This must be as simple
as possible, just let apps to choose a device.  No more, no less.

We have already some framework for enumeration, but it's unfortunately
useless right now.  Partly because it requires extra work (to call
alsactl names), and partly because it's incomplete.

Once after we get this, the naming doesn't matter so much because apps
simply choose from the names the system provides.  (Of course, apps
may ask you arbitrary string for device, but the basic operatoin
should be a selection from the list.)  That's why I find it's more
important here...


Takashi

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: Default soundcard (UDEV?)

[Jaroslav Kysela]

On Thu, 28 Sep 2006, Takashi Iwai wrote:

> At Thu, 28 Sep 2006 17:06:08 +0200 (CEST),
> Jaroslav Kysela wrote:
> > 
> > On Thu, 28 Sep 2006, Takashi Iwai wrote:
> > 
> > > BTW, for the secondary card, you can use like the style like
> > > "default:1".  This will choose the default PCM of the secondary card.
> > 
> > Note that perhaps we should change what the default card means. In the 
> > sense of udev mechanism, devices should be detected and enumerated in 
> > system. We have actually no way (and it will be very problematic) to 
> > change the soundcard number in the ALSA driver. Fortunately, we have extra 
> > card id (which is not very much used) which can be perfectly used for this 
> > purpose and it can be also changed at runtime (so udev rules can reassing 
> > for example the default card).
> > 
> > I would propose that "default" will refer always to a card with id 
> > "default" (and if no card will have this id, first soundcard will be used 
> > as now). At driver initialization, first card becomes as "default", then 
> > user or udev can rename it to something else.
> > 
> > Also, extra udev support should be added to match devices from longname or 
> > shortname (see control API and SYSFS{}).
> > 
> > Opinions (except that we should learn users to use "logical 
> > identification" not card numbers)?
> 
> The logical id (aka persistent name) is a good invention, but actually
> it forces apps to change its code.  This is not easy.  Thus, we can
> never drop the style like "hw:1" while we may provide the new support
> of logical id.

I do not propose to change the current behaviour. We do not require any 
changes in alsa-lib except changing "defaults.pcm.card 0" to 
"defaults.pcm.card "default"" (and handle fallback to first soundcard).

> That is, we'd need eventually an internal map between the logical id
> and the numerical id.  Currently it's in the driver side, but this
> could be in alsa-lib once if the device connection is moved to the
> persistent device-file names.

I am against any kind of remapping based on the card index. It would be 
more confusing.

> (BTW, I very much agree with changing the semantics of "default:1".
>  Originally I proposed to use a different name, but we didn't get
>  consensus to a solid name, so "default" was chosen as compromise.)

Note that "default:Intel" (or replace Intel with your card id) works now.
I don't see any collision. You may refer device using logical or 
physical name.

> IMO, the first thing we have to do above the things above is to
> provide an easy-to-use device enumeration API.  This must be as simple
> as possible, just let apps to choose a device.  No more, no less.
> 
> We have already some framework for enumeration, but it's unfortunately
> useless right now.  Partly because it requires extra work (to call
> alsactl names), and partly because it's incomplete.

We all know that the problem with right enumeration is that we have 
virtual names and arguments, so we have basically unlimited number of 
choices.

I would propose to return a list of devices consisting from:

a) basic devices on top of hardware (default:X, hw:X, surround...)
b) user selectable list (from asoundrc or global configuration)

If we merge these two lists, we can offer to applications something basic 
for standard users. Of course, all apps should have a possibility to 
enter another device name.

						Jaroslav

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

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: Default soundcard (UDEV?)

[Takashi Iwai]

At Thu, 28 Sep 2006 18:00:41 +0200 (CEST),
Jaroslav Kysela wrote:
> 
> On Thu, 28 Sep 2006, Takashi Iwai wrote:
> 
> > At Thu, 28 Sep 2006 17:06:08 +0200 (CEST),
> > Jaroslav Kysela wrote:
> > > 
> > > On Thu, 28 Sep 2006, Takashi Iwai wrote:
> > > 
> > > > BTW, for the secondary card, you can use like the style like
> > > > "default:1".  This will choose the default PCM of the secondary card.
> > > 
> > > Note that perhaps we should change what the default card means. In the 
> > > sense of udev mechanism, devices should be detected and enumerated in 
> > > system. We have actually no way (and it will be very problematic) to 
> > > change the soundcard number in the ALSA driver. Fortunately, we have extra 
> > > card id (which is not very much used) which can be perfectly used for this 
> > > purpose and it can be also changed at runtime (so udev rules can reassing 
> > > for example the default card).
> > > 
> > > I would propose that "default" will refer always to a card with id 
> > > "default" (and if no card will have this id, first soundcard will be used 
> > > as now). At driver initialization, first card becomes as "default", then 
> > > user or udev can rename it to something else.
> > > 
> > > Also, extra udev support should be added to match devices from longname or 
> > > shortname (see control API and SYSFS{}).
> > > 
> > > Opinions (except that we should learn users to use "logical 
> > > identification" not card numbers)?
> > 
> > The logical id (aka persistent name) is a good invention, but actually
> > it forces apps to change its code.  This is not easy.  Thus, we can
> > never drop the style like "hw:1" while we may provide the new support
> > of logical id.
> 
> I do not propose to change the current behaviour. We do not require any 
> changes in alsa-lib except changing "defaults.pcm.card 0" to 
> "defaults.pcm.card "default"" (and handle fallback to first soundcard).

Hm, then I misunderstood.  I thought you meintioned the persistent
device files via udev (like ethernet and disk)...

> > That is, we'd need eventually an internal map between the logical id
> > and the numerical id.  Currently it's in the driver side, but this
> > could be in alsa-lib once if the device connection is moved to the
> > persistent device-file names.
> 
> I am against any kind of remapping based on the card index. It would be 
> more confusing.

Yeah, it's a workaround if we were to move to the persistent device
files.  Then there would be no number in the device file any more.

> > (BTW, I very much agree with changing the semantics of "default:1".
> >  Originally I proposed to use a different name, but we didn't get
> >  consensus to a solid name, so "default" was chosen as compromise.)
> 
> Note that "default:Intel" (or replace Intel with your card id) works now.
> I don't see any collision. You may refer device using logical or 
> physical name.

I know.  That's why I mentioned numbers.
Since no real applications use this id string at all (AFAIK), it
doesn't help to cry "Hey but we already support it!"...
My point is to keep the number scheme compatible like before _even if_
we are obliged to move to persistent device files.

> > IMO, the first thing we have to do above the things above is to
> > provide an easy-to-use device enumeration API.  This must be as simple
> > as possible, just let apps to choose a device.  No more, no less.
> > 
> > We have already some framework for enumeration, but it's unfortunately
> > useless right now.  Partly because it requires extra work (to call
> > alsactl names), and partly because it's incomplete.
> 
> We all know that the problem with right enumeration is that we have 
> virtual names and arguments, so we have basically unlimited number of 
> choices.
> 
> I would propose to return a list of devices consisting from:
> 
> a) basic devices on top of hardware (default:X, hw:X, surround...)

Returning both default and hw makes little sense, rather confusing.
The apps don't (shouldn't) care what black magic is done in the
background.  (Note that the apps I suppose here are not the sound
system like JACK but media players, voip, recorders, etc.)

Maybe we'd better to think in another way from user's point of view.
Imagine to let app choose one entry per card or function (currently
identifed as "default").  And, you can set up the card default
differently per purpose, such as 5.1, or SPDIF output.  In this way,
the list becomes small, and you can still configure the devices.
This sounds more logical to me.  However...

The problem in this scheme is that the ALSA setup isn't dynamically
configurable.  Once you open a device, it's bound to a specific
purpose.  If you change the setup (e.g. from 2 to 5.1 channels) while
opening a device, it's not reflected to the running system.
Also the crash (race) of different configurations is another issue,
especially for dmix.  So, this is not an easy option.

> b) user selectable list (from asoundrc or global configuration)

A new attirbute in the definition would be needed since we shouldn't
list all available defitions (like aplay -L currently does).  Only the
definitions with such an attribute are listed as selectable devices.
Then you can have a description for each definition, too.


Takashi

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

_test_channels() / plug:surround51 / Hardware Mixing And dmix / SW or HW Resampling / Volume Control

[Daniel Yek]

Hi,

I have a few more follow-up questions inline...

At 06:17 AM 9/28/2006, Takashi Iwai wrote:
>At Thu, 28 Sep 2006 01:54:47 -0700,
>Daniel Yek wrote:
<...snip...>
> >
> > (A) Test Channels:
> >
> > I have the following sound card.
> > Card: Intel ICH7
> > Chip: Analog Devices AD1981B
> > (AD1981B is AC '97 2.3 Compliant CODEC, 2 Channels of Audio with SPDIF)
> >
> > Why the following code reports that the system supports 6 channels audio
> > when the "default" device is used?
> >   channels = 6;
> >   snd_pcm_hw_params_test_channels( PCMHandle, hwparams, channels);
> >
> > As a result, many channels were simply lost, not being heard. The same 
> happens even on
> > a 5.1 system if "default" device is used.
>
>This function returns whether the sound system _accepts_ the given
>number of channels.  It doesn't care whether it's really played or
>not.  Since "default" PCM uses plug layer, it accepts any number of
>channels.

What is the right way to figure out if the hardware associated with the 
"plug:surround51" PCM is capable of playing in 5.1 mode? I need to know 
this because in the case the hardware isn't 5.1-ready, I would like to 
fallback to 2-channel playback. On systems incapable of 5.1 playback all 
PCMs seem to drop channels; that is bad.

What is usually happening when "surround51" is aliased to "default" PCM and 
"plug:surround51" is asked to accept 6 channels (5.1) playback? Where the 
extra channels were discarded? Was it in "plug"? (Or could it be dmix? The 
hardware mixer has nothing to do with this right?)


> > (B)
> >
> > Plug:
> >
> > If opening "surround51" device failed, does it make sense for a
> > media application to try to open "plug:surround51"?
> >
> > Would "plug" play 5.1 channels content without losing any
> > channel?
>
>If _opening_ surround51 fails, it's usually a problem of device
>assignment (e.g. the device is already in use).  The surround51
>usually doesn't do softmixing unlike "default" PCM.
>
>The plug layer would be useful if you play sample formats that the
>hardware doesn't support, for example, playing 16bit format on ICE1712
>boards.  Basically, it's safe to use "plug:surround51" when you know
>you are going to play 5.1 sound.  But, this doesn't guarantee that the
>device can be opened (because of non-dmix nature).
>
> > Or would it make more sense for the application to mix the channels into
> > a 2 channels output (in software)?
>
>No.

If "no" is the answer, I would have to ask: why then doing software 
down-mixing sounds much better than playing in 5.1 mode? (That is channels 
were not lost if software down-mixing is used. See "aplay -v" output at the 
bottom of this email.) Is there anything I am missing?




> > (C)
> >
> > dmix:
> >
> > Does ALSA use dmix if the sound card supports hardware mixing?
>
>No (usually).  The configuration file for each driver is written to
>use the appropriate hw or plughw for such a hardware (e.g. emu10k1).

Glad to know that.


> > Are there different levels of hardware mixing supports? That is, if a
> > sound card has hardware mixing support, does it always has 5.1 channel
> > hardware mixing support?
>
>Not really.  Currently, surround* and iec958 (spdif) are supposed to
>be non-mixing devices unless the hardware supports.
>The setup of 5.1-dmix isn't provided in the standard configuration
>yet.
>
> > ALSA library version 1.0.9rc2 and later is using dmix by default.
> > In the case of the sound card supporting hardware mixing, should a
> > demanding media application prefers another device name because
> > "default" is now configured with dmix?
>
>A mediaplayer can/should use "default" PCM (unless wants explicitly
>5.1 sounds etc).  The default PCM skips dmix if hw-mixing is
>available.
>
>BTW, for the secondary card, you can use like the style like
>"default:1".  This will choose the default PCM of the secondary card.

Thanks!


> > If an application opens "surround51" device, would it hold the
> > device exclusively and preventing other media application from using it?
>
>Yes (in most cases).
>
> > If so, are they any standard dmix device name for surround51?
>
>Not yet.  It's one of TODOs.
>
> > (D)
> >
> > Sampling Rate:
> >
> > What is the best Sampling Rate to be produced by a media application for
> > ALSA and ALSA dmix device?
>
>48000.  In the recent version, it can be changed via a system-wide
>setup (defaults.pcm.dmix_rate), though.
>
> > The following page claimed that dmix write directly to the soundcard's
> > DMA buffer.
> > Does that implicitly referring to sound card with hardware mixer?
> >
> > http://www.alsa-project.org/alsa-doc/doc-php/asoundrc.php
>
>No.
>
> > The same page says that ALSA dmix device is default to RATE=48000.
> > With sound quality in mind, should a media application with resampling
> > capability tries to resample to 48000Hz in software or should it let dmix
> > or the hardware handle resampling?
>
>The dmix cannot use the hardware resampling because the hardware _is_
>running on 48kHz.
>
>Once ago I made an experimental patch to change dmix code to accept
>both 44.1 and 48kHz depending on the first application.  But it's
>racy, so isn't a good solution yet...
>
>
> > (E)
> >
> > Volume Control:
> >
> > How can I use ALSA's Playback controls volume level interface?
> > Is it for the application to use or more for alsa-lib?
> > Refer to
> >
> > http://www.sabi.co.uk/Notes/linuxSoundALSA.html
>
>Every ALSA-native mixer app uses the mixer API.
>Also, some media players use it, too.
>
> > Are there any per-process Volume Control interface available?
>
>Not yet.  It's on my TODO list.
>
>Currently, a player needs to pick up either "Master", "PCM" or
>whatever existing volume element.
>
>
>Takashi


Aplay verbose output (only 2 channels were heard):

aplay -v --device=default --format=S16_LE --channels=6 --file-type raw 
--rate=44100 wave.dat

Playing raw data 'wave.dat' : Signed 16 bit Little Endian, Rate 44100 Hz, 
Channels 6
Plug PCM: Route conversion PCM (sformat=S16_LE)
   Transformation table:
     0 <- 0
     1 <- 1
Its setup is:
   stream       : PLAYBACK
   access       : RW_INTERLEAVED
   format       : S16_LE
   subformat    : STD
   channels     : 6
   rate         : 44100
   exact rate   : 44100 (44100/1)
   msbits       : 16
   buffer_size  : 15052
   period_size  : 940
   period_time  : 21333
   tick_time    : 0
   tstamp_mode  : NONE
   period_step  : 1
   sleep_min    : 0
   avail_min    : 940
   xfer_align   : 940
   start_threshold  : 15040
   stop_threshold   : 15052
   silence_threshold: 0
   silence_size : 0
   boundary     : 986447872
Slave: Rate conversion PCM (48000, sformat=S16_LE)
Its setup is:
   stream       : PLAYBACK
   access       : MMAP_INTERLEAVED
   format       : S16_LE
   subformat    : STD
   channels     : 2
   rate         : 44100
   exact rate   : 44100 (44100/1)
   msbits       : 16
   buffer_size  : 15052
   period_size  : 940
   period_time  : 21333
   tick_time    : 0
   tstamp_mode  : NONE
   period_step  : 1
   sleep_min    : 0
   avail_min    : 940
   xfer_align   : 940
   start_threshold  : 15040
   stop_threshold   : 15052
   silence_threshold: 0
   silence_size : 0
   boundary     : 986447872
Slave: Direct Stream Mixing PCM
Its setup is:
   stream       : PLAYBACK
   access       : MMAP_INTERLEAVED
   format       : S16_LE
   subformat    : STD
   channels     : 2
   rate         : 48000
   exact rate   : 48000 (48000/1)
   msbits       : 16
   buffer_size  : 16384
   period_size  : 1024
   period_time  : 21333
   tick_time    : 0
   tstamp_mode  : NONE
   period_step  : 1
   sleep_min    : 0
   avail_min    : 1024
   xfer_align   : 1024
   start_threshold  : 16384
   stop_threshold   : 16384
   silence_threshold: 0
   silence_size : 0
   boundary     : 1073741824
Hardware PCM card 0 'Intel ICH7' device 0 subdevice 0
Its setup is:
   stream       : PLAYBACK
   access       : MMAP_INTERLEAVED
   format       : S16_LE
   subformat    : STD
   channels     : 2
   rate         : 48000
   exact rate   : 48000 (48000/1)
   msbits       : 16
   buffer_size  : 16384
   period_size  : 1024
   period_time  : 21333
   tick_time    : 4000
   tstamp_mode  : NONE
   period_step  : 1
   sleep_min    : 0
   avail_min    : 1024
   xfer_align   : 1024
   start_threshold  : 1
   stop_threshold   : 1073741824
   silence_threshold: 0
   silence_size : 1073741824
   boundary     : 1073741824

Thanks again!

-- 

Daniel Yek


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: _test_channels() / plug:surround51 / Hardware Mixing And dmix / SW or HW Resampling / Volume Control

[Takashi Iwai]

At Thu, 28 Sep 2006 16:44:26 -0700,
Daniel Yek wrote:
> 
> Hi,
> 
> I have a few more follow-up questions inline...
> 
> At 06:17 AM 9/28/2006, Takashi Iwai wrote:
> >At Thu, 28 Sep 2006 01:54:47 -0700,
> >Daniel Yek wrote:
> <...snip...>
> > >
> > > (A) Test Channels:
> > >
> > > I have the following sound card.
> > > Card: Intel ICH7
> > > Chip: Analog Devices AD1981B
> > > (AD1981B is AC '97 2.3 Compliant CODEC, 2 Channels of Audio with SPDIF)
> > >
> > > Why the following code reports that the system supports 6 channels audio
> > > when the "default" device is used?
> > >   channels = 6;
> > >   snd_pcm_hw_params_test_channels( PCMHandle, hwparams, channels);
> > >
> > > As a result, many channels were simply lost, not being heard. The same 
> > happens even on
> > > a 5.1 system if "default" device is used.
> >
> >This function returns whether the sound system _accepts_ the given
> >number of channels.  It doesn't care whether it's really played or
> >not.  Since "default" PCM uses plug layer, it accepts any number of
> >channels.
> 
> What is the right way to figure out if the hardware associated with the 
> "plug:surround51" PCM is capable of playing in 5.1 mode? I need to know 
> this because in the case the hardware isn't 5.1-ready, I would like to 
> fallback to 2-channel playback. On systems incapable of 5.1 playback all 
> PCMs seem to drop channels; that is bad.

So far, the channel configuration is decided at the time opening a
device via snd_pcm_open().  That is, the PCM name (e.g. "default",
"surround51") is bound to a certain functional preset.

So, if the app is sure to play 5.1 sounds, it first opens
"surround51".  If the open fails, it can open "default" as fallback.

> What is usually happening when "surround51" is aliased to "default" PCM and 
> "plug:surround51" is asked to accept 6 channels (5.1) playback? Where the 
> extra channels were discarded? Was it in "plug"? (Or could it be dmix? The 
> hardware mixer has nothing to do with this right?)

Well, the "default" should be configured to accept the (almost) all
setting.  If user changed its surround51 and the system denies 2
channels, it's basically user's fault.

"surround51" requires 6-channels.  It might accept other channels in
test functions, but this PCM is defined only for 6-channels.  The
extra channels are discarded in the plug layer. 

The plug is actually a collection of several plugins, rate, linear and
route.  It's a kind of do-all-conversion.  It's route plugin that
takes care of channel expansion and shrinkage.  This plugin discards
the extra channels, and copies the missing channels, etc.  The
behavior changes slightly depending on the configuration option.

The dmix takes only the pre-defined number of channels (usually 2).
It can take more channels when set up differently (e.g. dmix for 5.1),
but it's not provided in the standard system, as I mentioned in the
last post.

All around this, the hardware mixing plays no role at all.  It's only
the question whether the hardware accepts the given number of channels
or not.  The h/w mixing is independent from this.


> > > (B)
> > >
> > > Plug:
> > >
> > > If opening "surround51" device failed, does it make sense for a
> > > media application to try to open "plug:surround51"?
> > >
> > > Would "plug" play 5.1 channels content without losing any
> > > channel?
> >
> >If _opening_ surround51 fails, it's usually a problem of device
> >assignment (e.g. the device is already in use).  The surround51
> >usually doesn't do softmixing unlike "default" PCM.
> >
> >The plug layer would be useful if you play sample formats that the
> >hardware doesn't support, for example, playing 16bit format on ICE1712
> >boards.  Basically, it's safe to use "plug:surround51" when you know
> >you are going to play 5.1 sound.  But, this doesn't guarantee that the
> >device can be opened (because of non-dmix nature).
> >
> > > Or would it make more sense for the application to mix the channels into
> > > a 2 channels output (in software)?
> >
> >No.
> 
> If "no" is the answer, I would have to ask: why then doing software 
> down-mixing sounds much better than playing in 5.1 mode? (That is channels 
> were not lost if software down-mixing is used. See "aplay -v" output at the 
> bottom of this email.) Is there anything I am missing?

Ah, I now understand what you wanted.
Yes, as a fallback, it's a good idea that app does downmixing by
itself when it cannot open 5.1 output.  In future, we can set up the
default to do more clever up/downmixing (we have already such
plugins).  But (from portability POV) a media player could do it
better right now.


Takashi

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

5.1 surround sound playback XRUN / snd_pcm_writei() didn't unblock immediately / small 114 msec buffer

[Daniel Yek]

Hi,

I opened "surround51" PCM device and set the sampling rate to 48000, S16_LE 
format. I requested 500000 usec (0.5 sec) of buffer time, but I got back 
only 113770 usec. (equals to 65532 bytes.) Is there a way I can get a 
bigger buffer size? Does it depend on the driver or ALSA can typically 
provide more?

I used snd_pcm_writei() in blocking mode, transferring 28800 bytes (2400 
frames) at a time. After two writes (buffer about full), the third write 
blocked for 95 msec. Soon after, the function blocked for 128 msec, caused 
XRUN. Is snd_pcm_writei() in blocking mode suitable for 5.1 channels 
playback without XRUNs? Why snd_pcm_writei() didn't unblock immediately 
when snd_pcm_avail_update() returned 5044 frames (105 msec.) available?

I'm going to try a non-blocking snd_pcm_writei() solution. Do you think it 
is the answer to the XRUN problem?

Thank you very much.


-- 
Daniel Yek


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: 5.1 surround sound playback XRUN / snd_pcm_writei() didn't unblock immediately / small 114 msec buffer

[Clemens Ladisch]

Daniel Yek wrote:
> I opened "surround51" PCM device and set the sampling rate to 48000, S16_LE 
> format.

Better use "plug:surround51".  There are chips like ICE1712 that do not
support any format except S32_LE.

> I requested 500000 usec (0.5 sec) of buffer time, but I got back only
> 113770 usec. (equals to 65532 bytes.) Is there a way I can get a
> bigger buffer size?

You can try writing a value larger than 64 to
/proc/asound/card?/pcm?p/sub?/prealloc, but drivers for on-board
controllers typically don't support more than 128 KB.

There are drivers that force you to have even smaller or larger buffers.

> Does it depend on the driver or ALSA can typically provide more?

The maximum size is set by the driver, but many PCI sound drivers use a
random value of 128 or 256 KB although the hardware could support more.

> I used snd_pcm_writei() in blocking mode, transferring 28800 bytes (2400 
> frames) at a time. After two writes (buffer about full), the third write 
> blocked for 95 msec. Soon after, the function blocked for 128 msec, caused 
> XRUN. Is snd_pcm_writei() in blocking mode suitable for 5.1 channels 
> playback without XRUNs? Why snd_pcm_writei() didn't unblock immediately 
> when snd_pcm_avail_update() returned 5044 frames (105 msec.) available?

In theory, playback with a ~100 ms buffer should be possible.

There are several possibilities why your program wasn't waken up fast
enough:
1) The period size is too high.  The period size specifies the interval
   after which the hardware issues an interrupt.  If the buffer is full,
   you have to wait at least until the next period boundary before ALSA
   can detect that some part of the buffer is free.
   You should try to have at least about five periods per buffer.
2) avail_min and or xfer_align are set too high.  avail_min specifies
   how much free space must be in the buffer before snd_pcm_writei()
   continues writing; xfer_align specifies the minimum size of a block
   to write into the buffer.  The default value of both parameters is
   the period size, but this is not appropriate for your application;
   you don't want to wait before writing even the smallest possible
   amount.
   Set both these software parameters to one frame.
3) Some other process or thread was executed and prevented
   snd_pcm_writei() from executing.  This shouldn't be too much a
   problem because the kernel reschedules every 4 ms.  Make sure the
   priority of your audio thread is higher than the default.

> I'm going to try a non-blocking snd_pcm_writei() solution. Do you think it 
> is the answer to the XRUN problem?

No.  Using non-blocking writes does not change the wake-up behaviour.


HTH
Clemens

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: 5.1 surround sound playback XRUN / snd_pcm_writei() didn't unblock immediately / small 114 msec buffer

[Daniel Yek]

Hi Clemens,

First of all, thank you for the helpful remarks and suggestions.

I have comments inline...

At 06:09 AM 10/6/2006, Clemens Ladisch wrote:
>Daniel Yek wrote:
> > I opened "surround51" PCM device and set the sampling rate to 48000, 
> S16_LE
> > format.
>
>Better use "plug:surround51".  There are chips like ICE1712 that do not
>support any format except S32_LE.

It would be great if somebody could suggest an easy way for a media 
application to identify if the system is 5.1-channels capable. After making 
sure that 5.1-channels playback is preferable over 2-channels playback, I 
can then use "plug:surround51" PCM device. I assume that Plug will convert 
all 6 channels without dropping any here. If not, it is not usable.

Right now, I'm depending on opening "surround51" PCM device to fail to 
indicate that the system isn't 5.1-channels capable. "plug:surround51" PCM 
wouldn't open-fail even if the system isn't 5.1-channels capable, resulting 
in a poor playback experience. Do you have a suggestion for me?



> > I requested 500000 usec (0.5 sec) of buffer time, but I got back only
> > 113770 usec. (equals to 65532 bytes.) Is there a way I can get a
> > bigger buffer size?
>
>You can try writing a value larger than 64 to
>/proc/asound/card?/pcm?p/sub?/prealloc, but drivers for on-board
>controllers typically don't support more than 128 KB.

This worked. XRUN is reduced or eliminated in this case. This would be one 
way to have (root) users fix the systems if other methods don't work.

Thanks.

<...snip...>

> > I used snd_pcm_writei() in blocking mode, transferring 28800 bytes (2400
> > frames) at a time. After two writes (buffer about full), the third write
> > blocked for 95 msec. Soon after, the function blocked for 128 msec, caused
> > XRUN. Is snd_pcm_writei() in blocking mode suitable for 5.1 channels
> > playback without XRUNs? Why snd_pcm_writei() didn't unblock immediately
> > when snd_pcm_avail_update() returned 5044 frames (105 msec.) available?
>
>In theory, playback with a ~100 ms buffer should be possible.
>
>There are several possibilities why your program wasn't waken up fast
>enough:
>1) The period size is too high.  The period size specifies the interval
>    after which the hardware issues an interrupt.  If the buffer is full,
>    you have to wait at least until the next period boundary before ALSA
>    can detect that some part of the buffer is free.
>    You should try to have at least about five periods per buffer.
>2) avail_min and or xfer_align are set too high.  avail_min specifies
>    how much free space must be in the buffer before snd_pcm_writei()
>    continues writing; xfer_align specifies the minimum size of a block
>    to write into the buffer.  The default value of both parameters is
>    the period size, but this is not appropriate for your application;
>    you don't want to wait before writing even the smallest possible
>    amount.
>    Set both these software parameters to one frame.

Thanks! I'll try it out.


>3) Some other process or thread was executed and prevented
>    snd_pcm_writei() from executing.  This shouldn't be too much a
>    problem because the kernel reschedules every 4 ms.  Make sure the
>    priority of your audio thread is higher than the default.
>
> > I'm going to try a non-blocking snd_pcm_writei() solution. Do you think it
> > is the answer to the XRUN problem?
>
>No.  Using non-blocking writes does not change the wake-up behaviour.
>
>
>HTH
>Clemens


You are so helpful. Thank you very much.


-- 
Daniel Yek


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: 5.1 surround sound playback XRUN / snd_pcm_writei() didn't unblock immediately / small 114 msec buffer

[Clemens Ladisch]

Daniel Yek wrote:
> At 06:09 AM 10/6/2006, Clemens Ladisch wrote:
> >Daniel Yek wrote:
> > > I opened "surround51" PCM device and set the sampling rate to 48000, S16_LE
> > > format.
> >
> >Better use "plug:surround51".  There are chips like ICE1712 that do not
> >support any format except S32_LE.
> 
> It would be great if somebody could suggest an easy way for a media 
> application to identify if the system is 5.1-channels capable. After making 
> sure that 5.1-channels playback is preferable over 2-channels playback, I 
> can then use "plug:surround51" PCM device. I assume that Plug will convert 
> all 6 channels without dropping any here. If not, it is not usable.
> 
> Right now, I'm depending on opening "surround51" PCM device to fail to 
> indicate that the system isn't 5.1-channels capable. "plug:surround51" PCM 
> wouldn't open-fail even if the system isn't 5.1-channels capable, resulting 
> in a poor playback experience. Do you have a suggestion for me?

The configuration files won't define a "surround51" device if the
hardware is not capable of accepting 5.1 sound, so opening
"plug:surround51" should fail as expected.


HTH
Clemens

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV