[LAD] PCM Troubleshooting Questions

Rory Filer rflyer at gmail.com
Sun Oct 31 19:51:00 UTC 2010


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 ...

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.



More information about the Linux-audio-dev mailing list