Greetings, > > 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.
I think this EDMA transfer is a special case because the destination address is a register. It's just a hunch, although it's easy to set up a one-shot transfer and look at the transmit holding register after the transfer in CCS. So, in a dummy dsp/bios project you'd do somthing like this pseudo-code: // space for value volatile unsigned int data = 0x44332211; // Use the low-level edma to send to mcasp tx register // ACNT = 4 // BCNT = 1 // CCNT = 1 // SRC = &data // DST = (ASP TX REGISTER) // Step through and check value of register with memory pane // If you 0x11223344 then you have your answer // Now write to the register directly // i.e. ASP_TX_REGISTER = data // Check value, do you get different results? > 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. Yes, sorry I still have the old terminology stuck in my head from back in DM642 days! > 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. Well, PCM data is little endian for storage purposes and other standards purposes, but the AIC33 chips expect most-significant-bit first for transfers. Other codec chips may require data in a different order, which is why the ASP allows for output of 32-bit samples in LSB format (with companding turned on). I think the issue really boils down to the ASP XEVT being queued but not serviced in time to make the real-time deadline, so the ASP just outputs two of the same sample that is in the holding buffer, thus throwing our EDMA indices off by ACNT bytes. The reason the 32-bit transfer 'fixes' the channel swap is that the ASP has both channels in the holding buffer already so if the deadline is missed, both channels will have the same data repeated. You can see this effect by putting out a triangle wave and looking for small flat spots. All in all, I would expect the behavior of the EDMA and ASP to vary by chip and silicon revision because we noticed a huge EDMA prioritization performance change between the DM6441 1.3 silicon and the DM6441 PG 2.1 silicon running the exact same code. Regards, David -- DAVID A. KONDRAD Software Design Engineer On-Q/Legrand Telephone (717) 546-5442 *NEW* www.onqlegrand.com "Nori, Sekhar" <[email protected]> wrote on 10/06/2009 01:48:09 PM: > 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. > > > 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
