On 03/20/2014 04:15 PM, Lars-Peter Clausen wrote:
That sounds like a bug in either the kernel or alsa-lib. We do have a rule in place that specifies that the buffer size needs to be a integer multiple of the period size and we have a rule in place that the period size needs to be a multiple of a constant C. Hence ALSA should be able to deduce that the buffer size needs to be at least a multiple of min_periods * C. We probably should fix this for good and not workaround it in individual drivers. Do you think you can put together a small standalone test application that shows the issue?
Now that I have 'wasted' quite some time with this I ended up writing the tool to test the issue.
It is a simple tool which: opens the hw:0,0 (you can pass another PCM to open). Goes and tests 44.1, 88.2, 48 and 96 KHz from 0.1s to 1s buffer time with 0.005s steps. It prints the running test and tells if the combination failed or not. If it is OK, it is going to print the resulting buffer time.
Since the output is long for email they are in pastebin.
On am335x-evmsk only period_step = 32 constraint is placed by the McASP driver: http://pastebin.com/C81uQkJd
When both period_step and buffer_step is set to 32: http://pastebin.com/D8hr3bQ1
As a note: if I run this tool on my desktop/laptop it does fail in some combination there as well with hd_intel. What is even more interesting is that I have less failure cases with hda_intel on 64bit machines then on my old macbook1,1 which is 32bit Linux. Basically the mcabook,1,1 behaves similarly like my am335x (when I change the hda_intel driver to place only period_step = 32 constraint)