At Sat, 04 May 2002 07:41:28 -0400, Paul Davis wrote: > > >I am starting to write an sound driver for a card with no previous support and > >would like to know if DMA is necessary as per the ALSA framework itself. My > >card doesn't support DMA, yet. So if your answer is no, I would need to > >fallback on OSS for the time being. > > its not. ALSA doesn't require anything but a fairly small set of > function pointers to be initialized so that the "mid-level" code can > manage the device. as long as there is some way to move data to and > from the audio interface (which seems like a pretty basic assumption), > you just have to wrap it up and present it to the mid-level code.
in fact, you don't need even wrappers, if update of periods can be done asynchronously, that is, either by hardware interrupts or timer interrupts. for example, recently i wrote a code to play pcm using emu8000 wavetable engine on sbawe (yes, just for fun :) it has no DMA and no hardware interrupts. the DMA'ish copy is done in copy/silence callbacks. they are called from the read/write syscalls only if defined. interestingly, in the emu8000 pcm routine, there is even no buffer because it transfers the data from user space to its hardware directly by loop. the update of period is established by checking the current pointer in the system timer interrupts. this is odd, of course. the least period size is limited by the timer interrupt frequency. but it works. the problem arises when the transfer rate is really slow or equal with the playback rate. in such a case, it's fairly difficult to get the accurate schedule timing. i don't think this is his case, though. Takashi _______________________________________________________________ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
