[alsa-devel] [PATCH] ALSA: soc - fsl_ssi.c fix audio capture
avorontsov at ru.mvista.com
Fri Jul 4 17:43:13 CEST 2008
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
>>> both the receive and transmit sections. So, when we're trying to
>>> anything, stccr register does not get initialized, thus the output
>>> 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
>> 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).
email: cbouatmailru at gmail.com
More information about the Alsa-devel