At Fri, 31 May 2002 11:38:41 +0100, Martijn Sipkema wrote: > > below is a message i sent earlier, but with the wrong email address: > > ---- > > writing audiowerk driver (philips saa7146a), some questions > > > hi, > > i have finally been able to get the information i need to be able > to write a driver for the emagic audiowerk8 audio interface. > now since i am not an experienced kernel programmer and have > not even done audio programming (apart from midi), i have > some questions. > > - 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. > - 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. > - where can i find documentation on writing alsa drivers? what would be > the best driver source to use for documentation? hmm.. it depends on the hardware design... > - 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. > - 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. 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
