_Hardware/Software Platform_

* Custom Hardware based on Freescale i.MX28EVK platform * Original Codec Freescale SGTL5000 on Freescale i.MX28EVK platform * Ported a Codec Texas Instruments PCM1681 * Embedded Linux using Freescale LTIB 2013 (linux kernel 2.6.35.3) distribution

_Good News_

I have the I2S clocks verified with digital scope on the hardware for the desired 256 * fs, 64 * fs, and fs.

_Bad News_

Audio when played out with aplay and a 44.1 kHz S16_LE Stereo file plays out too fast (guesstimating about 3 times too fast).

_Due Diligence_

I've been digging through the linux kernel code to figure out why my driver is passing the incorrect fs (sample rate) up to the linux kernel alsa subsystem between aplay and my pcm1681 device driver. I've forced the driver to only run 44.1kHz (which shows up everwhere from my kernel debug printk) and that is what is showing up with a scope on the hardware fs clock with a digital scope but ... between aplay and the driver, there is a perception of a lower sample rate needed, therefore there is a rate reduction of the sample sequence which makes the audio clip play faster out on the audio port.

I've been digging through the code and trying different things for a few days now and I have not made any progress.

_Help/Advice/Understanding Needed_

What I need to understand is how from aplay down through the alsa layer in the kernel the sample rate is set down to the driver layer ... and in the reverse direction.

Of course the kernel is patched by Freescale so I'm not exactly sure how to ask for help on this but perhaps there is a way to get some ideas from the aplay (userspace layer) down through the alsa kernel layer that I can look at that might downsample the audio file before it gets to the driver.

Using

alsa-lib-1.0.24.1 alsa-utils-1.0.24.2

My idea is to approach debug from the userspace down versus the driver porting which was from the lowest level (driver layer) and up. That is why I'm posting on alsa-devel as I think that this is where I need to focus where the sample rate misconception is and thereby where the downsampling is occurring which is either in userspace (alsa-lib) code or possibly alsa layer kernel code.

Looking to leverage some alsa knowledge and expertise.