[alsa-devel] [PATCH] ALSA: soc - fsl_ssi.c fix audio capture
avorontsov at ru.mvista.com
Mon Jul 21 13:15:18 CEST 2008
On Fri, Jul 04, 2008 at 07:43:13PM +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.
Timur, have you had a chance to look into these two patches?
email: cbouatmailru at gmail.com
More information about the Alsa-devel