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@xxxxxxxxxxxxx> >> >> Acked-by: Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx> >> >> 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@xxxxxxxxx irc://irc.freenode.net/bd2 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
