Re: PCM API questions

[Takashi Iwai <tiwai@suse.de>]

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/