Re: [LAD] PCM Troubleshooting Questions

On Mon, Nov 1, 2010 at 2:00 AM, Clemens Ladisch <clemens@email-addr-hidden> 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
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Wed Nov 3 08:15:02 2010