Clemens,
OK. It sounds like I need to go further down into the hardware driver to ferret out the cause. I agree with you it looks like a bad return from hardware. I will see if I can figure out how to get the correct code. it sounds to me like it should be in one of the TI OMAP branches then. Thanks!
Regards,
Brent
On Thu, Jan 31, 2013 at 11:44 AM, Clemens Ladisch clemens@ladisch.dewrote:
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