[alsa-devel] ASoC:Question rate constraint between the dais
broonie at opensource.wolfsonmicro.com
Sat Mar 17 21:31:03 CET 2012
On Sat, Mar 17, 2012 at 03:49:06PM -0400, Trent Piepho wrote:
> On Sat, Mar 17, 2012 at 7:48 AM, Mark Brown
> > On Fri, Mar 16, 2012 at 06:01:44PM -0400, Trent Piepho wrote:
> > > Since the constraint is based on the current configuration of another
> > > DAI, the two DAIs need some way to query each other's parameters. The
> > Since they're both provided by the same driver this is trivial.
> It's not that trivial with the sub-streams in question aren't in the
> same instance of the driver, e.g. playback and record. Say you had
It's very easy to go back from the DAI to the CODEC, there's a direct
> two WM8988 codecs, how does one codec get a handle to the other?
Such a constraint would be machine imposed, not CODEC imposed - the case
the Intel guys were talking about was a constraint between the two
interfaces on a single CODEC. There's no way the driver for one CODEC
should be doing anything about another CODEC.
> There's no global list of codecs in the driver, so you have to add
> something like that. Or change the device tree binding to give the
You're talking about a totally different use case here, there's way more
issues than just the constraints getting multiple CODECs on the same
link to play nicely.
> slave codec a phandle to the master codec.
No, that wouldn't be sensible - this should all be handled at the DAI
level. Adding explicit code in individual CODEC drivers for this would
be an awful lot of duplication.
> Does PulseAudio handle it if hw_params fails? From what I've seen,
> most applications just fail if hw_params fails.
I've no idea what PulseAudio does; I suppose someone who's interested
could look at the code. Most applications do just fail, like I say it's
exceptionally rare to hit any of thist stuff.
> are in state >= SETUP, verify that the hw_params are still valid and
> if not, update the constraints and return an error. But it is not
> until line 455 that the substream has actually finished getting the
So long as the driver takes care that only one of multiple concurrent
hw_params() calls manages to successfully return we should be fine, once
the hw_params() call has returned we're committed to flagging success.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 836 bytes
Desc: Digital signature
Url : http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20120317/bb3f60f4/attachment.sig
More information about the Alsa-devel