On Thu, 2013-01-31 at 20:44 +0100, Clemens Ladisch wrote:
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
Ah, this was my initial design too :)
Some userspace software will actually and validly open a PCM, configure some mixers and then perform a hw_params() -> trigger(). So locking out the PCM at open() for invalid paths breaks some userspace code.
- while the PCM device is open, lock the route configuration, or
We cant do this either as we have to support runtime switching between different use cases (that use different back end components) e.g. MP3 playback to Phonecall
- if changing the route during playback is necessary, allow to set only those routes that are possible with the current PCM configuration.
We do this already, but will first try and fixup any of the configuration differences in the DSP so that the userspace operation succeeds.
I guess Peter/Brent will have to look at the min/max values in more detail.
Liam