[alsa-devel] PandaBoard ES Audio Problems
brentweatherall at gmail.com
Thu Jan 31 23:13:27 CET 2013
Before I begin to dig around, do you know if there is the possibility
a newer kernel (like 3.7 or something) will have fixed this issue?
On Thu, Jan 31, 2013 at 12:00 PM, Liam Girdwood <
liam.r.girdwood at linux.intel.com> wrote:
> 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
> > >> 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
> I guess Peter/Brent will have to look at the min/max values in more
More information about the Alsa-devel