2010/2/4 pl bossart <bossart.nospam@xxxxxxxxx> > >> - the 'only' change is to make sure the hw_ptr reported in .pointer is > >> NOT the number of samples pushed out to the interface. hw_ptr should > > > > although, I'm not entirely sure this still makes rewinds fully safe. > After > > driver has called period elapsed and hw_ptr jumps ahead one period worth > of > > samples, the DMA for the next burst/batch is already programmed and > possibly > > ongoing. And with some drivers the burst size (of a single DMA > transaction) > > may be fairly large, while some transfer sample at a time, at codec rate. > > > > This might lead to undefined behaviour when application rewinds upto > hw_ptr > > and starts to refill the segment of the ringbuffer just after hw_ptr, > while > > at the same time DMA engine is already transferring data out of that same > > ringbuffer segment. > > > > So a safer bet would be to limit rewinds to hw_ptr+X, where X is highly > > driver/hw specific. At the minimum, 'X >= dma_get_cache_alignment()' (see > > linux/Documentation/DMA-API.txt) to get deterministic results on > different > > platforms. A sane convervative assumption is 'X >= period-size'. > > Well, we went from my interpretation that was completely broken to > something that can still be broken at times... > If you really want to be safe, you'd need a means to specify this X > value for your system. Actually it would make a lot of sense to do so. > On most embedded systems the DMA bursts and buffering in FIFOs can be > programmed. It'd be nice to have the ability to set different values > for DMA bursts and delay depending on the mode (low-power, > low-latency, etc). > > will your propsed hw_ptr move when underrun occur ? >> if the 'only' change is to make sure the hw_ptr reported in .pointer is NOT the number of >> samples pushed out to the interface. >> hw_ptr should really represent the next read position in the ring buffer, this isn't >> uniform across drivers. This means for example that the HDAudio >> implementation needs to modified so that the LPIB value is increased >> with runtime->delay. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
