ASoC:Question rate constraint between the dais

ASoC:Question rate constraint between the dais

[Ramesh Babu]

Hi

I would like to understand how to handle the different sampling rates
between dais.

I need to make sure that all simultaneous playback and capture (across the
all dai_links) needs to be of same frequency family.
If the sampling frequency of  a new request is different from ongoing
playback/capture, then it needs to be rejected.

How do I handle it in machine driver?

Thanks
Ramesh

Re: ASoC:Question rate constraint between the dais

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 777 bytes --]

On Thu, Mar 15, 2012 at 03:23:04PM +0530, Ramesh Babu wrote:

> I need to make sure that all simultaneous playback and capture (across the
> all dai_links) needs to be of same frequency family.
> If the sampling frequency of  a new request is different from ongoing
> playback/capture, then it needs to be rejected.

> How do I handle it in machine driver?

Why do you need to do this in the machine driver?  Such a constraint
sounds like it's coming from one of the chips in the system rather than
from the machine itself so it'd seem sensible for the chip itself to
impose the constraint so that other machines don't need to replicate the
code.

See wm8988 for an example of adding sample rate constraints, obviously
you can change the criteria dynamically.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: ASoC:Question rate constraint between the dais

[Trent Piepho]

On Thu, Mar 15, 2012 at 1:53 PM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Thu, Mar 15, 2012 at 03:23:04PM +0530, Ramesh Babu wrote:
>> I need to make sure that all simultaneous playback and capture (across the
>> all dai_links) needs to be of same frequency family.
>> If the sampling frequency of  a new request is different from ongoing
>> playback/capture, then it needs to be rejected.
>
>> How do I handle it in machine driver?
>
> Why do you need to do this in the machine driver?  Such a constraint
> sounds like it's coming from one of the chips in the system rather than
> from the machine itself so it'd seem sensible for the chip itself to
> impose the constraint so that other machines don't need to replicate the
> code.
>
> See wm8988 for an example of adding sample rate constraints, obviously
> you can change the criteria dynamically.

There is a race when the constraints change dynamically.  See the
fsl_ssi.c driver and the sample size constraint in synchronous mode.

Say you have two substreams that must be at the same rate.  The first
pcm substream opens, gets a constraint based on current conditions.
If no other substreams are initialized, then this is a range of sample
rates.  Now a second substream opens, before the first is initialized,
and gets the same constraints of a range of sample rates.  The second
stream initializes and starts.  This means the first substream must
now be constrained to be the same sample rate as the second.  But
those constraints were set when the first stream opened.  There's no
way to change them now.

Re: ASoC:Question rate constraint between the dais

[Omair Mohammed Abdullah]

>> I need to make sure that all simultaneous playback and capture (across
>> the all dai_links) needs to be of same frequency family.
>> If the sampling frequency of  a new request is different from ongoing
>> playback/capture, then it needs to be rejected.
>
>> How do I handle it in machine driver?
>
> Why do you need to do this in the machine driver?  Such a constraint sounds like it's coming from one of the chips in the system rather than from the machine itself so it'd seem sensible for the chip itself to impose the constraint so that other machines don't need to replicate the code.
>
> See wm8988 for an example of adding sample rate constraints, obviously you can change the criteria dynamically.

You are right to say that it is not a machine constraint but a codec 
constraint. The problem is that if a DAI (say the "SN95031 Headset DAI") 
is opened with a 44.1 khz rate, then another DAI (say "SN95031 Voice") 
is opened with a 48 khz rate, then we need to reject the second open 
because the codec cannot support both rates at the same time.

Is there any way to do this with constraint_lists? The way it is done in 
the wm8988 driver does not apply here because there it is a single DAI.

Re: ASoC:Question rate constraint between the dais

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 812 bytes --]

On Fri, Mar 16, 2012 at 03:35:18PM +0530, Omair Mohammed Abdullah wrote:

> You are right to say that it is not a machine constraint but a codec
> constraint. The problem is that if a DAI (say the "SN95031 Headset
> DAI") is opened with a 44.1 khz rate, then another DAI (say "SN95031
> Voice") is opened with a 48 khz rate, then we need to reject the
> second open because the codec cannot support both rates at the same
> time.

> Is there any way to do this with constraint_lists? The way it is
> done in the wm8988 driver does not apply here because there it is a
> single DAI.

There's a way to do this, and it's the way that the WM8988 driver is
doing it - obviously you'll have different criteria for choosing
constraints but the actual application of the constraints is going to be
done in the same way.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: ASoC:Question rate constraint between the dais

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 567 bytes --]

On Thu, Mar 15, 2012 at 05:28:13PM -0400, Trent Piepho wrote:

> There is a race when the constraints change dynamically.  See the
> fsl_ssi.c driver and the sample size constraint in synchronous mode.

This is just a limitation of the ALSA ABI - there's nothing we can do
about it without changing the userspace interface so we just have to
live with it and error out if an application ever manages to hit the
race and pick something incompatible with other active streams (note
that the symmetric rates support has a dev_warn() complaining about
hitting the race).

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: ASoC:Question rate constraint between the dais

[Lars-Peter Clausen]

On 03/16/2012 08:25 PM, Mark Brown wrote:
> On Thu, Mar 15, 2012 at 05:28:13PM -0400, Trent Piepho wrote:
> 
>> There is a race when the constraints change dynamically.  See the
>> fsl_ssi.c driver and the sample size constraint in synchronous mode.
> 
> This is just a limitation of the ALSA ABI - there's nothing we can do
> about it without changing the userspace interface so we just have to
> live with it and error out if an application ever manages to hit the
> race and pick something incompatible with other active streams (note
> that the symmetric rates support has a dev_warn() complaining about
> hitting the race).
> 

I think the real problem with this is, that currently a userspace application
will usually exit with an error when such a race occurs, while it should be
possible to just restart the enumeration process and try with another format.

So I'm wondering if we can make it easier for userspace to detect that the
constraints have changed and it may retry with other parameters? E.g. return a
special error code in such a case.

- Lars

Re: ASoC:Question rate constraint between the dais

[Trent Piepho]

On Fri, Mar 16, 2012 at 3:22 PM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Fri, Mar 16, 2012 at 03:35:18PM +0530, Omair Mohammed Abdullah wrote:
>
>> You are right to say that it is not a machine constraint but a codec
>> constraint. The problem is that if a DAI (say the "SN95031 Headset
>> DAI") is opened with a 44.1 khz rate, then another DAI (say "SN95031
>> Voice") is opened with a 48 khz rate, then we need to reject the
>> second open because the codec cannot support both rates at the same
>> time.
>
>> Is there any way to do this with constraint_lists? The way it is
>> done in the wm8988 driver does not apply here because there it is a
>> single DAI.
>
> There's a way to do this, and it's the way that the WM8988 driver is
> doing it - obviously you'll have different criteria for choosing
> constraints but the actual application of the constraints is going to be
> done in the same way.

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
fsl_ssi driver is a better example for that, as it has a constraint
like this that is dynamic and based on the current configuration of
another substream.

And as I said before, ALSA doesn't handle this 100%.  There is a race
if both streams are initialized at the same time.  If you open one
stream, setup the parameters, then open another stream, the second
stream opened will have the proper constraints.  But if you open the
second stream _before_ the first has setup it's parameters (called
->hw_params() method) then the second won't have the proper
constraints.  How can the 2nd stream constrain the rate to that of the
1st stream when the 1st has yet to choose a rate?

I think what's necessary is for ALSA to let hw_params return an error
code that means lets the driver say, "Sorry, the constraints have
changed and the hw_params you have chosen are no longer valid.  Here
are new constraints, please try again."

And in turn you need ALSA lib and application code to be able to
handle a sequence like this: "We have 44.1k and 48k rates available."
"I'd like 48k."  "I'm sorry, we're out of 48k, would you like 44.1k?"

Re: ASoC:Question rate constraint between the dais

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 772 bytes --]

On Fri, Mar 16, 2012 at 09:00:12PM +0100, Lars-Peter Clausen wrote:

> So I'm wondering if we can make it easier for userspace to detect that the
> constraints have changed and it may retry with other parameters? E.g. return a
> special error code in such a case.

I think an event would be better; userspace or possibly the in kernel
core can turn it into an error code if it wants to but from a driver
point of view the event seems simpler.  If the drivers try to do an
error code it has to keep track of which applications saw what and if
they're affected by a given change which is more trouble than it's
worth.

Though to be honest the race is almost always an application fighting
with itself over bidirectional audio so practically the problem isn't
often serious.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: ASoC:Question rate constraint between the dais

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 1780 bytes --]

On Fri, Mar 16, 2012 at 06:01:44PM -0400, Trent Piepho wrote:
> On Fri, Mar 16, 2012 at 3:22 PM, Mark Brown

> > There's a way to do this, and it's the way that the WM8988 driver is
> > doing it - obviously you'll have different criteria for choosing
> > constraints but the actual application of the constraints is going to be
> > done in the same way.

> 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.

> And as I said before, ALSA doesn't handle this 100%.  There is a race
> if both streams are initialized at the same time.  If you open one

Yes, I did reply to your previous mail about that pointing out that this
is impossible...

> I think what's necessary is for ALSA to let hw_params return an error
> code that means lets the driver say, "Sorry, the constraints have
> changed and the hw_params you have chosen are no longer valid.  Here
> are new constraints, please try again."

Thinking about this slightly further than in my reply to Lars-Peter a
few minutes ago...

I think just returning -EINVAL on bad parameters (which is pretty much
what we do) is sufficient for this if the driver is good about keeping
the constraints up to date.  Applications should already be able to take
the hint, though I imagine most of them wouldn't trust the drivers to
provide accurate constraints and aren't as widely deployed as PulseAudio
(which forced fixing the DMA stuff by virtue of everyone using it).
Though just spinning a small number of times will probably deal with
lying drivers well enough.

We could still generate an event but I'm now even less sure it's worth
drivers doing anything special about this.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: ASoC:Question rate constraint between the dais

[Clemens Ladisch]

Lars-Peter Clausen wrote:
> On 03/16/2012 08:25 PM, Mark Brown wrote:
>> On Thu, Mar 15, 2012 at 05:28:13PM -0400, Trent Piepho wrote:
>>> There is a race when the constraints change dynamically.  See the
>>> fsl_ssi.c driver and the sample size constraint in synchronous mode.
>>
>> This is just a limitation of the ALSA ABI - there's nothing we can do
>> about it without changing the userspace interface so we just have to
>> live with it and error out if an application ever manages to hit the
>> race and pick something incompatible with other active streams (note
>> that the symmetric rates support has a dev_warn() complaining about
>> hitting the race).
>
> I think the real problem with this is, that currently a userspace application
> will usually exit with an error when such a race occurs, while it should be
> possible to just restart the enumeration process and try with another format.
>
> So I'm wondering if we can make it easier for userspace to detect that the
> constraints have changed and it may retry with other parameters?

Devices that have such a restriction must be marked with
SNDRV_PCM_INFO_JOINT_DUPLEX.  There is no indication that the race has
actually happened, so applications that care have to retry just in case.


Regards,
Clemens

Re: ASoC:Question rate constraint between the dais

[Trent Piepho]

On Sat, Mar 17, 2012 at 7:48 AM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
>
> On Fri, Mar 16, 2012 at 06:01:44PM -0400, Trent Piepho wrote:
> > On Fri, Mar 16, 2012 at 3:22 PM, Mark Brown
>
> > > There's a way to do this, and it's the way that the WM8988 driver is
> > > doing it - obviously you'll have different criteria for choosing
> > > constraints but the actual application of the constraints is going to be
> > > done in the same way.
>
> > 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
two WM8988 codecs, how does one codec get a handle to the other?
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
slave codec a phandle to the master codec.

> > And as I said before, ALSA doesn't handle this 100%.  There is a race
> > if both streams are initialized at the same time.  If you open one
>
> Yes, I did reply to your previous mail about that pointing out that this
> is impossible...

...which didn't arrive until after I started writing my email.

> > I think what's necessary is for ALSA to let hw_params return an error
> > code that means lets the driver say, "Sorry, the constraints have
> > changed and the hw_params you have chosen are no longer valid.  Here
> > are new constraints, please try again."
>
> Thinking about this slightly further than in my reply to Lars-Peter a
> few minutes ago...
>
> I think just returning -EINVAL on bad parameters (which is pretty much
> what we do) is sufficient for this if the driver is good about keeping
> the constraints up to date.  Applications should already be able to take
> the hint, though I imagine most of them wouldn't trust the drivers to
> provide accurate constraints and aren't as widely deployed as PulseAudio
> (which forced fixing the DMA stuff by virtue of everyone using it).
> Though just spinning a small number of times will probably deal with
> lying drivers well enough.

Does PulseAudio handle it if hw_params fails?  From what I've seen,
most applications just fail if hw_params fails.

I think there is still a race in the design of ALSA, in that the
driver checking the parameters in its hw_params() method is not atomic
with the substream being assigned those parameters, w.r.t. another
substream.

The problem is in the code for snd_pcm_hw_params(),

 405        err = snd_pcm_hw_params_choose(substream, params);
 406        if (err < 0)
 407                goto _error;
 408
 409        if (substream->ops->hw_params != NULL) {
 410                err = substream->ops->hw_params(substream, params);
 411                if (err < 0)
 412                        goto _error;
 413        }
 414
 415        runtime->access = params_access(params);
 ...
 455        runtime->status->state = SNDRV_PCM_STATE_SETUP;

At line 410 the driver is given a chance to approve the selected
hw_params.  It can look at any of the joint substreams, and if they
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
parameters and entered the SETUP state. There is no lock to prevent
another substream from entering this code at the same time.  To fix
the race, there would need to be a critical section from line 408-455
that only one substream of the group with joint constraints can enter
at one time.

Re: ASoC:Question rate constraint between the dais

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 2257 bytes --]

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
pointer.

> 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.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: ASoC:Question rate constraint between the dais

[Jassi Brar]

On Sun, Mar 18, 2012 at 1:19 AM, Trent Piepho <tpiepho@gmail.com> wrote:
>>
>> > > There's a way to do this, and it's the way that the WM8988 driver is
>> > > doing it - obviously you'll have different criteria for choosing
>> > > constraints but the actual application of the constraints is going to be
>> > > done in the same way.
>>
>> > 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
> two WM8988 codecs, how does one codec get a handle to the other?
>
A CODEC is constrained only by its own, not by its another instance.
If your machine routes related signals to two instances of the CODEC,
then you have constraints at machine level, still not at codec level.
So your machine driver should keep track of the first active codec's
configuration and impose that on dais of the other as requests come.
If actually your machine doesn't impose any such constraint, it becomes
a policy, which should be imposed from user-space.

Implementation wise, maybe two tightly coupled dais at machine level,
could be represented as one virtual dai with independent virtual 'mute'
switches for each physical path?

I find it so obvious, so perhaps I am overlooking something :D

-j
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: ASoC:Question rate constraint between the dais

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 857 bytes --]

On Sun, Mar 18, 2012 at 11:52:01AM +0530, Jassi Brar wrote:

> Implementation wise, maybe two tightly coupled dais at machine level,
> could be represented as one virtual dai with independent virtual 'mute'
> switches for each physical path?

When I've considered implementing this in the past I've thought about
doing something like having DAI groups which own the physical link
configuration when you've got more than one logical link on the same
physical infrastructure.  The physical configuration would then get
punted up to the group level and we'd need some mechanism for the group
to start clocks when required.

I've only ever thought about it though so there may be some problems
there I've not come up with yet.  Might be useful to start the
refactoring for the clocks anyway, might be useful for the
reconfigurable channel allocation cases too.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: ASoC:Question rate constraint between the dais

[James Courtier-Dutton]

On 15 March 2012 09:53, Ramesh Babu <ramesh.babu@linux.intel.com> wrote:
> Hi
>
> I would like to understand how to handle the different sampling rates
> between dais.
>
> I need to make sure that all simultaneous playback and capture (across the
> all dai_links) needs to be of same frequency family.
> If the sampling frequency of  a new request is different from ongoing
> playback/capture, then it needs to be rejected.
>
> How do I handle it in machine driver?
>

A more deterministic method to do this would be have a mixer setting
to select the sample rate on a card wide bases.
Then all applications will only have one sample rate to choose from.
FYI: All EMU sound cards do it this way.
If the user wishes to change the sample rate, they close down all the
applications using the old rate, change the mixer setting, and then
start the apps up at the new rate.
Then applications that wish to use different sample rates, will need
to provide a sample rate conversion function.
A majority of the sound cards out there do 48KHz well, but not so well
on other rates, so defaulting to 48KHz is probably the best choice.
I know pulseaudio falls over hopelessly if it is set to 44.1KHz and
some USB web cam can only do 48KHz for the MIC.
Setting everything to 48KHz cures a lot of problems.
One of the most difficult things is getting 44.1KHz MP3s etc.
resampled to 48KHz, but most MP3 playing apps support good resamplers
so they can still talk to pulseaudio at 48KHz.

Kind Regards

James
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: ASoC:Question rate constraint between the dais

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 711 bytes --]

On Mon, Mar 19, 2012 at 04:12:42PM +0000, James Courtier-Dutton wrote:

> A majority of the sound cards out there do 48KHz well, but not so well
> on other rates, so defaulting to 48KHz is probably the best choice.

This really isn't so true in the embedded space, there's a few systems
that only do 48kHz to the AP but generally if there's a fixed sample
rate it'll usually be 44.1kHz and otherwise the rates will be flexible.

> One of the most difficult things is getting 44.1KHz MP3s etc.
> resampled to 48KHz, but most MP3 playing apps support good resamplers
> so they can still talk to pulseaudio at 48KHz.

Again, not so true for embedded and burning power on resampling tends
not to make people happy.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]