Bugzilla – Bug 12853
Channels swapped with r6556
Last modified: 2009-09-08 09:15:52 UTC
The channels appear to be swapped with r6556. As a result the custom mp3 file with filters applied for the in store demo will be channel swapped to compensate so that the high pass content will be on the right channel and the low pass content will be on the left. Hopefully the swap is consistent and does not swap back over time.
Richard, steven noticed that the channels seem to be swapped from what is expected. From the schematics and wire harness, we expect the tweeter to be on the left channel, woofer on the right. But when we play sounds, it appears that the opposite is true. Do you have any comments/thoughts on that?
Discussed with Caleb, he is going to check the i2s bus.
Shoot, I tried looking at this, but its mixed to mono for some reason when I use aplay. The last line of /etc/asound.conf is commented out, so it doesn't seem the be the babydsp plugin mixing to mono. Can you reconfigure so that babydsp is always being used, then I can put in a non-mono version when testing?
The /etc/asound.conf file controls if babydsp is used, and that should be the only place making it mono. You sure it wasn't enabled? If all lines are uncommented then the filter is used by aplay and squeezeplay.
Oops, I think I was playing an mp3, which didn't work so good with aplay. Anyway, I see that there are only 16 bit-clock periods per LR clock phase, whereas i thought it should be 32. And data seems to get 'left-over' in the other phase. See attachment. Clearly, this doesn't seem right. Don't know how we got this far with the format so far off. The data is from a sine wave that is playing only in the left channel.
Created attachment 5498 [details] 16-bit I2S mode?
Created attachment 5499 [details] 16 bit clocks per LR clock.
That might be aplay, it'll open the device with a different format than squeezeplay. That would explain the 16 bits. Can you do the same test using squeezeplay as the source?
Richard, I found a couple of things: tlv320aic3104 line 1212 does actually set the # of bits going over the i2s bus. I don't know if that's strictly necessary, but I'm not sure it hutrs. In order to test the LR swap, I'm using the babydsp plugin (damn that's going to be useful!), to set *dst[0] = 0; *dst[1] = 0xAAAAAAAA; When doing this, I get the signal in the LOW part (left) of the I2S signal. I believe this is reversed from what is typically expected. generally audio goes LRLR not RLRLR.
Also,tlv320aic3104 changes the # of clocks/LRclock (line 1212). I don't know if this is a problem or not. I think it could be left a 32 clocks/LRCLK without problem. -Caleb
I think we need to ask Freescale about this.
Sammy as freescale commented: Our driver always sends data in left channel first. There is STCR register in SSI to control invert of frame sync. I just went through the patch gotten from Richard(it is old and I don't know whether it is updated now). SND_SOC_DAIFMT_NB_IF format was set, I think you should try SND_SOC_DAIFMT_NB_NF for normal I2S mode. Fixed in r6808 in fab4 branch (not baby-mp).