At Fri, 31 May 2002 14:05:20 +0100, Martijn Sipkema wrote: > > > > - should i use the normal double buffered aproach or does having > > > more than 2 buffers have advantages? > > > > most of pci drivers use a linear contigous buffer for pcm (per > > stream). > > the scatter-gather buffer is not supported yet on alsa (as a mid/high > > level layer -- it would be possible if you write all on the low-level > > layer). > > the buffer is accessed directly via mmap as long as it's supported. > > > > > > > - what is normally called the latency of an audio interface for output? > > > is this the total size of the buffers or (in the case of double > buffered > > > io) > > > only one buffer? i'm thinking it is the total buffer size and this > would > > > make using more than 2 buffers have a better latency/interrupt response > > > time ratio, right? > > > > but if you have double buffer, isn't it difficult to handle mmap? > > also i don't think double-buffer (that i'm not sure whether you mean > > here "period" in the sense of alsa, or really double-buffering as in > > graphics) leads to better latency. of course my guess may be wrong. > > i did not mean two buffers actually, perhaps the alsa term is period? with > double buffering i meant having the saa7146 interrupt at half buffer. then it's called "two periods per buffer" in alsa.
> the saa7146 uses a single contiguous buffer, optionally using an mmu (so > then the buffer is not actually contiguous in physical memory). ok, it's similar to trident or emu10k1, which uses also its own TLB. for pcm, both of them use contigous memory buffer, though. > thus, having more than two periods is advantageous? let the choice left to application. more periods would be more stable even for interrupts delay, but of course would have longer latency. > > > - should setting the buffer size and number be done on modules loading > > > or should it be possible to change it after that? the saa7146 doesn't > need > > > contiguous memory since it has a mmu. > > > > the buffer size and numbers are specified by each application. > > at set-up stage, an application and driver commnucate with each other > > to find the preferable condition. the driver answers the hardware > > restriction to the application which inquires the condition. > > then the hardware is "prepared" actually, by calling prepare > > callback. > > > > in most cases, the hardawre restriction (condition) can be described > > in snd_pcm_hardware_t struct, which is passed to the runtime instance > > at open callback. the struct contains most of important conditions, > > such as supported formats, rates, channels, max buffers, etc. > > also, you can define more complicated conditions, if necessary. > > > > so if the application can set the buffer at set-up stage, it is best to > allocate > buffer memory at that time? yes. however, usually a chunk of memory is pre-allocated at the boot time (i.e. when the module is loaded), to avoid possible memory fragmentation. you can find snd_pci_preallocate_buffer() is called where the pcm is created via snd_pcm_new(). > > > - does alsa allow varipitch? i think the new rme cards are supposed to > > > have this feature and the audiowerk8 has it, i.e. it can change its > > > sampling > > > rate from about 37700 to 58200 hz while running in 1hz increments. > > > this allows for sync to video/tape/midi or whatever. or it allows for > the > > > sample rate to be adjusted when receiving audio using rtp. > > > > basically no (at least not tested). but i think it's not too > > difficult to support it. we can assign a control per pcm. > > you'll need to change runtime->rate dynamically according to the > > current rate, so that the tick interrupt handler calculates the time > > properly. > > again, i am not (yet) familiar with alsa, so i am not sure what > runtime->rate is > or what you mean with the tick interrupt handler (where can i find > documentation > on this?), but i think 'pitch' is meant as a deviation from the nominal > sample rate > and setting a large deviation can be thought of as a bad dac/adc? there is a runtime instance for a pcm stream, and this holds the informaton such as the current rate, channels, formats, etc. there is no pitch parameter implemented in alsa, but this can be added easily into the runtime instance, if inevitablly necessary. alsa pcm engine invokes a timer interrupt to update the "tick", and this tick is determined using the rate of the runtime instance. if you change the rate value dynamically during playback, then the tick interrupt will be wrongly scheduled, and leads to wrong detection of under/overrun. > > > - the audiowerk8 uses three dma channels: one for input and two for > output. > > > should i just wake a process that is blocking on a read() from the > input > > > dma > > > interrupt or should i wait until all three dma channels are ready and > then > > > unblock all read()/write() processes? should unblocking the processes > be > > > done > > > from bottom half? > > > > it's a job of alsa's high-level layer. > > the lowlevel routines don't have to handle sleep()/wakeup(). > > just call snd_pcm_period_elapsed() in the interrupts routine when the > > certain amount of samples have been processed. > > is there any documentation on this? not (yet)... i once posted a very brief summary to alsa devel ML. please check out the archive. Takashi _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
