Hello, For most of the last week I've been stuck trying to configure my silicon peripheral to generate Normal I2S audio data to mostly _bad_, results and had a couple of questions (below). Briefly, my setup is as follows: SqueezeServer on a Windows host PC, Squeezeslave on my embedded Linux device sending audio samples through the kernel (2.6.28) down to my driver which lives in sound/soc/pxa.I've been trying to configure my device for I2S format. Outside the CPU, the I2S-formatted PCM data is sent to an external FM transmitter chip so I should be able to hear the audio on my FM receiver. Since the only "new" stuff here is my driver and the output hardware, I've been focussing my attention on them until now, but haven't had much success hearing anything. I've actually heard _some_ recognizable audio - I could tell it was the song I had selected, but it sounded very distorted (sounded horrible) and I'm certain it wasn't because of a weak FM transmitter signal. I'm guessing it was a mismatch in the formatting of the I2S data between what I was sending and what the FM Tx chip was expecting and that has formed the basis of my troubleshooting effort. I've run out of ideas for things to try at the bottom end and now I want to make sure my top-end components are working properly. This is weird because I've stopped being able to hear anything lately, but a scope confirms my I2S lines are all lit up. Here are a couple of questions... 1) The CPU supports a packed mode write to the Synchronous Serial Port (SSP) FIFO, meaning that two 16 bit samples (one left channel and one right) can be written at the same time, both being packed into a single 32 bit FIFO write. My driver enables this mode, but my question is, where in the kernel would the samples be combined into a 32 bit chunk for writing? I'm using Squeezeslave on my embedded device as the player and I've checked the sources and it doesn't look like it's happening in there. Makes more sense to be somewhere further down in the stack so players don't have to care about the details of the hardware they are running on. I was wondering if anyone knew where this packing might take place. 2) Are their any useful tools out there for debugging/narrowing down where problems in the audio path might lie? My player is an embedded platform and I've only ported Squeezeslave to it, but for all I know there could be a problem anywhere from SqueezeServer, through Squeezeslave, down into the stack, my PCM driver or even the FM transmitter. To eliminate the latter as a problem I'm looking for another device that spits out known good I2S audio and I'll feed that into the FM Tx and hopefully eliminate that. But there's a lot of code from the SSP back and it would be great if I had some simple tone generator application (for instance) that was easily portable to an ARM9 platform (kernel 2.6.28) that I knew was sending correct data down the stack. 3) My experience with Linux and audio is just beginning and so far it's been right down at the driver level, so a question about audio playing software: when a player produces a PCM stream from, say, an MP3 file, does it automatically interleave the left channel and right channel or does it produce two separate streams, one for left and one for right? I can't tell from reading the Squeezeslave code, but it looks like the audio data is sent in one continuous stream, so ... interleaved? 4) For those of you experienced with I2S and other PCM formats, what would a Normal I2S stream sound like on a DAC that thought it was receiving Justified I2S? Would the audio still be intelligible or would you hear nothing at all? Thanks to all who read this post. Cheers, Rory