Re: [alsa-devel] [PATCH 3/3] ASoC: Add support for AIF channel muxing on WM8903
Stephen Warren wrote at Wednesday, February 09, 2011 9:33 AM:
Mark Brown wrote at Wednesday, February 09, 2011 6:47 AM:
Signed-off-by: Mark Brown broonie@opensource.wolfsonmicro.com
sound/soc/codecs/wm8903.c | 66 ++++++++++++++++++++++++++++++++++++++++++--- 1 files changed, 62 insertions(+), 4 deletions(-)
...I'll make sure to test it within the next few days, once it's applied.
Mark,
I did find one issue with this.
With the default Left/Right Capture Mux settings, and the patch series I just posted, mic detection now works fine in all the scenarios I tested:
1) Mic plugged in before loading driver, or not. 2) Mic plugged in when starting to capture, or not. 3) Mic removed and plugged back in while capture active.
However, if I flip the Right Capture Mux to setting Left (while not capturing), then this breaks case (3) above; the initial portion of the recording is fine, but when I remove and plug the mic back in, something isn't turned on, and so nothing is recorded after that.
I haven't had a chance to look into this yet, but can later; probably on Saturday evening.
Stephen Warren wrote at Thursday, February 10, 2011 3:59 PM:
Stephen Warren wrote at Wednesday, February 09, 2011 9:33 AM:
...I'll make sure to test it within the next few days, once it's applied.
Mark,
I did find one issue with this. ... However, if I flip the Right Capture Mux to setting Left (while not capturing),then this breaks case (3) above; the initial portion of the recording is fine, but when I remove and plug the mic back in, something isn't turned on, and so nothing is recorded after that.
So, what's happening is that once the mic is removed, there's no active path in the whole codec, so everything gets shut down, including CLK_SYS. In turn, this means that mic detection doesn't work, so when the mic gets plugged back in, that event is not noticed, and nothing gets re-enabled.
If I am playing a stream at the same time as recording, that solves (hides) the problem, since the codec is active and CLK_SYS stays enabled.
I found that if I revert:
2c8be5a26e42cfc4906c4daa8a5a5c82610ddb3d ASoC: Dynamically manage CLK_SYS in WM8903
That also fixes the issue. I'm not entirely clear why though; perhaps there are simply missing entries in the route map for CLK_SYS to mic-related widgets?
On Thu, Feb 10, 2011 at 09:40:37PM -0800, Stephen Warren wrote:
So, what's happening is that once the mic is removed, there's no active path in the whole codec, so everything gets shut down, including CLK_SYS. In turn, this means that mic detection doesn't work, so when the mic gets plugged back in, that event is not noticed, and nothing gets re-enabled.
If I am playing a stream at the same time as recording, that solves (hides) the problem, since the codec is active and CLK_SYS stays enabled.
I found that if I revert:
2c8be5a26e42cfc4906c4daa8a5a5c82610ddb3d ASoC: Dynamically manage CLK_SYS in WM8903
That also fixes the issue. I'm not entirely clear why though; perhaps there are simply missing entries in the route map for CLK_SYS to mic-related widgets?
There's a link from CLK_SYS to Mic Bias so if Mic Bias is enabled then CLK_SYS should be kept up too. However, it looks like the core DAPM logic is getting this wrong and the force enable is only applying to the immediate widget. In the case of a supply widget this is clearly the wrong thing to do. I'll send out a patch for this shortly.
On Thu, Feb 10, 2011 at 02:59:17PM -0800, Stephen Warren wrote:
However, if I flip the Right Capture Mux to setting Left (while not capturing), then this breaks case (3) above; the initial portion of the recording is fine, but when I remove and plug the mic back in, something isn't turned on, and so nothing is recorded after that.
That's just bizzare; I can't off the top of my head think of any reason for it and I'm out of the office today so can't test.
Does the left channel data stay OK (assuming you're mapping the data through on both channels)?
participants (2)
-
Mark Brown -
Stephen Warren