[alsa-devel] [PATCH] ALSA: soc - fsl_ssi.c fix audio capture

[Anton Vorontsov]

On Fri, Jul 04, 2008 at 07:02:17AM -0400, Timur Tabi wrote:
>
> On Jul 3, 2008, at 10:42 AM, Mark Brown wrote:
>
>> On Thu, Jul 03, 2008 at 06:37:14PM +0400, Anton Vorontsov wrote:
>>> Since we're using SSI in synchronous mode, the STCCR register  
>>> controls
>>> both the receive and transmit sections. So, when we're trying to  
>>> record
>>> anything, stccr register does not get initialized, thus the output  
>>> file
>>> filled with the white noise.
>>
>>> Fix this by initializing the STCCR for both playback and capture. If
>>> TX/RX widths don't match, return that we're busy at the moment.
>>
>>> Signed-off-by: Anton Vorontsov <avorontsov at ru.mvista.com>
>>
>> Acked-by: Mark Brown <broonie at opensource.wolfsonmicro.com>
>>
>> but Timur needs to ack it since I don't have any particular knowledge 
>> of
>> the hardware.
>
> Anton has the right idea, but I'm not sure the fix is the best.  I was  
> planning on posting my fix after I got back from vacation.
>
> Part of the problem is that STCK and SRCK can be wired together, which  
> means that even though you're not in synchronous mode, the sample rates 
> have to match.  For the 8610 HPCD, this isn't a problem, but the SSI 
> driver is supposed to support more than just that board.  We need device 
> tree additions to cover all cases.

Ok, we can set both.

> Anton, are you sure returning -EBUSY is the right fix? 

Since we're using prepare(), yes. But we probably should use
hw_params() and return -EINVAL.

> Would this make 
> applications like mplayer detect the problem and automatically pick a 
> matching sample format that does work?

I don't think that anyone tries to negotiate if/when prepare() failed.
But if hw_params() failed, then yes. Here is updated patch.

Also new patch for the codec used on the HPCD: it seem has the similar
issue, but wrt sampling rate.

On Fri, Jul 04, 2008 at 04:49:29PM +0200, Takashi Iwai wrote:
> I guess it won't work in such a way.  But, at least, you can avoid
> unexpected machine state, which resulted in white noise.
> Since you will post another patch (I suppose it's with hw_constraint
> coupling), I'll postpone this patch as now.

Hm... Not sure hw_constraints are appropriate in these cases, as see
it, they all called in the open routines, while we set up things much
later -- in the hw_params, so we want "dynamic" constraints (please
take a look at the second patch, it is simpler).

Thanks,

-- 
Anton Vorontsov
email: cbouatmailru at gmail.com
irc://irc.freenode.net/bd2