On Tue, Sep 29, 2009 at 20:43:20, [email protected] wrote: > Greetings,
Hello David, > > On Wed, Sep 09, 2009 at 17:38:42, Nori, Sekhar wrote: [...] > > > > Even on the DM355 EVM this patch fixes the random channel swap on audio > > loopback 'arecord -fcd | aplay -fcd'. > > > > However, on playback, the channels do seem to be permanently swapped. > This cannot > > surely be blamed on this patch because, without it, the channels get > randomly > > swapped. > > I also tried this technique and achieved the same results with our custom > driver. > It's an endian issue related to the EDMA casting memory accesses as > representational values. > > Example: LL = Left LSB, LM = Left MSB, RL = Right LSB, RM = Right MSB > > data to copy : LL LM RL RM > interpreted as dword: RM RL LM LL (cast above memory to unsigned int) > > data sent by McASP : RM RL LM LL (always big-endian unless companding is > turned on) Hmm, where is the ending issue occurring? I don't think EDMA causes endian change when ACOUNT is set to 4. There is no ACOUNT=4 example in the EDMA user guide, but the two byte burst transfer example in section 3.4.2 in the spru (http://focus.ti.com/lit/ug/sprue23d/sprue23d.pdf) did not show any endian swap. > > You don't see it with 2 byte transfers because the data goes out how you > would expect: > > data to copy : LL LM RL RM > interpreted as 2 words: LM LL RM RL (cast above memory to unsigned short) > > data sent by McASP : LM LL RM RL (always big-endian unless companding is > turned on) I guess you mean ASP not McASP. The ASP user guide says it transfers data MSB (Most Significant Bit) first, but I did not find any reference to big endian transfers. PCM data is little endian, so I guess, the codec should receive the data as LL LM RL RM, else, the song will not play correctly. Thanks, Sekhar > > There are a few ways to correct this: (not all may be applicable) > > 1. Use EDMA to copy between large holding buffer and small ping/pong buffer > using AB-sync transfers to byte-swap data > Since the whole point was to reduce EDMA usage, if you're not doing this > now then it may make problem worse > > 2. Pre-process the buffer using a CPU loop > Again may run into resource issues > > 3. Channel swap inside AIC33/AC97 driver > Use the internal mixer to route left dac to right output and vice versa. > Pretty easy to do, but must keep track channel state and map all > requests to other channel. > > > > > Since this was not observed on DM6446 EVM, I have to see if the DM355 EVM > > hardware swaps the channels. I briefly compared the schematics of the two > EVMs, > > but nothing seems to be wrong there. > > We've certainly seen it on our DM6441 and DM6446 EVMs (old 1.3 silicon and > DM6441 PG 2.1 silicon) > and the spotty (OSS at the time) audio driver performance is what prompted > a re-write using a DSP-side driver in the first place. > > Hope this helps, > David > > -- > DAVID A. KONDRAD > Software Design Engineer > Legrand Home Systems Divison (formerly OnQ/Legrand) > www.onqlegrand.com > > This email, and any document attached hereto, may contain > confidential and/or privileged information. If you are not the > intended recipient (or have received this email in error) please > notify the sender immediately and destroy this email. Any > unauthorized, direct or indirect, copying, disclosure, distribution > or other use of the material or parts thereof is strictly > forbidden. > > _______________________________________________ > Davinci-linux-open-source mailing list > [email protected] > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source > _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
