I just don't think it is a hardware problem. I a polling ssc driver that works very nicely for this codec. However, it is polling and I do not want to rely on it when I have more of a load on the processor. I have the machine/codec code and at91-ssc.c configured so that the registers and gpio should be set up identical to what I had before and it is not generating a proper sync signal with arecord. When I do strace on arecord it hangs at this first line before finishing. ioctl(4, 0x800c4151, 0xbed9cc34) = -1 EIO (Input/output error) write(2, "arecord", 7arecord) = 7 write(2, ": ", 2: ) = 2 write(2, "pcm_read", 8pcm_read) = 8 write(2, ":", 1:) = 1 write(2, "1346", 41346) = 4 write(2, ": ", 2: ) = 2 write(2, "read error: ", 12read error: ) = 12 write(2, "Input/output error", 18Input/output error) = 18 write(2, "\n", 1 ) = 1 exit(1) = ? Does anyone know what this line is doing? I think it might give a clue. The sync line still ripples at about .3V peak to peak with f=256k (Bit Clock Rate). Frank: I modified the machine code so that RF0 and RK0 are set in the gpio. The only differences are that the sync line no longer tri-states after going trying to record and instead of seeing the ripple around 3V it is now around 200 mV. Has anyone seen this behavior before? Paul _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
