RE: [alsa-devel] [PATCH] ASoC: atmel_ssc_dai: Track playback and capture CMR dividers separately.

[Peter Rosin]

Hi again!

> Hi Peter,
> 
> On 10/21/2014 03:55 PM, Peter Rosin wrote:
> > Hi!
> >
> > (and thank you for the pointer to the example with the ssc-dai in
> > master mode)
> >
> >> Hi Peter,
> >>
> >> On 10/20/2014 09:45 PM, Peter Rosin wrote:
> >>>   From 1e5621d7b9887c648d1a66238dc82d715c1e2cad Mon Sep 17
> 00:00:00
> >>> 2001
> >>> From: Peter Rosin <peda@xxxxxxxxxx>
> >>> Date: Mon, 20 Oct 2014 14:38:04 +0200
> >>> Subject: [PATCH] ASoC: atmel_ssc_dai: Track playback and capture CMR
> >> dividers
> >>>    separately.
> >>>
> >>> The CMR divider register is shared by playback and capture. The SSC
> >>> driver therefore tries to enforce rules so that the needed register
> >>> content do not conflict during simultaneous playback/capture.
> >>> However, the implementation also prevents changing the register
> >>> content in a half-duplex scenario, which is needed when changing
> sample rates.
> >>
> >> I am not fully get what you mean here, do you mean:
> >>     - when playback, first playback 48kHz, and then playback 8Khz,
> >> the 8Khz still playback in 48kHz mode?
> >>
> >> or other things?
> >
> > I do not know exactly why the problem occurs, but it might be
> > connected to the library (proprietary) we are using. It apparently
> > uses the OSS interface and somehow it opens a stream and changes the
> > playback sample-rate a couple of time before it settles on something.
> > I don't know why this is done, and I have no control over it. The end
> > result is that without this patch, the ssc-dai driver returns -EBUSY
> > when the library changes the playback sample-rate (the driver returns
> > -EBUSY because it thinks that the new sample rate does not match a
> > previously given capture sample-rate, but that is of course bogus when no
> capture is going on at all).
> 
> If this issue is caused by your proprietary library, please fix in the library.

Ah, but it's not "our" proprietary library to fix, it's simply a library that we
are using (speech synthesis, not our area of expertise). So, I'm not in a
position to simply fix it, as I have no source code.

> I don't know how this code can fix your issue and also there is no
> improvement to the code and it absolutely increase work (choose which
> clock to configure: tcmr or rcmr) for the SSC work in master. And also this
> patch may confuse the end user, let them thinking the clock for tcmr and
> rcmr can configure seperately.

I added some traces to our hw_params and got the following (without the patch):

[  161.170000] atmel ssc startup
[  161.170000]  TFA9879: axentia_asoc_tfa9879_hw_params - mclk rate 66000000
[  161.180000]  TFA9879: axentia_asoc_tfa9879_hw_params - bclk rate 128000
[  161.180000]  TFA9879: axentia_asoc_tfa9879_hw_params - bclk divider 128
[  161.190000]  TFA9879: axentia_asoc_tfa9879_hw_params - period 7
[  161.200000]  TFA9879: axentia_asoc_tfa9879_hw_params - mclk rate 66000000
[  161.200000]  TFA9879: axentia_asoc_tfa9879_hw_params - bclk rate 128000
[  161.210000]  TFA9879: axentia_asoc_tfa9879_hw_params - bclk divider 128
[  161.220000]  TFA9879: axentia_asoc_tfa9879_hw_params - period 7
[  161.230000]  TFA9879: axentia_asoc_tfa9879_hw_params - mclk rate 66000000
[  161.230000]  TFA9879: axentia_asoc_tfa9879_hw_params - bclk rate 256000
[  161.240000]  TFA9879: axentia_asoc_tfa9879_hw_params - bclk divider 64
[  161.250000]  TFA9879: axentia_asoc_tfa9879_hw_params - Failed to set cpu dai clk divider
[  161.260000] axentia-tfa9879-audio sound.9: ASoC: machine hw_params failed: -16

> So, I think keep the code as is (without this patch applied), what's your
> opinion?

In that case we'll simply carry the patch ourselves. I don't know why the above
happens, or if it is caused by bad behavior in the library, or what. But I do know
that the library is unusable for us without some action.

I thought it was an improvement, and therefore sent the patch...

Cheers,
Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/