At Tue, 25 Jun 2002 00:11:20 -0700, Joshua Haberman wrote: > > * Takashi Iwai ([EMAIL PROTECTED]) 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/ _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
