See campfire discussion from last night:

- Seems that it is repeatable every reboot for me and Felix.

- only impacts analog not spdif

- Channels are flipped back if you play something with a different sample rate than 44100 and the correct channels are maintained if you then play something at 44100.

(this would cause pcm_open to be called again and the alsa params to be reset, so I reason it may be an ordering problem with the alsa setup?)

Maurice is concerned that this is a silicon bug in the mx35.  Richadr, do you share this worry?

Looks to me like software - it is possibly introduced by a recent change to decode_alsa.c.

Don't understand why at present, but commenting out the call to snd_hctl_open possilby avoids it.

Created attachment 4704 [details]
possible patch - only call snd_hctl_open on the playback device

This patch appears to resolve for me.  However I am not sure it has for Keith - may need to look at his hardware?

Previously we were calling snd_hctl_open on the effects device which fails - as this occurs in parallel for both devices in different threads I am not sure how failure of one device impacts the other, but only calling for the playback device seems to avoid it...

Do we really need to do scn_hctl twice though as we do once when calling pcm_open to test the device and then again when we start up the thread (and then again everytime the sample rate changes)?

I think this is something to do with alsa or dma/hardware - all the previous patch below did was avoid one of the trigger conditions (well it seemed to!) but it is still very reproducable with Keith's flac channel test file and is cleared when the same rate is changed (which drains the alsa queue and restarts it).

I produced an image which always puts noise in one channel - this shows that the channel change happens at times of other activity - sometimes even triggered by starting a software upgrade!

So I think this needs checking with different hardware and whatever options you have to change the dma code Richard.

For ref all my debug image does is:

--- /home/adrian/jive/fab4/squeezeplay/src/squeezeplay/src/audio/decode/decode_alsa.c   2009-01-14 21:05:03.000000000 +0000
+++ tmp/work/armv6-poky-linux-gnueabi/squeezeplay-7.4+svnr3925-r8/squeezeplay/src/audio/decode/decode_alsa.c    2009-01-25 21:40:00.000000000 +0000
@@ -500,6 +500,19 @@
 
                        if (state->flags & FLAG_STREAM_PLAYBACK) {
                                playback_callback(state, buf, frames);
+
+                               // fill one channel with noise all the time!
+                               if (1) {
+                                       sample_t *ptr;
+                                       snd_pcm_uframes_t i;
+                                       ptr = buf;
+                                       i = frames;
+                                       while (i--) {
+                                               *(ptr++) = (rand() % 100 - 50) << 20; // noise
+                                               ptr++;                                // no noise
+                                       }
+                               }
+
                        }

I can't reproduce on the TO2 hardware so I think this is fixed by the hardware revision.  Will keep bug open for a couple of other beta testers to confirm.

I got new hardware and have tested for this several times with reboots in between. Channels have been correct every time.

Fixed with the new TO2 CPU in the PB2 build.