On Mon, Nov 1, 2010 at 2:00 AM, Clemens Ladisch <[email protected]> wrote: > Rory Filer wrote: > And what exactly did you change that made it stop working at all?
An excellent question and I still don't know the answer. I kept thinking I could make it just a little better with another tweak to the SSP registers and quickly lost track of all the changes. However, I've narrowed it down now (noted below) > To rule out most problems above the driver, use "aplay -D hw > something.wav" (where the wav file must have a format supported by > the hardware). It took me all day Monday to figure out how to cross compile this for my ARM platform and I even trashed my Ubuntu desktop in the process; that's how I learned what the "--prefix" switch on the "configure" program does, lol. Was a painful day, though. RTFM is perhaps the message here, becauseI only noticed the -D switch now. When I ran aplay on my target today it threw an error: "ALSA lib pcm.c:2143:(snd_pcm_open_noupdate) Unknown PCM default aplay: main:510: audio open error: No such file or directory " I looked at the code in question but the error doesn't mean anything to me yet. > > ALSA supports (and automatically converts between) both formats, but > practically every hardware uses interleaved samples, so this is what > practically every software produces. And digging through the code in squeezeslave a little more, I learned quite a bit. The miniMAD decoder is writing alternate left and right channel data into the output buffer. It was cool to discover this and I was looking in the wrong place before I wrote my original post. > > Nobody in their right mind uses right-justified, because this format > must also be configured for the right sample bit width. (But then I > don't know how many hardware designers actually are in their right > mind.) Lol Thanks to Clemens and Patrick for your prompt replies. I spent yesterday and today trying to narrow down the problem using your suggestions and as noted above, aplay doesn't run for me, but I'll try it with the -D switch tomorrow. However, I did have a major breakthrough today. I used a decent scope to capture the Sync, Clock and Data lines and temporarily hacked squeezeslave; where it writes decoded data into the final output buffer I changed it to write different recognizable constant values into the left and right channels and then checked the scope. The data is correct in polarity, bit order and value and the Normal I2S mode appears to be correctly formatted correct too. This seems to eliminate the whole of my Linux installation - although still no audio from the FM receiver. I'll focus my attention on that downstream device now. Best Regards Rory _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
