Timur Tabi wrote:

lokowich wrote:

...

I'm integrating a ALSA driver for an MPC5200 into the ASoC layer, similar to my successful effort for a PXA255 board.

Can you provide your code? I'm working on ASoC support for another MPC SOC, so we need to synchronize our development.

Yes, I presume you mean using git into the ALSA branch. I need to get more familiar with git, and follow the appropriate coding conventions before it's ready. Any guidance will be appreciated.

I'm modeling the DMA and ALSA interfaces per ac97mgt driver found in the Lite5200B BSP, rather than the BestComm API example in the 2.4 kernel. The speaker-test with 400Hz sine wave is working, but has a slight audible jitter. A wav file output using aplay produces white noise.

What kind of audio samples are you trying to play? Since the MPC5200 is typically big-endian, you probably can only play S16_BE samples instead of S16_LE samples.

Yes! I had enabled the S16_BE format in my codec/i2s/pcm driver, but naively thought ALSA would handle the rest. Converted my test file to S16_BE and it sounds much closer to the original. Thanks! Found the "jitter" is due to a FIFO overflow. I'm using same alarm (0x120) and granularity (4) common to 2.4 I2S and ac97 drivers. Is there a more appropriate setting for 16-bit, 2-channel, 44.1kHz audio?

Also, can we chat about SDRAM problems on 5200B outside of this forum?

This email was Anti Virus checked by Astaro Security Gateway. http://www.astaro.com

lokowich wrote:

Yes, I presume you mean using git into the ALSA branch.  I need to
get more familiar with git, and follow the appropriate coding
conventions before it's ready.  Any guidance will be appreciated.

No, I meant that your code and my code will probably need to merge, so we need to compare the code to take advantage of any commonality.

However, after looking at the 5200 manual, it appears there's not really a whole lot in common after all. Still, I'd like to provide some input to your code once I see it.

Yes!  I had enabled the S16_BE format in my codec/i2s/pcm driver,
but naively thought ALSA would handle the rest.

Well, ALSA has plug-ins for sample rate and size, but I don't think it has one for endianness. I'm not really sure. Besides, if you use "aplay -Dhw:0,0", you are bypassing all ALSA plug-ins.

Converted my test file to S16_BE and it sounds much closer to the original. Thanks!

You're welcome. The reason why it sounded garbage is because when you write a little-endian sample to the shift register, it bit order is this:

07-06-05-04-03-02-01-00 15-14-13-12-11-10-09-08

The bytes may be little-endian, but the bits are big-endian.

Found the "jitter" is due to a FIFO overflow.  

That makes sense.

I'm using same alarm (0x120) and granularity (4) common to 2.4 I2S and ac97 drivers. Is there a more appropriate setting for 16-bit, 2-channel, 44.1kHz audio?

I don't know enough about the 5200 to say. The I2S hardware I'm using looks like it's much more complicated than what's on the 5200.

Also, can we chat about SDRAM problems on 5200B outside of this forum?

I know nothing about the 5200, so you'll have to ask someone else about SDRAM.

lokowich wrote:

Are we stopping further MPC52xx development in ppc?

Yes. Everyone should be using arch/powerpc if they can.