Asoundrc - Revision history

Simplify: /* The naming of PCM devices */ Corrected a non-breaking space. It was misspelled.

2014-02-09T17:10:43Z

The naming of PCM devices: Corrected a non-breaking space. It was misspelled.

← Older revision		Revision as of 17:10, 9 February 2014
Line 87:		Line 87:
	As with most arrays the first item usually starts at <code>0</code> not <code>1</code>. This is true for the way pcm devices (physical I/O channels) are represented in ALSA. Starting at <code>pcm0c</code> (capture), <code>pcm0p</code> (playback).		As with most arrays the first item usually starts at <code>0</code> not <code>1</code>. This is true for the way pcm devices (physical I/O channels) are represented in ALSA. Starting at <code>pcm0c</code> (capture), <code>pcm0p</code> (playback).

	We use subdevices mainly for hardware which can mix several streams together. It is impractical to have 32 devices with exactly the same capabilities. The subdevices can be opened without a specific address, so the first free subdevice is opened. Also, we temporarily use subdevices for hardware with a lot of streams (I/O connectors)&~~bnsp~~;— for example MIDI. There are several limits given by used minor numbers (8 PCM devices per card, 8 MIDI devices per card etc.).		We use subdevices mainly for hardware which can mix several streams together. It is impractical to have 32 devices with exactly the same capabilities. The subdevices can be opened without a specific address, so the first free subdevice is opened. Also, we temporarily use subdevices for hardware with a lot of streams (I/O connectors) — for example MIDI. There are several limits given by used minor numbers (8 PCM devices per card, 8 MIDI devices per card etc.).

	For example, to access the first device on the first soundcard/device, you would use		For example, to access the first device on the first soundcard/device, you would use

AndreasMohr: Add global config framework overview explanation

2013-11-07T21:20:25Z

Add global config framework overview explanation

← Older revision		Revision as of 21:20, 7 November 2013
Line 7:		Line 7:

	Neither the user-side <code>.asoundrc</code> nor the <code>asound.conf</code> configuration files are required for ALSA to work properly. Most applications will work without them. These files are used to allow extra functionality, such as routing and sample-rate conversion, through the alsa-lib layer.		Neither the user-side <code>.asoundrc</code> nor the <code>asound.conf</code> configuration files are required for ALSA to work properly. Most applications will work without them. These files are used to allow extra functionality, such as routing and sample-rate conversion, through the alsa-lib layer.
	The reason that most applications will work without these user-side custom config files is that usually a default install of alsa-lib provides a sufficiently capable setup consisting of hierarchical config files (which make use of the standard .asoundrc format syntax as well), specifically capable of supporting certain soundcard brands.		The actual reason that most applications will work without these user-side custom config files is that usually a default install of alsa-lib provides a sufficiently capable setup consisting of hierarchical config files (which always make use of the standard .asoundrc format syntax as well), which are specifically capable of supporting certain soundcard brands each.
			Thus, let's start with a quick overview of how ALSA config file framework evaluation is composed, globally:

	==~~The .asoundrc~~ file==		==Global view of ALSA config file framework, executive summary==

	This file allows you to have more advanced control over your card/device. The <code>.asoundrc</code> file consists of definitions of the various cards available in your system. It also gives you access to the pcm plugins in alsa-lib. These allow you to do tricky things like combine your cards into one or access multiple I/Os on your ~~mulitchannel~~ card.		The alsa-lib package (at least on Debian libasound2-data 1.0.27) provides the /usr/share/alsa/alsa.conf file as the ''main entry point''.
			That file is responsible for including the full list of potential .asoundrc-format-type files on the system.
			It contains a reference to the ALSA "DATADIR" (Debian: /usr/share/alsa/).
			It continues by loading the DATADIR's cards/aliases.conf file: that one defines translation mappings from the kernel driver's sound card name (as listed at /proc/asound/cards, or aplay -Ll) to a "more detailed" description string. That "more detailed name" of a sound card then gets used to lookup a corresponding card-specific config file at DATADIR/cards/CARD.conf.
			And THAT card-specific file then attempts to provide a maximally elegant sound setup for its specific card brand, by compensating for various limitations of cards (e.g. use dmix to combat single-stream playback only, or stereo downmix to lessen a mono-output-only restriction).
			Finally (to support those cases where the standard setup of a soundcard is deficient/lacking, or custom plugin setup is desired), alsa.conf loads a system-global custom settings file /etc/asound.conf and a per-user custom settings file ~/.asoundrc.

			So, the objective should be to achieve having the common alsa-lib configuration file framework enhanced ''by default'' in the best possible manner for each specific soundcard brand, to avoid the need of creating manually customized config files in all standard cases.

			With this global overview done and cared for, let's have a look at the actual configuration format of alsa-lib files.


			==The .asoundrc file format==

			This file allows you to have more advanced control over your card/device. The <code>.asoundrc</code> file consists of definitions of the various cards available in your system. It also gives you access to the pcm plugins in alsa-lib. These allow you to do tricky things like combine your cards into one or access multiple I/Os on your multichannel card.

	==Where does asoundrc live?==		==Where does asoundrc live?==

AndreasMohr: Start fixing ALSA system config layer description for real

2013-11-07T20:52:53Z

Start fixing ALSA system config layer description for real

← Older revision		Revision as of 20:52, 7 November 2013
Line 6:		Line 6:
	What is it good for, why do I want one?		What is it good for, why do I want one?

	Neither the <code>.asoundrc</code> nor the <code>asound.conf</code> files are required for ALSA to work properly. Most applications will work without them. ~~They~~ are used to allow extra functionality, such as routing and sample-rate conversion, through the alsa-lib layer.		Neither the user-side <code>.asoundrc</code> nor the <code>asound.conf</code> configuration files are required for ALSA to work properly. Most applications will work without them. These files are used to allow extra functionality, such as routing and sample-rate conversion, through the alsa-lib layer.
			The reason that most applications will work without these user-side custom config files is that usually a default install of alsa-lib provides a sufficiently capable setup consisting of hierarchical config files (which make use of the standard .asoundrc format syntax as well), specifically capable of supporting certain soundcard brands.

	==The .asoundrc file==		==The .asoundrc file==

Oneirn: /* Referenced applications */ it has been over 5 years

2012-07-06T03:47:47Z

Referenced applications: it has been over 5 years

← Older revision		Revision as of 03:47, 6 July 2012
Line 539:		Line 539:
	==Referenced applications==		==Referenced applications==

	* '''aRTsd''' - the aRTs sound server is the basis of desktop sound for KDE.		* '''aRTsd''' - the aRTs sound server was the basis of desktop sound for KDE 3.
	* '''ESD''' - the Enlightened Sound Daemon mixes several audio streams for playback by a single audio device.		* '''ESD''' - the Enlightened Sound Daemon mixes several audio streams for playback by a single audio device.
	* '''Ecasound''' - a commandline multitrack recorder and editor with various GUI apps.		* '''Ecasound''' - a commandline multitrack recorder and editor with various GUI apps.

Lorenzopolidori: /* The .asoundrc file */

2012-05-01T09:01:13Z

The .asoundrc file

← Older revision		Revision as of 09:01, 1 May 2012
Line 10:		Line 10:
	==The .asoundrc file==		==The .asoundrc file==

	This file allows ~~the~~ you to have more advanced control over your card/device. The <code>.asoundrc</code> file consists of definitions of the various cards available in your system. It also gives you access to the pcm plugins in alsa-lib. These allow you to do tricky things like combine your cards into one or access multiple I/Os on your mulitchannel card.		This file allows you to have more advanced control over your card/device. The <code>.asoundrc</code> file consists of definitions of the various cards available in your system. It also gives you access to the pcm plugins in alsa-lib. These allow you to do tricky things like combine your cards into one or access multiple I/Os on your mulitchannel card.

	==Where does asoundrc live?==		==Where does asoundrc live?==

JeanGoulet: /* Bindings explained */

2011-07-28T15:16:36Z

Bindings explained

← Older revision		Revision as of 15:16, 28 July 2011
Line 389:		Line 389:

	The above example for a virtual multi channel device uses bindings to make the connections work. The following is a more advanced asoundrc for 2 RME Hammerfalls which is a professional multichannel sound device. Below is a full explanation of how bindings work.		The above example for a virtual multi channel device uses bindings to make the connections work. The following is a more advanced asoundrc for 2 RME Hammerfalls which is a professional multichannel sound device. Below is a full explanation of how bindings work.


	# This is for two RME Hammerfall cards. They have been conceptually split into rows		# This is for two RME Hammerfall cards. They have been conceptually split into rows
Line 436:		Line 435:
	slaves.b.channels 26;		slaves.b.channels 26;

	# Use rme9652_0 ch 0-7 mapped to ALSA ch 0-7		# Use rme9652_0 ch 0-7 mapped to ALSA ch 0-7

	bindings.0.slave a;		bindings.0.slave a;
	bindings.0.channel 0;		bindings.0.channel 0;
	bindings.1.slave a;		bindings.1.slave a;
Line 455:		Line 454:
	bindings.7.channel 7;		bindings.7.channel 7;

	# Use rme9652_0 ch 16-23 mapped to ALSA ch 8-15		# Use rme9652_0 ch 16-23 mapped to ALSA ch 8-15

	bindings.8.slave a;		bindings.8.slave a;
Line 474:		Line 473:
	bindings.15.channel 23;		bindings.15.channel 23;

	# Use rme9652_1 ch 8-15 mapped to ALSA ch 16-23		# Use rme9652_1 ch 8-15 mapped to ALSA ch 16-23

	bindings.16.slave b;		bindings.16.slave b;

JeanGoulet: /* Bindings explained */

2011-07-28T15:12:42Z

Bindings explained

← Older revision		Revision as of 15:12, 28 July 2011
Line 389:		Line 389:

	The above example for a virtual multi channel device uses bindings to make the connections work. The following is a more advanced asoundrc for 2 RME Hammerfalls which is a professional multichannel sound device. Below is a full explanation of how bindings work.		The above example for a virtual multi channel device uses bindings to make the connections work. The following is a more advanced asoundrc for 2 RME Hammerfalls which is a professional multichannel sound device. Below is a full explanation of how bindings work.


	# This is for two RME Hammerfall cards. They have been conceptually split into rows		# This is for two RME Hammerfall cards. They have been conceptually split into rows
Line 434:		Line 435:
	slaves.b.pcm rme9652_1;		slaves.b.pcm rme9652_1;
	slaves.b.channels 26;		slaves.b.channels 26;

	# Use rme9652_0 ch 0-7 mapped to ALSA ch 0-7		# Use rme9652_0 ch 0-7 mapped to ALSA ch 0-7

	bindings.0.slave a;		bindings.0.slave a;
	bindings.0.channel 0;		bindings.0.channel 0;
Line 453:		Line 454:
	bindings.7.slave a;		bindings.7.slave a;
	bindings.7.channel 7;		bindings.7.channel 7;

	# Use rme9652_0 ch 16-23 mapped to ALSA ch 8-15		# Use rme9652_0 ch 16-23 mapped to ALSA ch 8-15

	bindings.8.slave a;		bindings.8.slave a;
	bindings.8.channel 16;		bindings.8.channel 16;

JeanGoulet: /* Bindings explained */

2011-07-28T15:07:41Z

Bindings explained

← Older revision		Revision as of 15:07, 28 July 2011
Line 435:		Line 435:
	slaves.b.channels 26;		slaves.b.channels 26;

	# Use rme9652_0 ch 0-7 mapped to ALSA ch 0-7		# Use rme9652_0 ch 0-7 mapped to ALSA ch 0-7

	bindings.0.slave a;		bindings.0.slave a;
	bindings.0.channel 0;		bindings.0.channel 0;
	bindings.1.slave a;		bindings.1.slave a;
Line 454:		Line 454:
	bindings.7.channel 7;		bindings.7.channel 7;

	# Use rme9652_0 ch 16-23 mapped to ALSA ch 8-15		# Use rme9652_0 ch 16-23 mapped to ALSA ch 8-15

	bindings.8.slave a;		bindings.8.slave a;
Line 473:		Line 473:
	bindings.15.channel 23;		bindings.15.channel 23;

	# Use rme9652_1 ch 8-15 mapped to ALSA ch 16-23		# Use rme9652_1 ch 8-15 mapped to ALSA ch 16-23

	bindings.16.slave b;		bindings.16.slave b;

JeanGoulet: /* Bindings explained */

2011-07-28T15:03:39Z

Bindings explained

← Older revision		Revision as of 15:03, 28 July 2011
Line 402:		Line 402:
	# \| 16 17 18 19 20 21 22 23 \|		# \| 16 17 18 19 20 21 22 23 \|
	# \| 26 27\|		# \| 26 27\|

JeanGoulet: /* Bindings explained */

2011-07-28T14:56:59Z

Bindings explained

← Older revision		Revision as of 14:56, 28 July 2011
Line 390:		Line 390:
	The above example for a virtual multi channel device uses bindings to make the connections work. The following is a more advanced asoundrc for 2 RME Hammerfalls which is a professional multichannel sound device. Below is a full explanation of how bindings work.		The above example for a virtual multi channel device uses bindings to make the connections work. The following is a more advanced asoundrc for 2 RME Hammerfalls which is a professional multichannel sound device. Below is a full explanation of how bindings work.

	# This is for two RME Hammerfall cards. They have been split into ~~top row~~		# This is for two RME Hammerfall cards. They have been conceptually split into rows
	# and ~~bottom row~~ with channels 0-7+16-25 on rme9652_0 and channels 8-15~~+26-27~~ on		# and will be mapped to ALSA channels 0-27: with channels 0-7 and 16-23 on rme9652_0 and channels 8-15 on
	# rme9652_1~~. NB.~~ channels 24-~~27 are~~ used as two stereo channels while the others are mono.		# rme9652_1, and finally channels 24-25 of both cards, used as two stereo channels, mapped to ALSA channels 24-27 (while the others are mono).

	# eg. card1		# eg. ALSA channels on card1 = rme9652_0
	# \| 0 1 2 3 4 5 6 7 \|		# \| 0 1 2 3 4 5 6 7 \|
	# \| 8 9 10 11 12 13 14 15 24 25\|		# \| 8 9 10 11 12 13 14 15 \|
	# card2		# \| 24 25\|
	# \| 16 17 18 19 20 21 22 23 ~~24 25~~\|		#
			# ALSA channels on card2 = rme9652_1
			# \| 16 17 18 19 20 21 22 23 \|
			# \| 26 27\|


Line 432:		Line 435:
	slaves.b.pcm rme9652_1;		slaves.b.pcm rme9652_1;
	slaves.b.channels 26;		slaves.b.channels 26;

			# Use rme9652_0 ch 0-7 mapped to ALSA ch 0-7

	bindings.0.slave a;		bindings.0.slave a;
	bindings.0.channel 0;		bindings.0.channel 0;
Line 448:		Line 454:
	bindings.7.slave a;		bindings.7.slave a;
	bindings.7.channel 7;		bindings.7.channel 7;

			# Use rme9652_0 ch 16-23 mapped to ALSA ch 8-15

	bindings.8.slave a;		bindings.8.slave a;
	bindings.8.channel 16;		bindings.8.channel 16;
Line 465:		Line 474:
	bindings.15.channel 23;		bindings.15.channel 23;

	# Use rme9652_1		# Use rme9652_1 ch 8-15 mapped to ALSA ch 16-23

	bindings.16.slave b;		bindings.16.slave b;
Line 484:		Line 493:
	bindings.23.channel 15;		bindings.23.channel 15;

	# stereo channels		# stereo channels: slave a+b ch 24-25 mapped to ALSA ch 24-27

	bindings.24.slave a;		bindings.24.slave a;
Line 500:		Line 509:
	There are two sound cards which are linked with a wordclock pipe. That allows them to keep sample sync with each other which is very important for multichannel work. If the sample rates are not in sync then your sounds become out of time with each other.		There are two sound cards which are linked with a wordclock pipe. That allows them to keep sample sync with each other which is very important for multichannel work. If the sample rates are not in sync then your sounds become out of time with each other.

	~~Each~~ sound card has a number of physical channels 19 + 10. They are represented in <code>/proc/asound/card</code>x as <code>pcm</code>X<code>c</code> (capture) and <code>pcm</code>X<code>p</code> (playback). Where X equals the number of the physical input/output (i/o) channels starting at 0.		In this example each sound card has a number of physical channels being used: 18 (a) + 10 (b). They are represented in <code>/proc/asound/card</code>x as <code>pcm</code>X<code>c</code> (capture) and <code>pcm</code>X<code>p</code> (playback). Where X equals the number of the physical input/output (i/o) channels starting at 0.

	If you look at the lines:		If you look at the lines: