On 03/20/2012 09:47 PM, Trent Piepho wrote:
To me this looks more like a correct fix. At quick test I got single xrun when starting up but not endless loop of them. Maybe need to tune a bit with CONFIG_SND_PCM_XRUN_DEBUG=y.
Does the ALSA API allow the driver to change start_threshold in the prepare function? It seems what is needed is a minimum start_threshold constraint, but there aren't constaints for sw_params.
I did as well looked at the start_threshold, and came to the same conclusion. It is sw_param, and the driver should not modify it. The OSS emulation layer sets the start_threshold to 1, most application sets the start threshold to the size of the buffer. Some legacy application might not care about this at all. Others might want specific threshold to start the actual playback.
With that fix, you could have an app set start_threshold to 50 ms, write 51 ms of audio, and expect the stream to start. But it won't, because the driver has increased start_threshold. The app could have read back start_threshold from the driver, but I doubt any apps do this, since there is nothing in the documentation about that being necessary.
True, it is a sw_param, and the applications does not expect it to be changed by the driver (since the driver should not change it).