On Tue, Mar 20, 2012 at 1:27 PM, Grazvydas Ignotas notasas@gmail.com wrote:
On Tue, Mar 20, 2012 at 7:04 PM, Mark Brown broonie@opensource.wolfsonmicro.com wrote:
On Tue, Mar 20, 2012 at 06:15:34PM +0200, Grazvydas Ignotas wrote:
On Tue, Mar 20, 2012 at 6:01 PM, Mark Brown
though this should probably have the note about working around broken applications from the cover letter in the changelog as with the changelog alone it's really not apparent why we're doing this here as a driver specific thing.
I wouldn't really call them broken, it's enough to set period size to 512 with smaller start_threshold (something like 50ms) to have problems, those parameters are perfectly valid for a program trying to achieve low latency.
If they can't cope with the parameters they've set I'd call them broken, they should've asked for more sensible parameters.
It sounds like the problem happens if an application sets start_threshold to something less than the FIFO size. E.g., set start_threshold to 50ms, app writes 50 ms to stream, gets an instant underrun when the sDMA quickly reads > 50 ms of audio as it fills the FIFO. Doesn't seem like the app is broken to expect that after writing 50 ms of audio it has almost 50 ms to write more before an underrun.