On Tue, Jun 23, 2009 at 5:54 AM, Mark Brown<broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote: > On Mon, Jun 22, 2009 at 12:43:52PM -0400, Jon Smirl wrote: >> On Mon, Jun 22, 2009 at 12:27 PM, James > >> > DMA transfers on sound cards are a ring buffer. There is no automatic >> > stop feature. > >> I don't about all hardware, but all of the hardware I've worked with >> works both ways, ring or stop at the end. > >> DMA transfers for network packets wouldn't work in the ring buffer >> model, you need the stop at the end capability. > > Remember, you're working with a general purpose SoC which shares the DMA > controller with a large selection of other hardware. A DMA controller > that's part of a sound device and can't be used in anything else doesn't > need to worry about any other applications. > >From what I have observed the current ALSA DMA design does not reliably deal with over/underrun. On the hardware I'm using it is possible to construct a system which will always behave predictably but I can't build it using the ALSA driver interface. These issues probably indicates that the DMA interface between ALSA and the driver has been designed at the wrong level. For example those timers trying to fix glitches in HDA belong down in the HDA driver, not the core. Why did my DMA code needs to peak back into ALSA core at appl pointer? The proliferation of flags on the DMA interface is also an indication that it is too low level. I'm still working on solutions for my embedded application but I may be forced to add private IOCTLs to the driver and by-pass ASLA. That will work for me since I'm not building a general purpose system. -- Jon Smirl jonsmirl@xxxxxxxxx _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
