Subject: Re: [ecasound] .asoundrc /ecasound
From: Kai Vehmanen (k_AT_eca.cx)
Date: Tue Sep 17 2002 - 17:54:19 EEST
Hi,
On 17 Sep 2002, Nathan Stewart wrote:
> pcm_slave.2496
> {
> pcm ice1712
> format 24_le
> channels 12
> rate 96000
> }
[...]
> From ecasound, I specify ecasound -i:alsaplugin,2496
> It takes it, but then informs me that it's using s16_le, 2 channel,
> 44100 Hz. So, I bypassed the plugin interface and did it like this:
I'm not sure what the asoundrc-definition of parameters actually does. My
best guess it that it sets the default audio parameters. In any case,
ecasound always sets the audio parameters explicitly. If you don't add a
-f option, the default format -f:s16_le,2,44100,i will be used. You can
change the default by putting:
default-audio-format = s32_le,2,44100,i
... to your ~/.ecasound/ecasoundrc (or in ~/.ecasoundrc if using
2.0.x or older).
> ecasound -f:s32_le,12,96000,n -a:radio,mic -f:s32_le,12,96000
> -i:alsa,ice1712 -a:radio -erc:1,1 -a:radio -erc:2,1
You haven't defined an output, so ecasound will try to make the setup
valid by adding a default output. In other words "-o:/dev/dsp" is added to
the chainsetup definition before enabling it. You can againt override the
default output by adding:
default-output = alsa,default
or some such in the ecasoundrc. Although it's generally better add
explicit outputs when using complicated setups. The ecasoundrc
default-output is mainly aimed at simpler apps like ecaplay.
> (audio-io) Format: s32_le, channels 12, srate 96000, interleaved.
> (eca-control) ERROR: Connecting chainsetup failed: "Enabling
> chainsetup: AUDIOIO-OSS: audio format not supported (2)"
.. ie. it's tries to open /dev/dsp for output, but fails.
> 3) Why is asoundrc such a
> blasted personal thing that varies according to what YOU want to call
> your sound card instead of being the same for all cards of a certain
> chipset/model? Does is really give that much more usefulness to be able
> to call the SP/DIF input LeRoyMcGuinness if I want to? (OK, I'm ranting.
> Sorry.)
This is perfectly valid question. I'm not perhaps the best person to
answer it, but I'd say the main reason is that it is a very difficult task
to identify a good group of profiles (device configurations). You either
force a certain use-scenario to all users (as is done in Windows,
OSS/commercial, and many other widely used audio subsystems) or provide
the end-user full flexility of the underlying system. Unfortunatey with
flexibility comes complexity. As an example, you can combine a set of
soundcard devices (that are synced to a common clock) and present it as
one big soundcard. It's quite impossible to predefine these kinds of
configurations.
The general lack of end-user friendly documentation and features
originates from how the ALSA project works. It's actually developed in a
very much Linux/Linus-style way. The key ALSA project member are
interested in technology and do not let politics and social aspect
interfere (at least not much) with their work. This is generally a very
good thing and has proven to work. ALSA has produced excellent software
and has continued to do this for many years now. The big problem is that
the ALSA developers are relative alone with their efforts. Unlike the
kernel developers, ALSA people don't have masses of people (and big
companies distributing Linux solutions) that help to make the technology
more easily usable and approachable by the end-users.
The bright side is that ALSA is now part of linux-2.5/linux-2.6, so
this whole situations just might change in the future.
> # audio inputs
> -a:radio -f:s24_le,12,96000 -i:alsahw,0,0
> -a:mic -f:s24_le,12,96000 -i:alsahw,0,0
This is not valid. You cannot define input "alsahw,0,0" twice in one
chainsetup. Instead you should define it once and route its audio to
multiple chains. In other words:
-a:radio,mic -f:s24_le,12,96000 -i:alsahw,0,0
-- http://www.eca.cx Audio software for Linux!-- To unsubscribe send message 'unsubscribe' in the body of the message to <ecasound-list-request_AT_wakkanet.fi>.
This archive was generated by hypermail 2b28 : Tue Sep 17 2002 - 17:55:36 EEST