PCM API questions

PCM API questions

[Joshua Haberman]

Hello all!

I am writing a PortAudio implementation for ALSA.  PortAudio is designed
to present a single API that cross-platform applications can use on many
different platforms.

I have some questions I hope you can answer for me.

1.  Is there any reason to choose anything other than mmap mode for
transfer?  Are there some cards that don't support it?

2.  How is device selection designed to work with ALSA?  My experience
with ALSA has been very confusing in this regard.  I recall reading at
least once that ALSA is not designed to have applications enumerate all
the devices; that the correct way is to use ~/.asoundrc to define a
hardware device and then supply that name to applications.  But is there
anything more sophisticated an application can do than to just present
the user with a text box?

3.  I'm not sure how to approach the latency-related software and
hardware parameters.  PortAudio will soon be able to run in either
callback mode or blocking mode, and it is intended that the user be able
to provide hints to the implementation about what kind of latency it
wants.

The mechanism for setting latency in PortAudio is in a state of flux, but
at the moment the PortAudio implementation is provided with these
parameters:

    framesPerCallback -- max number of frames to pass to the user callback,
        when running in callback mode
    numberOfBuffers
    latencyInFrames

These are only guidelines to the driver, not commands, but I'd still like
to do the best possible approximation.  I'm thinking of doing something
like this:

    snd_pcm_hw_params_set_period_time( MIN(latencyInFrames, framesPerCallback) )
    snd_pcm_hw_params_set_periods( numberOfBuffers )
    /* buffer size is implicit from the above two */

    snd_pcm_sw_params_set_avail_min( MIN(latencyInFrames, framesPerCallback) )

As you can probably tell, I'm murky on the interaction between the
avail_min software parameter and the period_time hardware parameter.
Clarifications welcome.  :-)

I think that's it for now.

Josh


-------------------------------------------------------
Sponsored by:
ThinkGeek at http://www.ThinkGeek.com/

Re: PCM API questions

[Takashi Iwai]

Hi Josh,

At Sat, 22 Jun 2002 20:41:20 -0700,
Joshua Haberman wrote:
> 
> Hello all!
> 
> I am writing a PortAudio implementation for ALSA.  PortAudio is designed
> to present a single API that cross-platform applications can use on many
> different platforms.
> 
> I have some questions I hope you can answer for me.
> 
> 1.  Is there any reason to choose anything other than mmap mode for
> transfer?  Are there some cards that don't support it?
 
yes.  some devices don't support.
however you can specify the mmap-emulation mode on asoundrc, hence
mmap mode will be able to work on every device.


> 2.  How is device selection designed to work with ALSA?  My experience
> with ALSA has been very confusing in this regard.  I recall reading at
> least once that ALSA is not designed to have applications enumerate all
> the devices; that the correct way is to use ~/.asoundrc to define a
> hardware device and then supply that name to applications.  But is there
> anything more sophisticated an application can do than to just present
> the user with a text box?

the pcm name really depends on the driver implementation.
usually, device #0 is provided for general use.  but, for example, the
implementation of 4-channel sound is driver speicific.
some driver implements using a control switch and other combines
multiple pcm streams, etc.

however, there are standard names, too:
default, front, rear, center_lfe, surround40, surround51, spdif and
iec958 (identical with spdif).
it would be nice if users can choose one of them from a list, and
additionally have an input text field (well, not sophisticated,
though).


> 3.  I'm not sure how to approach the latency-related software and
> hardware parameters.  PortAudio will soon be able to run in either
> callback mode or blocking mode, and it is intended that the user be able
> to provide hints to the implementation about what kind of latency it
> wants.
> 
> The mechanism for setting latency in PortAudio is in a state of flux, but
> at the moment the PortAudio implementation is provided with these
> parameters:
> 
>     framesPerCallback -- max number of frames to pass to the user callback,
>         when running in callback mode
>     numberOfBuffers
>     latencyInFrames
> 
> These are only guidelines to the driver, not commands, but I'd still like
> to do the best possible approximation.  I'm thinking of doing something
> like this:
> 
>     snd_pcm_hw_params_set_period_time( MIN(latencyInFrames, framesPerCallback) )
>     snd_pcm_hw_params_set_periods( numberOfBuffers )
>     /* buffer size is implicit from the above two */

this should work, although snd_pcm_hw_params_set_period_time_near()
would be better to ensure the driver works.  the available
period/buffer size is dependent on the chip.  *_near() function probes
the nearest possibility.  you then need to reconfirm the approved
period/buffer sizes.  the similar thing will be necessary for sample
rates.
also, don't forget to set channels and format :)

just a question - is it necessary to provide both latencyInFrames and
framesPerCallback?

>     snd_pcm_sw_params_set_avail_min( MIN(latencyInFrames, framesPerCallback) )
> 
> As you can probably tell, I'm murky on the interaction between the
> avail_min software parameter and the period_time hardware parameter.
> Clarifications welcome.  :-)

the value you set is the default.  so you don't have to set it
explicitly.


ciao,

Takashi


-------------------------------------------------------
Sponsored by:
ThinkGeek at http://www.ThinkGeek.com/

Re: PCM API questions

[Paul Davis]

>> 2.  How is device selection designed to work with ALSA?  My experience
>> with ALSA has been very confusing in this regard.  I recall reading at
>> least once that ALSA is not designed to have applications enumerate all
>> the devices; that the correct way is to use ~/.asoundrc to define a
>> hardware device and then supply that name to applications.  But is there
>> anything more sophisticated an application can do than to just present
>> the user with a text box?
>
>the pcm name really depends on the driver implementation.
>usually, device #0 is provided for general use.  but, for example, the
>implementation of 4-channel sound is driver speicific.
>some driver implements using a control switch and other combines
>multiple pcm streams, etc.
>
>however, there are standard names, too:
>default, front, rear, center_lfe, surround40, surround51, spdif and
>iec958 (identical with spdif).
>it would be nice if users can choose one of them from a list, and
>additionally have an input text field (well, not sophisticated,
>though).

but there's no straightforward method of determining which names
actually exist. the code in aplay that handles the -L request, for
example, is baroque to the point of extremity. an application could
not just use those standard names, because the audio interface they
have may not support them.

in addition this also doesn't deal with the issue of users with more
than one soundcard installed.

--p


-------------------------------------------------------
Sponsored by:
ThinkGeek at http://www.ThinkGeek.com/

Re: PCM API questions

[Takashi Iwai]

At Mon, 24 Jun 2002 08:49:25 -0400,
Paul Davis wrote:
> 
> >> 2.  How is device selection designed to work with ALSA?  My experience
> >> with ALSA has been very confusing in this regard.  I recall reading at
> >> least once that ALSA is not designed to have applications enumerate all
> >> the devices; that the correct way is to use ~/.asoundrc to define a
> >> hardware device and then supply that name to applications.  But is there
> >> anything more sophisticated an application can do than to just present
> >> the user with a text box?
> >
> >the pcm name really depends on the driver implementation.
> >usually, device #0 is provided for general use.  but, for example, the
> >implementation of 4-channel sound is driver speicific.
> >some driver implements using a control switch and other combines
> >multiple pcm streams, etc.
> >
> >however, there are standard names, too:
> >default, front, rear, center_lfe, surround40, surround51, spdif and
> >iec958 (identical with spdif).
> >it would be nice if users can choose one of them from a list, and
> >additionally have an input text field (well, not sophisticated,
> >though).
> 
> but there's no straightforward method of determining which names
> actually exist. the code in aplay that handles the -L request, for
> example, is baroque to the point of extremity. an application could
> not just use those standard names, because the audio interface they
> have may not support them.
 
yep.  that's actually a problem, too.
the names above are not defined on all cards (except for default).
i think we need a kind of config database for each card.
this is useful not only for pcm but also for parsing the mixer
structure.


> in addition this also doesn't deal with the issue of users with more
> than one soundcard installed.

this is not difficult, since the card number can be passed via
CARD argument.


Takashi


-------------------------------------------------------
Sponsored by:
ThinkGeek at http://www.ThinkGeek.com/

Re: PCM API questions

[Paul Davis]

>the names above are not defined on all cards (except for default).
>i think we need a kind of config database for each card.
>this is useful not only for pcm but also for parsing the mixer
>structure.

i think this is the wrong solution. i believe the correct solution is
to provide a **simple** way to get every defined PCM device name.

a config database for cards doesn't cover multi devices, or channel
subsets, or share devices, etc. etc.

>> in addition this also doesn't deal with the issue of users with more
>> than one soundcard installed.
>
>this is not difficult, since the card number can be passed via
>CARD argument.

thats not my point. an application that wants to provide a way to
select the audio input and output needs to be able to know which all
the PCM devices that are defined. the whole beauty of the naming
system is that its based around physical cards, but that also means
that card numbers are not the right way to start thinking about this.

--p



-------------------------------------------------------
Sponsored by:
ThinkGeek at http://www.ThinkGeek.com/

Re: PCM API questions

[Fred Gleason]

On Monday 24 June 2002 10:17, Paul Davis wrote:
> >the names above are not defined on all cards (except for default).
> >i think we need a kind of config database for each card.
> >this is useful not only for pcm but also for parsing the mixer
> >structure.
>
> i think this is the wrong solution. i believe the correct solution is
> to provide a **simple** way to get every defined PCM device name.

Amen!  I understand the need for flexibility in configuring devices, but this 
is a routine requirement that IMHO is currently vastly more complex to 
implement than it needs to be.

Cheers!


|-------------------------------------------------------------------------|
|      Frederick F. Gleason, Jr.      |         Salem Radio Labs          |
|       Voice: 1-(540)-341-2880       |      87 Lee Highway, Suite 11     |
|        FAX: 1-(540)-341-7176        |        Warrenton, VA 20188        |
|-------------------------------------------------------------------------|
|    The real problem with hunting elephants is carrying the decoys.      |
|                                             -- Anonymous                |
|-------------------------------------------------------------------------|



-------------------------------------------------------
Sponsored by:
ThinkGeek at http://www.ThinkGeek.com/

Re: PCM API questions

[Takashi Iwai]

At Mon, 24 Jun 2002 10:17:08 -0400,
Paul Davis wrote:
> 
> >the names above are not defined on all cards (except for default).
> >i think we need a kind of config database for each card.
> >this is useful not only for pcm but also for parsing the mixer
> >structure.
> 
> i think this is the wrong solution. i believe the correct solution is
> to provide a **simple** way to get every defined PCM device name.
> 
> a config database for cards doesn't cover multi devices, or channel
> subsets, or share devices, etc. etc.
 
that's right.  (but i think it's not a bad idea to put something more
descriptive for each pcm device which is card-specific.)

regarding to the device listing:
afaik, you can look up all pcm devices by calling
	snd_config_search(config, "PCM", &conf)
and then run snd_config_for_each()...  ah, not SIMPLE as you wrote.

so, making a list of pcm names would be relatively easy.  we can add a
new function to alsa-lib.

but arising problem is that this will list up all possible
definitions.  that is, it will include the standard pcm names with
arguments such as hw or plughw.  it's not bad (you can use them even
without arguments) but maybe confusing.

anyway it would be nice to add a "description" entry for each
definition in the config, so that it will appear on the list more
intuitively.


Takashi


-------------------------------------------------------
Sponsored by:
ThinkGeek at http://www.ThinkGeek.com/

Re: PCM API questions

[Joshua Haberman]

* Paul Davis (pbd@op.net) wrote:
> >the names above are not defined on all cards (except for default).
> >i think we need a kind of config database for each card.
> >this is useful not only for pcm but also for parsing the mixer
> >structure.
> 
> i think this is the wrong solution. i believe the correct solution is
> to provide a **simple** way to get every defined PCM device name.

I agree.  I also think its important that users can do basic things
(stereo in and out) with any physical card in their system without having
to touch ~/.asoundrc.

The complexity of ~/.asoundrc configuration is apparently necessary to
accommodate the high-end: people using one or more professional
multichannel cards.  That's fine, but now that ALSA is in 2.5 there are
going to be a hoarde of basic users who want to run XMMS and watch DVDs.
They will want it to just work, and if it doesn't work they'll come and
flood your mailing lists and proclaim that ALSA sucks because it can't
even do basic things.

Maybe this is what the "default" device is intended for, but can it
accommodate more than one card?  I happen to have a sound card built into
my motherboard and another in a PCI slot -- how do I tell XMMS which one
to use?

Don't take my comments the wrong way: I'm glad to know that ALSA was done
the right way and can scale up to multiple multichannel cards.  I just
hope that it can also be a good fit for basic, stereo-only users.

In this same line of thought, I still have no idea what half the channels
alsamixer shows me correspond to, nor why my digital CD input is labelled
"IEC958 TTL" (I discovered this via guess and check).

Josh


-------------------------------------------------------
Sponsored by:
ThinkGeek at http://www.ThinkGeek.com/

Re: PCM API questions

[Paul Davis]

>Maybe this is what the "default" device is intended for, but can it
>accommodate more than one card?  I happen to have a sound card built into
>my motherboard and another in a PCI slot -- how do I tell XMMS which one
>to use?

an excellent context for the question. 

i want to extend the question just a little. it seems from watching a
few friends who use windows audio apps that its conventional there to
name audio output options after the physical hardware. so you see
things like "Terratec XWP" and "Ensoniq PCM" and so forth. This is
nice because its what a lot of users think in terms of.

in ALSA, we really don't see such naming at all. thats fine with me,
but it leads me to wonder. the reason that the names are useful is
that they don't move around when you change the install order for the
modules (for example). so, the "Ensoniq PCM" is always the "Ensoniq
PCM" whether its the first card or the second.

Now, AFAICT, Windows doesn't make it very easy to deal with multiple
"Ensoniq PCM" devices whereas ALSA does. However, there does seem to
be something "missing" when we present users with

   plughw:1,0

as the name of suitably flexible device for general purpose audio on
the second card in the absence of a ~/.asoundrc file ....

So I'm left wondering what naming scheme to use to get a more flexible
way of referring to cards *without* using an ~/.asoundrc
file. Alternatively, how to autogenerate the file so that it provides
nice names?

--p


-------------------------------------------------------
Sponsored by:
ThinkGeek at http://www.ThinkGeek.com/

Re: PCM API questions

[Jaroslav Kysela]

On Mon, 24 Jun 2002, Paul Davis wrote:

> >Maybe this is what the "default" device is intended for, but can it
> >accommodate more than one card?  I happen to have a sound card built into
> >my motherboard and another in a PCI slot -- how do I tell XMMS which one
> >to use?
> 
> an excellent context for the question. 
> 
> i want to extend the question just a little. it seems from watching a
> few friends who use windows audio apps that its conventional there to
> name audio output options after the physical hardware. so you see
> things like "Terratec XWP" and "Ensoniq PCM" and so forth. This is
> nice because its what a lot of users think in terms of.
> 
> in ALSA, we really don't see such naming at all. thats fine with me,
> but it leads me to wonder. the reason that the names are useful is
> that they don't move around when you change the install order for the
> modules (for example). so, the "Ensoniq PCM" is always the "Ensoniq
> PCM" whether its the first card or the second.
> 
> Now, AFAICT, Windows doesn't make it very easy to deal with multiple
> "Ensoniq PCM" devices whereas ALSA does. However, there does seem to
> be something "missing" when we present users with
> 
>    plughw:1,0
> 
> as the name of suitably flexible device for general purpose audio on
> the second card in the absence of a ~/.asoundrc file ....
> 
> So I'm left wondering what naming scheme to use to get a more flexible
> way of referring to cards *without* using an ~/.asoundrc
> file. Alternatively, how to autogenerate the file so that it provides
> nice names?

I think that you've forgot that we can identify hardware devices over the 
control interface. Look for snd_ctl_pcm_next_device() and snd_ctl_pcm_info()
functions. It's easy to use this information with combination of PCM names 
like 'hw:CARD,DEVICE,SUBDEVICE' and 'plughw:*'.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project  http://www.alsa-project.org
SuSE Linux    http://www.suse.com



-------------------------------------------------------
Sponsored by:
ThinkGeek at http://www.ThinkGeek.com/

Re: PCM API questions

[Joshua Haberman]

* Jaroslav Kysela (perex@suse.cz) wrote:
> On Mon, 24 Jun 2002, Paul Davis wrote:
> 
> > >Maybe this is what the "default" device is intended for, but can it
> > >accommodate more than one card?  I happen to have a sound card built into
> > >my motherboard and another in a PCI slot -- how do I tell XMMS which one
> > >to use?
> > 
> > an excellent context for the question. 
> > 
> > i want to extend the question just a little. it seems from watching a
> > few friends who use windows audio apps that its conventional there to
> > name audio output options after the physical hardware. so you see
> > things like "Terratec XWP" and "Ensoniq PCM" and so forth. This is
> > nice because its what a lot of users think in terms of.
> > 
> > in ALSA, we really don't see such naming at all. thats fine with me,
> > but it leads me to wonder. the reason that the names are useful is
> > that they don't move around when you change the install order for the
> > modules (for example). so, the "Ensoniq PCM" is always the "Ensoniq
> > PCM" whether its the first card or the second.
> > 
> > Now, AFAICT, Windows doesn't make it very easy to deal with multiple
> > "Ensoniq PCM" devices whereas ALSA does. However, there does seem to
> > be something "missing" when we present users with
> > 
> >    plughw:1,0
> > 
> > as the name of suitably flexible device for general purpose audio on
> > the second card in the absence of a ~/.asoundrc file ....
> > 
> > So I'm left wondering what naming scheme to use to get a more flexible
> > way of referring to cards *without* using an ~/.asoundrc
> > file. Alternatively, how to autogenerate the file so that it provides
> > nice names?
> 
> I think that you've forgot that we can identify hardware devices over the 
> control interface. Look for snd_ctl_pcm_next_device() and snd_ctl_pcm_info()
> functions. It's easy to use this information with combination of PCM names 
> like 'hw:CARD,DEVICE,SUBDEVICE' and 'plughw:*'.

I didn't know about these functions.  Here is what I came up with:

joshua@birdie:~/code$ cat alsa_devices.c 

#include <alsa/asoundlib.h>

int main() {
    snd_ctl_t *ctl;
    snd_pcm_info_t *info;
    char *cardname;
    char alsaname[100];
    char *devicename;
    int device;
    int card_idx = -1;
    int device_idx;

    snd_pcm_info_malloc(&info);

    while( snd_card_next(&card_idx) == 0 && card_idx >= 0 ) {
        snd_card_get_name(card_idx, &cardname);
        printf("card %d: %s\n", card_idx, cardname);

        device_idx = -1;
        sprintf(alsaname, "hw:%d", card_idx);
        snd_ctl_open(&ctl, alsaname, 0);
        while( snd_ctl_pcm_next_device(ctl, &device_idx) == 0  && device_idx >= 0 ) {
            snd_ctl_pcm_info(ctl, info);
            devicename = snd_pcm_info_get_name(info);
            printf("\tdevice %d: %s\n", device_idx, devicename);
        }
    }
}
joshua@birdie:~/code$ ./alsa_devices 
card 0: Sound Blaster Live!
        device 0: EMU10K1
        device 1: EMU10K1
        device 2: EMU10K1
        device 3: EMU10K1
card 1: SiS SI7012
        device 0: SiS SI7012

This is useful (though the subdevice names provide no information).
Using a process similar to this, it would be easy to write a program like
this:

foreach card:
    tell the user "I discovered a card named $card"
    if the user has more than one card named this, emit a beep to disambiguate
    ask the user what to call this card
    add to ~/.asoundrc: "pcm.$users_name { type hw  card $num }"

But this leaves two problems:
    1. ~/.asoundrc becomes invalid if drivers are loaded in a different order
    2. How can applications get a list of the cards the user defined?

What would be even nicer is if the symbolic names above ("Sound Blaster
Live!" and "SiS SI7012" could be automatically aliased to the hw:$x:0
entries, so that an application could call:

    snd_pcm_open( "Sound Blaster Live!", SND_PCM_STREAM_PLAYBACK, 0 );

and get the right thing.

Josh


-------------------------------------------------------
Sponsored by:
ThinkGeek at http://www.ThinkGeek.com/

Re: PCM API questions

[Jaroslav Kysela]

On Mon, 24 Jun 2002, Joshua Haberman wrote:

> * Jaroslav Kysela (perex@suse.cz) wrote:
> > On Mon, 24 Jun 2002, Paul Davis wrote:
> > 
> > > >Maybe this is what the "default" device is intended for, but can it
> > > >accommodate more than one card?  I happen to have a sound card built into
> > > >my motherboard and another in a PCI slot -- how do I tell XMMS which one
> > > >to use?
> > > 
> > > an excellent context for the question. 
> > > 
> > > i want to extend the question just a little. it seems from watching a
> > > few friends who use windows audio apps that its conventional there to
> > > name audio output options after the physical hardware. so you see
> > > things like "Terratec XWP" and "Ensoniq PCM" and so forth. This is
> > > nice because its what a lot of users think in terms of.
> > > 
> > > in ALSA, we really don't see such naming at all. thats fine with me,
> > > but it leads me to wonder. the reason that the names are useful is
> > > that they don't move around when you change the install order for the
> > > modules (for example). so, the "Ensoniq PCM" is always the "Ensoniq
> > > PCM" whether its the first card or the second.
> > > 
> > > Now, AFAICT, Windows doesn't make it very easy to deal with multiple
> > > "Ensoniq PCM" devices whereas ALSA does. However, there does seem to
> > > be something "missing" when we present users with
> > > 
> > >    plughw:1,0
> > > 
> > > as the name of suitably flexible device for general purpose audio on
> > > the second card in the absence of a ~/.asoundrc file ....
> > > 
> > > So I'm left wondering what naming scheme to use to get a more flexible
> > > way of referring to cards *without* using an ~/.asoundrc
> > > file. Alternatively, how to autogenerate the file so that it provides
> > > nice names?
> > 
> > I think that you've forgot that we can identify hardware devices over the 
> > control interface. Look for snd_ctl_pcm_next_device() and snd_ctl_pcm_info()
> > functions. It's easy to use this information with combination of PCM names 
> > like 'hw:CARD,DEVICE,SUBDEVICE' and 'plughw:*'.
> 
> I didn't know about these functions.  Here is what I came up with:
> 
> joshua@birdie:~/code$ cat alsa_devices.c 
> 
> #include <alsa/asoundlib.h>
> 
> int main() {
>     snd_ctl_t *ctl;
>     snd_pcm_info_t *info;
>     char *cardname;
>     char alsaname[100];
>     char *devicename;
>     int device;
>     int card_idx = -1;
>     int device_idx;
> 
>     snd_pcm_info_malloc(&info);
> 
>     while( snd_card_next(&card_idx) == 0 && card_idx >= 0 ) {
>         snd_card_get_name(card_idx, &cardname);
>         printf("card %d: %s\n", card_idx, cardname);
> 
>         device_idx = -1;
>         sprintf(alsaname, "hw:%d", card_idx);
>         snd_ctl_open(&ctl, alsaname, 0);
>         while( snd_ctl_pcm_next_device(ctl, &device_idx) == 0  && device_idx >= 0 ) {

You're missing here initialization of device, subdevice and stream, so you 
get only name for the first PCM device. Look for snd_pcm_info_set_*() 
functions.

>             snd_ctl_pcm_info(ctl, info);
>             devicename = snd_pcm_info_get_name(info);
>             printf("\tdevice %d: %s\n", device_idx, devicename);
>         }
>     }
> }
> joshua@birdie:~/code$ ./alsa_devices 
> card 0: Sound Blaster Live!
>         device 0: EMU10K1
>         device 1: EMU10K1
>         device 2: EMU10K1
>         device 3: EMU10K1
> card 1: SiS SI7012
>         device 0: SiS SI7012
> 
> This is useful (though the subdevice names provide no information).
> Using a process similar to this, it would be easy to write a program like
> this:
> 
> foreach card:
>     tell the user "I discovered a card named $card"
>     if the user has more than one card named this, emit a beep to disambiguate
>     ask the user what to call this card
>     add to ~/.asoundrc: "pcm.$users_name { type hw  card $num }"
> 
> But this leaves two problems:
>     1. ~/.asoundrc becomes invalid if drivers are loaded in a different order

Well, you can also determine the id of card (it's a string - something 
like abstract alias, user can pass this alias via the driver modules). See 
snd_ctl_card_info_get_id() function.

>     2. How can applications get a list of the cards the user defined?
> 
> What would be even nicer is if the symbolic names above ("Sound Blaster
> Live!" and "SiS SI7012" could be automatically aliased to the hw:$x:0
> entries, so that an application could call:
> 
>     snd_pcm_open( "Sound Blaster Live!", SND_PCM_STREAM_PLAYBACK, 0 );

Use the card id (alias) for this case. Example:

snd_pcm_open( "plughw:CARD=\"SB_Live\"", SND_PCM_STREAM_PLAYBACK, 0 );

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project  http://www.alsa-project.org
SuSE Linux    http://www.suse.com



-------------------------------------------------------
Sponsored by:
ThinkGeek at http://www.ThinkGeek.com/

Re: PCM API questions

[Joshua Haberman]

* Takashi Iwai (tiwai@suse.de) wrote:
> > Hello all!
> > 
> > I am writing a PortAudio implementation for ALSA.  PortAudio is designed
> > to present a single API that cross-platform applications can use on many
> > different platforms.
> > 
> > I have some questions I hope you can answer for me.
> > 
> > 1.  Is there any reason to choose anything other than mmap mode for
> > transfer?  Are there some cards that don't support it?
>  
> yes.  some devices don't support.
> however you can specify the mmap-emulation mode on asoundrc, hence
> mmap mode will be able to work on every device.

Hmm, is there any way to request mmap emulation without touching
~/.asoundrc?  Ideally PortAudio will be able to use any device
transparently (without requiring special configuration).  Also ideally I
will only have to implement one transfer mode. :-)

> > 2.  How is device selection designed to work with ALSA?  My experience
> > with ALSA has been very confusing in this regard.  I recall reading at
> > least once that ALSA is not designed to have applications enumerate all
> > the devices; that the correct way is to use ~/.asoundrc to define a
> > hardware device and then supply that name to applications.  But is there
> > anything more sophisticated an application can do than to just present
> > the user with a text box?
> 
> the pcm name really depends on the driver implementation.
> usually, device #0 is provided for general use.  but, for example, the
> implementation of 4-channel sound is driver speicific.
> some driver implements using a control switch and other combines
> multiple pcm streams, etc.

Why such non-uniformity?  Isn't part of the goal of an audio API to
abstract the difference between specific sound cards so that different
cards with similar features can be treated identically?

> however, there are standard names, too:
> default, front, rear, center_lfe, surround40, surround51, spdif and
> iec958 (identical with spdif).

How are these configured?  Do they automatically use the first card?

> > 3.  I'm not sure how to approach the latency-related software and
> > hardware parameters.  PortAudio will soon be able to run in either
> > callback mode or blocking mode, and it is intended that the user be able
> > to provide hints to the implementation about what kind of latency it
> > wants.
> > 
> > The mechanism for setting latency in PortAudio is in a state of flux, but
> > at the moment the PortAudio implementation is provided with these
> > parameters:
> > 
> >     framesPerCallback -- max number of frames to pass to the user callback,
> >         when running in callback mode
> >     numberOfBuffers
> >     latencyInFrames
> > 
> > These are only guidelines to the driver, not commands, but I'd still like
> > to do the best possible approximation.  I'm thinking of doing something
> > like this:
> > 
> >     snd_pcm_hw_params_set_period_time( MIN(latencyInFrames, framesPerCallback) )
> >     snd_pcm_hw_params_set_periods( numberOfBuffers )
> >     /* buffer size is implicit from the above two */
> 
> this should work, although snd_pcm_hw_params_set_period_time_near()
> would be better to ensure the driver works.  the available
> period/buffer size is dependent on the chip.  *_near() function probes
> the nearest possibility.  you then need to reconfirm the approved
> period/buffer sizes.  the similar thing will be necessary for sample
> rates.

I see, thanks for the tip.

> just a question - is it necessary to provide both latencyInFrames and
> framesPerCallback?

As I understand it, framesPerCallback is just that, a number affecting
only how the callback is invoked.  If it is less than latencyInFrames,
the callback is called multiple times for each buffer sent to the
hardware.

Like I said, the latency-configuration mechanism is being redesigned at
the moment.  If you have an idea for a more precise and/or useful way to
specify latency, please let me know and I'll pass it on!

> >     snd_pcm_sw_params_set_avail_min( MIN(latencyInFrames, framesPerCallback) )
> > 
> > As you can probably tell, I'm murky on the interaction between the
> > avail_min software parameter and the period_time hardware parameter.
> > Clarifications welcome.  :-)
> 
> the value you set is the default.  so you don't have to set it
> explicitly.

What I am unsure about is this: how does ALSA behave if avail_min and
period_time are not equal?  As I understand it, the hardware is
configured to produce an interrupt every period_time frames.  How does
the software use this information (the incoming interrupts and the
avail_min parameter) to decide when to wake up the client?

Thanks for your answers!

Josh


-------------------------------------------------------
Sponsored by:
ThinkGeek at http://www.ThinkGeek.com/

Re: PCM API questions

[Takashi Iwai]

At Tue, 25 Jun 2002 00:11:20 -0700,
Joshua Haberman wrote:
> 
> * Takashi Iwai (tiwai@suse.de) wrote:
> > > Hello all!
> > > 
> > > I am writing a PortAudio implementation for ALSA.  PortAudio is designed
> > > to present a single API that cross-platform applications can use on many
> > > different platforms.
> > > 
> > > I have some questions I hope you can answer for me.
> > > 
> > > 1.  Is there any reason to choose anything other than mmap mode for
> > > transfer?  Are there some cards that don't support it?
> >  
> > yes.  some devices don't support.
> > however you can specify the mmap-emulation mode on asoundrc, hence
> > mmap mode will be able to work on every device.
> 
> Hmm, is there any way to request mmap emulation without touching
> ~/.asoundrc?  Ideally PortAudio will be able to use any device
> transparently (without requiring special configuration).  Also ideally I
> will only have to implement one transfer mode. :-)

there is a config file for each driver under /usr/share/alsa/cards,
to specify / redefine the special cases.
and, although i wrote there are some devices, they are very rare
cases.  so in most cases no problem at all to assume mmap mode :)


> > > 2.  How is device selection designed to work with ALSA?  My experience
> > > with ALSA has been very confusing in this regard.  I recall reading at
> > > least once that ALSA is not designed to have applications enumerate all
> > > the devices; that the correct way is to use ~/.asoundrc to define a
> > > hardware device and then supply that name to applications.  But is there
> > > anything more sophisticated an application can do than to just present
> > > the user with a text box?
> > 
> > the pcm name really depends on the driver implementation.
> > usually, device #0 is provided for general use.  but, for example, the
> > implementation of 4-channel sound is driver speicific.
> > some driver implements using a control switch and other combines
> > multiple pcm streams, etc.
> 
> Why such non-uniformity?  Isn't part of the goal of an audio API to
> abstract the difference between specific sound cards so that different
> cards with similar features can be treated identically?

please note that the difference of hardware is reflected on the
difference of driver implementation.  some chip supports
multi-channels with several streams, and others using a single stream.
the driver is implemented as best for controlling its hardware.

on ALSA, the abstraction is done on the config file mentioned above.
thus, so long as you use the general pcm name like surround40, you
don't see the difference of implementation.
however, if you access directly the (kind of) low-level pcm device,
then you see such difference.

 
> > however, there are standard names, too:
> > default, front, rear, center_lfe, surround40, surround51, spdif and
> > iec958 (identical with spdif).
> 
> How are these configured?  Do they automatically use the first card?
 
to specify the card number, they can take also arguments, such like
surround40:CARD=2.


> > > 3.  I'm not sure how to approach the latency-related software and
> > > hardware parameters.  PortAudio will soon be able to run in either
> > > callback mode or blocking mode, and it is intended that the user be able
> > > to provide hints to the implementation about what kind of latency it
> > > wants.
> > > 
> > > The mechanism for setting latency in PortAudio is in a state of flux, but
> > > at the moment the PortAudio implementation is provided with these
> > > parameters:
> > > 
> > >     framesPerCallback -- max number of frames to pass to the user callback,
> > >         when running in callback mode
> > >     numberOfBuffers
> > >     latencyInFrames
> > > 
> > > These are only guidelines to the driver, not commands, but I'd still like
> > > to do the best possible approximation.  I'm thinking of doing something
> > > like this:
> > > 
> > >     snd_pcm_hw_params_set_period_time( MIN(latencyInFrames, framesPerCallback) )
> > >     snd_pcm_hw_params_set_periods( numberOfBuffers )
> > >     /* buffer size is implicit from the above two */
> > 
> > this should work, although snd_pcm_hw_params_set_period_time_near()
> > would be better to ensure the driver works.  the available
> > period/buffer size is dependent on the chip.  *_near() function probes
> > the nearest possibility.  you then need to reconfirm the approved
> > period/buffer sizes.  the similar thing will be necessary for sample
> > rates.
> 
> I see, thanks for the tip.
> 
> > just a question - is it necessary to provide both latencyInFrames and
> > framesPerCallback?
> 
> As I understand it, framesPerCallback is just that, a number affecting
> only how the callback is invoked.  If it is less than latencyInFrames,
> the callback is called multiple times for each buffer sent to the
> hardware.
> 
> Like I said, the latency-configuration mechanism is being redesigned at
> the moment.  If you have an idea for a more precise and/or useful way to
> specify latency, please let me know and I'll pass it on!
 
can latencyInFrames include the hardware latency, such as hardware
fifo size?


> > >     snd_pcm_sw_params_set_avail_min( MIN(latencyInFrames, framesPerCallback) )
> > > 
> > > As you can probably tell, I'm murky on the interaction between the
> > > avail_min software parameter and the period_time hardware parameter.
> > > Clarifications welcome.  :-)
> > 
> > the value you set is the default.  so you don't have to set it
> > explicitly.
> 
> What I am unsure about is this: how does ALSA behave if avail_min and
> period_time are not equal?  As I understand it, the hardware is
> configured to produce an interrupt every period_time frames.  How does
> the software use this information (the incoming interrupts and the
> avail_min parameter) to decide when to wake up the client?

it's referred to check whether wake_up() is called in interrupts.
the driver (in alsa mid-level function) checks the available space,
and if it's greater than avail_min, wake the polling/sleeping thread
up.
thus, for example, if avail_min is period_time * 2, then the process
will be woken up at the second interrupt after sleeping (if the
interrupt is generated at each period boundary).

also, please note that interrupts are generated not always with the
period size.  some chips have only fixed timer interrupts (with enough
high rate).  on such chips, the current sample pointer is checked at
each interrupt call whether it goes across the period boundary.
that's why, for example, ymfpci has strange period size.
but anyway the meaning of period or avail_min is same from the
outside.


ciao,

Takashi


-------------------------------------------------------
Sponsored by:
ThinkGeek at http://www.ThinkGeek.com/