On 03/13/15 13:56, Lars-Peter Clausen wrote:
On 03/13/2015 12:36 PM, Jyri Sarha wrote:
[...]
In theory this patch does exactly what it is supposed to. It only
allows a sample-rate and sample-format combination if the rate can be
produced with reasonable accuracy. Unfortunately the alsa-lib and
alsa-tools are not able use this information too well. If the requested
sample-rate and sample-format is not available the aplay/arecord
fails, even if plughw is selected, with:
pcm_params.c:170: snd1_pcm_hw_param_get_min: Assertion
`!snd_interval_empty(i)' failed.
[...]
+
+ /*
+ * If we rely on implicit BCLK divider setting we should
+ * set constraints based on what we can provide.
+ */
+ if (mcasp->bclk_master && mcasp->bclk_div == 0 &&
mcasp->sysclk_freq)
+ return snd_pcm_hw_rule_add(substream->runtime, 0,
+ SNDRV_PCM_HW_PARAM_RATE,
+ davinci_mcasp_hw_rule_rate,
+ mcasp,
+ SNDRV_PCM_HW_PARAM_FRAME_BITS,
+ SNDRV_PCM_HW_PARAM_CHANNELS, -1);
+
For things to work correctly you also need reverse rules restricting
CHANNELS and FRAME_BITS based on the RATE. This might fix the issue you
are seeing with the ALSA tools.
Thanks, that was indeed the case. I mail a new patch once I get my patch
in order.
Best regards,
Jyri
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
