At Mon, 4 Sep 2006 19:43:10 +0300,
Sergei Steshenko wrote:
>
> On Mon, 04 Sep 2006 16:31:10 +0200
> Takashi Iwai <[EMAIL PROTECTED]> wrote:
>
> > At Mon, 04 Sep 2006 07:15:54 -0400,
> > Gene Heskett wrote:
> > >
> > > On Monday 04 September 2006 06:46, Takashi Iwai wrote:
> > > >At Mon, 4 Sep 2006 13:32:27 +0300,
> > > >
> > > >Sergei Steshenko wrote:
> > > >> On Mon, 4 Sep 2006 18:25:10 +0800
> > > >>
> > > >> "littertiger" <[EMAIL PROTECTED]> wrote:
> > > >> > hi, group
> > > >> > How to develop and configure plugins? I find the document is too
> > > >> > brief. anyone cound suggest some materials,or book?
> > > >> >
> > > >> > Best Regards
> > > >> > littertiger
> > > >> > [EMAIL PROTECTED]
> > > >> > 2006-09-04
> > > >>
> > > >> As I understand the situation, ALSA developers are fiercely opposed to
> > > >> writing end user documentation unless they are payed for this :-) .
> > > >
> > > >Well, more correctly, unless they give us time and guts for this.
> > > >(and irony won't give neither of them :-)
> > > >
> > > I'm not sure if that was irony, Takashi. Besides, the word is "paid".
> >
> > That what I mentioned. Also, another correction: developers are not
> > "opposing" but less interested (in comparison with the demand from
> > end-users :-)
> >
> > > But, it seems to me that at some point the developers are going to be so
> > > buried in this that the only way to save your sanity is to write some
> > > docs
> > > that at least specify how its done for the rapidly proliferating chip
> > > selections that the chip people have succeeded in actually making a
> > > racket
> > > with that passes for sound in most circles. Without this, each developer
> > > will keep re-inventing the wheel. That doesn't appear to be the best way
> > > to spend your often valuable time.
> >
> > Well, in your argument it's not clear what level of documentation is
> > urgently needed. Actually, the difficulty in writing a document for
> > end-users is to know what they don't/need to know -- or a definition
> > of "end-users". We may need a tecnical reference for the developers,
> > while we may need a guidebook for novice users, or Gospels for
> > ex-window users. My mother cannot use a video recorder unless someone
> > tells her how to use it. But it's bundled with a good technical
> > reference for all information.
> >
> > Maybe we should start from FAQ, then someone can compile it as a
> > real tutorial (if needed)...
> >
> >
> > Takashi
> >
> > -------------------------------------------------------------------------
> > Using Tomcat but need to do more? Need to support web services, security?
> > Get stuff done quickly with pre-integrated technology to make your job
> > easier
> > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> > _______________________________________________
> > Alsa-user mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/alsa-user
> >
>
> At least, answer this question already in documentation:
>
> http://alsa.opensrc.org/.asoundrc ->
Note that this wiki is totally independent from the ALSA project, so
any questions there won't reach to ALSA developers directly.
Anyway...
>
> "
> What is a slave in the first place? What does it do, what does it mean, what
> for do I need it? Can please add some more light on this?'
> ".
First of all, you can define a PCM arbitarily and name its definition
as you like. It is done by defining a block like following in
~/.asoundrc (or /etc/asound.conf for system-side definitions), for
example:
pcm.mypcm {
..... my own definition .....
}
Then, you can pass this new PCM defintion "mypcm" to applications. In
the case of aplay, pass with -D option:
% aplay -D mypcm foo.wav
Voila, the file is played with your own definition! In other word,
this is somewhat like a user-defined device.
The second thing to know is that the ALSA PCM is stackable. A PCM
consists of "plugin" PCM objects. A plugin object may have an
underlying "slave" PCM (some plugins may have multiple slaves). For
example, suppose that you want to play PCM samples with a sample
rate, e.g. 32kHz, that isn't supported by your hardware (assume it
supports only 48kHz). In such a case, you can use "rate" PCM plugin.
This plugin shall have one slave PCM. For a playback, the slave PCM
means the output target. That is, the plugin reads from the input,
converts the sample rate, then outputs to the given slave PCM.
Hence, if you want to output the samples to the first sound card, the
setup would look like:
pcm.mypcm {
type rate
slave.pcm "hw:0"
slave.rate 48000
}
where the slave PCM is defined as a string "hw:0" that indicates the
"hardware" PCM device 0, and it sets slave rate to 48kHz. The "hw" is
a pre-defined PCM type for the direct access to the soundcard. The
number after colon is an argument to that PCM type, and in the case of
"hw" PCM, it means the card number (start from zero). "hw" can have
more optional arguments separated by comma, indicating the device
number, and the substream number. If they are omitted, defaults to
the first device and the first available substream -- in short, you
don't need to care about them normally.
Now you can play like
% aplay -D mypcm some-32khz-file.wav
As mentioned, a PCM is stackable -- i.e. you can add more layers.
Suppose that you want to support the automatic format conversion (from
any linear format) to the only format that your hardware supports
(e.g. S16_LE) in addition to the above rate conversion. Then you can
use "linear" plugin over the definition above:
pcm.mypcm2 {
type linear
slave.pcm "mypcm"
slave.format S16_LE
}
Then, you can play an A-Law sample file like:
% aplay -D mypcm2 some-alaw-format.wav
The definition of mypcm can be combined with mypcm2. mypcm2 can be
expressed with a single definition, such as:
pcm.mypcm2 {
type linear
slave {
type rate
slave.pcm "hw:0"
slave.rate 48000
format S16_LE
}
}
In the alsa-lib config syntax, a form "A.B C" is as same as
A {
B C
}
thus you can write the above equivalently like:
pcm.mypcm2 {
type linear
slave {
pcm {
type rate
slave {
pcm "hw:0"
rate 48000
}
}
format S16_LE
}
}
Be aware that the position of slave PCM is different between playback
and capture. In the case of capture (recording), the slave PCM is
regarded as "input" for the plugin, not the output like playback.
For example, if you use "mypcm" for the capture, it will read from
"hw:0", then down-sample from 48kHz to 32kHz.
> Second, as I already said, write down and publish states of card controls as
> you are testing the cards while debugging the drivers, so we, end users, will
> know how to set controls in order to enable certain card features.
You're asking to a wrong person. It's no "documentation" but a
support database. We don't have so many devices at all for debugging
or testing.
Takashi
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Alsa-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/alsa-user
