Brent Weatherall wrote:
stepping through the ALSA code, it seems the error *might* be in the ALSA code, but I am probably reading the code incorrectly:
pcm/interval.c:
That code is correct (it's used in a different context).
The problem is that the kernel driver returns wrong min/max values.
Liam Girdwood wrote:
The OMAP4 ABE driver doesn't actually know the exact constraints if there is not a valid playback path between source PCM and sink (it will still throw out anything insane though). This is because it can route audio from most of it's PCMs to most of it's components, e.g. HS, HF, BT, MODEM, Earpiece, etc where some components have different constraints. It's possible that you dont have a path in your case.
In theory, what the driver should do is: - don't allow the PCM device to be opened if there is no valid route configuration (or just never allow a completely invalid configuration); and - while the PCM device is open, lock the route configuration, or - if changing the route during playback is necessary, allow to set only those routes that are possible with the current PCM configuration.
Regards, Clemens