[alsa-devel] ASoC:Question rate constraint between the dais
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
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.
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.
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).
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
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.
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
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
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.
participants (6)
-
Clemens Ladisch -
James Courtier-Dutton -
Lars-Peter Clausen -
Mark Brown -
Ramesh Babu -
Trent Piepho