FS#12519 - iPod Classic/6G: swap L-R audio channels

Attached to Project: Rockbox
Opened by Cástor Muñoz (prof_wolfff) - Sunday, 08 January 2012, 20:19 GMT
Last edited by Nils Wallménius (nls) - Saturday, 25 February 2012, 13:53 GMT
Task Type Patches
Category Music playback
Status Closed
Assigned To No-one
Operating System Another
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


Audio channels are inverted on my iPod Classic 80Gb, i don't know if this problem exists on all Classic models. This patch inverts LRCK signal polarity on I2S interface, so it shouldn't have side effects on other sound settings.
This task depends upon

Closed by  Nils Wallménius (nls)
Saturday, 25 February 2012, 13:53 GMT
Reason for closing:  Accepted
Additional comments about closing:  Comitted, thanks!
Comment by Albert Barca (axismundi) - Sunday, 22 January 2012, 17:40 GMT
Just applied the patch, works like a charm for me (ipod 6g 80gb + ipod 6g 120gb). As far as I can see for now, nothing else seems to have been affected. Thanks!
Comment by Cástor Muñoz (prof_wolfff) - Thursday, 02 February 2012, 00:05 GMT
Last weekend, while doing some tests playing music in SVN and patched versions, i noticed like some files sounds somewhat different while other files seems to sound very similar for me, to check i was not getting paranoid i did a frequency response test and it shows that high frequencies are progressively attenuated (-1dB->7KHz, -3dB->11KHz, -6dB->14kHz, -9dB->17kHz) when using this patch, I don't know what is the reason, inverting LRCLK should work, theoretically...

But inverting LRCLK doesn't work, what v2 patch does is to invert AXI bus endianness. SVN version configures it as big-endian, i think this causes L-R channel swap because 32 bit words in memory are using default little-endian, then DMA reads the right sample first and then the left one while I2S is expecting left channel first. if we modify endianness then I2S must be configured as 16 bit samples (instead of 24 bit) to align bytes correctly, i suppose. Another thing the new patch does is to increase DMA source burst from 4 to 8, not necessary for this patch to work but maybe it can save a few microamperes.

I hope v2 patch will solve this problem, i am very busy these days so cannot test it a lot but now music sounds like SVN version for me and spectral shapes are almost identical, it would be great if a young audiophile can confirm it's really ok.

Comment by Albert Barca (axismundi) - Thursday, 02 February 2012, 19:23 GMT
Your findings puzzle me, Castor. Can you give more details, is it something that manifests permanently and regardless of the file format?

I think I have decent ears and I'm using a pretty good set of earphones, yet I didn't notice any change in the sound... Moreover, this weekend I had done some RMAA tests and the frequency response is almost perfect (up to 15 kHz at least), the same as the unpatched version. Today I used the oscilloscope and ran some tests with it, I can detect just a slight decrease in the output voltage as the frequency increases. But this is not really something worth worrying about, not to mention that the unpatched build of Rockbox behaves the same.
Comment by Cástor Muñoz (prof_wolfff) - Friday, 03 February 2012, 00:28 GMT
Hi Albert, i was also a bit confused but now i know what is happening:

I've using v1 patch for three months without noticing something wrong, i used a px-100 set for years but i lost them two weeks ago and i have no replacement at the moment, it was a very unfortunate lost, i didn't know this model is actually out of stock. Last weekend i was testing Rockbox using ipod dock connected to an external audio equipment and a set of headphones who cannot be connect directly to ipod.

I was swapping SVN and patched Rockbox versions very often, auto playback was enabled and the same track sounds all the time, then i begin to notice the effect. My ears, the amp and headphones are normal but i have listen to this track hundred of times before, i sensed something strangle mostly on voices, it was something very light and sporadic, i cannot explain exactly.

Testing other tracks confused me a bit more, some tracks sounds good for me and other not so good but i was not sure, maybe the headphones swap on my head was the reason, i was becoming paranoid so decided to make a quick frequency test using my audio card and Audacity software for Linux. The results surprised me, the patched version shows the high frequencies attenuating much more than SVN version, this attenuation must be noticed on almost any track, but on most tracks i cannot notice it, i was very worried about my ears...

I did a couple of quick tests to confirm the frequency response was not the same on both tracks, wrote the v2 patch, test it on Audacity and headphones and then all appears ok, still didn't knew why inverting LRCLK could produce the attenuation but i was very busy and had no time to think about that.

Your tests shows there is no attenuation, so immediately i launched Audacity to check my graphs, i use a mono test track containing 30 pure tones, if i select both channels the attenuation appears but if i select only one channel then there is no attenuation, eureka!!! left track is delayed one sample, Audacity mixes both tracks to calculate the FFT, phase shift on high frequencies attenuates the mix.

I don't know if some ear can notice that, but i am sure mine can't, more testing shows me that my audio equipment has some DSP engine who is doing something weird with mono tracks when channels are delayed. Quick test on an audio system i have on another room does not produce the effect, i don't know what is going on my audio equipment (EQ and all effects are off), i am very curious and will try to investigate it someday.

I usually listen to 60s-70s music, many tracks have strong stereo separation but also voices and some instruments are just in the center, it is like a mono track if you suppress the other instruments, Now i realize this is the kind of track where i can notice most often the delay effect.

Well... it's very late, but i am glad to know my ears are still usable.
Comment by Albert Barca (axismundi) - Friday, 03 February 2012, 11:07 GMT
Very good detective work, Castor :-).

The explanation is interesting. What is awkward is that your audio equipment is sensitive to the sample difference between channels. The only common DSP/EQ effects that I can think of right now as being the most likely culprits are crossfeed and stereo widening, both require combining information from L and R channels. That or you have quite bad channel separation on your audio equipment, in particular for high frequencies.

Is there any drawback in the way version 2 of the patch works? What I have in mind in particular is the 24 to 16 bits trim for I2S, will this interfere with the sound, especially when using the DSP in Rockbox (EQ and dithering)?

In any case, I'll give v2 a try this evening.

Comment by Cástor Muñoz (prof_wolfff) - Saturday, 04 February 2012, 05:06 GMT
Hi Albert, i have no idea (yet) why the audio equipment does that, it is a normal home multiuse equipment connected to TV i usually use to play music videos, but it sounds decent for me. At this moment i dont think it is a crosstalk, i am very suspicious about inside DSP, EQ and all effects are off so both channels should be processed independently, but maybe DSP has any default 'feature' to cancel noise or somewhat... or bad adc oversampling process... or maybe a firmware bug... who knows :). I want to see the audio output but the only one is headphone jack (fat), i am looking for a cable or adaptor to connect it to my computer.

About the v2 patch, the fast answer is now i am 99% sure v2 is the good patch and i think this is the correct way to do the L-R channel swap.

Technical answer, AFAIK Rockbox software decodes sound files and supplies 16 bit/48KHz samples, stereo channels are interleaved in memory as L1-R1 L2-R2 L3-R3... this is the standard. Both SVN and patched versions sends 16 bit samples to I2S controller, SVN version sends them as 24 bit samples, but it really transmit 16 bits (2 bytes) sending right sample first due to endianness on AXI bus (R1-L1 R2-L2 R3-L3...), I2S controller expects left sample first (standard) so it marks L-R channels incorrectly, then the samples are padded with zero on I2S controller FIFO and finally transmitted through I2s serial interface as 24 bit samples to CS44L55. The patched version (v2) sends 16 bits (2 bytes) as 16 bit samples to I2S controller transmiting left sample first (the standard), i figure these 16 bit samples are also padded with 0 into I2S ctrl FIFO and finally sent to the I2S serial interface as 24 bit samples. So both versions send same data, what changes is the way the samples and bytes are ordered on the bus and the way I2S controller interprets these data to transmit it to the codec, patched v2 sound quality should be the same as SVN version but swapping L-R channels, it sounds like SVN version for me, let me know if you listen something different.

The v1 patch marks L-R channels on I2S serial line ok, but because they are arriving swapped on AXI bus (R1-L1 R2-L2 R3-L3...) they are paired incorrectly (0-R1 L1-R2 L2-R3...) delaying left channel just one sample, as you say i think v1 patch will produce undesired effects when Rockbox crossfeed or other processing is active, didn't test it but i think probably these effects could be noticeable on some tracks.
Comment by Albert Barca (axismundi) - Monday, 13 February 2012, 23:14 GMT
Hi Castor, I've been using the second version of the patch for more than one week, so far I didn't notice any artifacts. I also made some measurements and everything seems ok in terms of raw audio performance, it looks like you've nailed it.
Comment by Cástor Muñoz (prof_wolfff) - Monday, 20 February 2012, 20:09 GMT
Yeah!, seems its also working ok for me, people at head-fi are very happy using it and so far no issues are reported.