Greetings, Please feel free to forward to ALSA list (I'm not a member)... > On Wed, Sep 09, 2009 at 17:38:42, Nori, Sekhar wrote: > > On Fri, Sep 04, 2009 at 00:25:57, Troy Kisky wrote: > > > Nori, Sekhar wrote: > > > > On Thu, Sep 03, 2009 at 05:45:08, Troy Kisky wrote: > > > >> Mark Brown wrote: > > > >>> On Mon, Aug 31, 2009 at 04:31:44PM -0700, Troy Kisky wrote: > > > > [...] > > > >>> I'll probably also apply the first patch since nobody else seems to care > > > >>> one way or another, but I would urge you to look at changing the default > > > >>> for the platform data to at most select the workaround only on CPUs that > > > >>> have problems with channel swapping - it's going to cause confusion for > > > >>> people to have it on by default. > > > >>> > > > >> I think the ones without a problem use davinci-mcasp instead of davinci-i2s > > > >> but share davinci-pcm. So, I don't know of any machines to exclude in > davinci-i2s. > > > >> But if someone else knows, speak up. > > > >> > > > > [...] > > > > > > > > > > > > > Using EDMA acount=4 instead of 2 (32-bit transfers) did fix that issue on the > > > > OSS drivers but I don't recall the problem morphing into an "always channel > > > > swapped" case. > > > > > > > > Have you tested your patch (1/3) with DM644x EVM? If not, we can do that and > > > > see if it leads to channels being always swapped on that hardware as well. > > > > > > Yes, I have tested with dm644x, not evm. I haven't tried to hear the channel swap, > > > but I have no doubt that it is. > > > > I finally got around to testing your patch 1/3 on DM6446 EVM. > > > > Without your patch, channel swap is quite easy to reproduce using audio > > loopback: > > > > arecord -fcd | aplay -fcd > > > > The audio source is a PC which speaker balance set to an extreme. > > By starting and stopping this command repeatedly, you can see the audio > > moving from one channel to the other. > > > > Applying your patch fixes this issue. > > > > Also, I did not notice any permanent channel swap. Used aplay to play data > > which was first left-only and then right-only. Plays the same way on a Linux PC. > > > > I will test on couple of other platform using davinci-i2s (DM355 etc) before > > acking the patch.
Even with a custom audio driver on the DSP-side we were seeing random audio channel mix ups on DM6441. We were even able to recreate it by writing to NAND and/or causing high CPU load with memory accesses. So it's almost certainly a resource starvation issue somewhere inside the switched central resource manager. It turned out to be a EDMA priority issue due to the default priority mapping of CodecEngine. Obviously, you are not using that here with arecord and aplay, but it would be worth a look to see what the default QUEPRI configuration is for that platform. Other platforms may need additional priority adjustments to other bus-masters to meet the real-time deadlines of the McASP and EDMA. > > 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) 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) 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
