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/ _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
