iPod Video: Occasional L-R channel swapping

[pbcnx]

i have seen that this happens to the sansa player but this also occurs sometimes with the iPod Video. Custom or Non-Custom Builds. why does this happen anyways?

[Febs]

I have experienced this on (rare) occasions on my iPod Video but I've never been able to replicate the problem.

[jhMikeS]

I've pushed some devs to get 16L-16R samples working for the other Portal Player targets for both this (what I thought was potential) problem and for efficiency.

The reason is that each 16 bit sample is shifted left to 32 bits before being sent to the audio hardware and a delay in getting a sample out can cause the channels to get out of sync if the FIFO goes empty briefly since each channel is sent separately. A little further experimenting would probably get it to work since I already figured out a lot of stuff in order to get it to work on the Sansa. The only difference is that Sansa uses slave mode for its IIS and the others master. I did get somebody to test on an H10 with the change but playback went silent and ran twice the speed but recording worked fine.

e200 uses atomic writes of 16R-16L as a single 32-bit value containing both channels to the FIFO which cuts the amount of data in half over other targets (read: half as many FIQs and twice as long a data reservoir when nearing empty and something prevents an FIQ) and never lets the channels get out of sync with the IIS LRCK. This problem no longer occurs on sansa as it cannot.

[pbcnx]

so that this means that the 16-bit audio is the problem or RockBox itself?  

if so i need to convert 16bit audio to 32-bit ehh...  

[Llorean]

It means the Rockbox code needs some fixing to prevent this problem.