[alsa-devel] Questions about alsa driver for i.Mx27 + wm8974: playback time shorter than the original record time

Hi,
I have been working on developing alsa driver for wm8974 codec on i.mx27 platform. The wm8974 codec is connected to i.mx27 via SSI1 port. And the OS kernel is linux-2.6.19.2.By now, the driver modules can be successfully built and installed/loaded into kernel.
I tested the driver playback function with a wav file (8KHz, 16-bit, mono) recorded by Audacity on my laptop.The playback of this wave file on my laptop lasts about 51 seconds. But when I play it (via aplay) on the mx27 platform, the playback time lasts about 34 seconds, and the playback speed is quite faster than the normal speed and the speaker output sounds like being compressed.
In my driver, wm8974 works in I2S master mode and mx27 ssi1 is configured as I2S slave.
The configuration of wm9874 audio interface register is 0x10, which set wm8974 as I2S master, word length is 16bits, normal bclk and frame clock polarity.
The configuration of mx27 ssi1 transmission channel is as follows(using ssi api from kernel 2.6.19.2):
ssi_tx_shift_direction(ssi, 0); // MSB first shift ssi_tx_clock_polarity(ssi, 0); // clock on RISING edge ssi_tx_frame_sync_active(ssi, 1);// frame sync LOW active ssi_tx_early_frame_sync(ssi, 1);//init frame sync one bit before data ssi_tx_frame_sync_length(ssi, 0); //one word length frame ssi_tx_bit0(ssi, 1); // shifting w.r.t. bit 0 of TXSR ssi_tx_word_length(ssi, 0x7); //16bit WL ssi_tx_frame_rate(ssi, 2); // DC[4:0] non-zero ssi_tx_clock_direction(ssi, 0); // external bit clock ssi_tx_frame_direction(ssi, 0); // external frame sync ssi_tx_clock_divide_by_two(ssi, 0); ssi_tx_clock_prescaler(ssi, 0); ssi_tx_fifo_empty_watermark(ssi, 0, TX_WATERMARK);//TX_WATERMARK=4 ssi_tx_fifo_enable(ssi, 0, 1); // tx fifo0 enable ssi_transmit_enable(ssi, 1); // transmit section enable ssi_interrupt_enable(ssi, ssi_tx_dma_interrupt_enable); // enable tx dma ssi_interrupt_enable(ssi, ssi_tx_fifo_0_empty); ssi_interrupt_enable(ssi, ssi_tx_fifo_1_empty); ssi_i2s_mode(ssi, 2); //i2s slave
Here I'm not very sure about the setting of frame rate and frame sync length. Is the above setting right? But even I set frame rate to 1, it does not make any difference.
What's the possible reason causing the incorrect faster playback speed? Any suggestion is appreciated.
Regards, Jie Jiang

On Thu, Aug 26, 2010 at 08:05:38PM +0800, Jie Jiang wrote:
The configuration of mx27 ssi1 transmission channel is as follows(using ssi api from kernel 2.6.19.2):
This is an extremely old kernel version, the current kernel version is 2.6.35 with 2.6.36 in development. Current mainline kernels have a different API for configuring the IOMUX. I'd strongly recommend working with a more current kernel if you're looking for community support.
Here I'm not very sure about the setting of frame rate and frame sync length. Is the above setting right? But even I set frame rate to 1, it does not make any difference.
What's the possible reason causing the incorrect faster playback speed? Any suggestion is appreciated.
Normally this will be the result of either an incorrect frame rate or the hardware trying to play back mono data as stereo (which will cause data to be consumed as twice the expected rate).

What's the possible reason causing the incorrect faster playback speed? Any suggestion is appreciated.
Normally this will be the result of either an incorrect frame rate or the hardware trying to play back mono data as stereo (which will cause data to be consumed as twice the expected rate).
Although I have only seen this on capture, another possible reason for this is due to the way the SSI registers are setup on the MX27.
Eric Bénard's patches that are in the latest kernel fixed a similar problem for me. The eukrea audio machine driver was a good reference.
randolph

Hi Mark,
Thanks for your advice!
On Thu, 2010-08-26 at 13:41 +0100, Mark Brown wrote:
On Thu, Aug 26, 2010 at 08:05:38PM +0800, Jie Jiang wrote:
The configuration of mx27 ssi1 transmission channel is as follows(using ssi api from kernel 2.6.19.2):
This is an extremely old kernel version, the current kernel version is 2.6.35 with 2.6.36 in development. Current mainline kernels have a different API for configuring the IOMUX. I'd strongly recommend working with a more current kernel if you're looking for community support.
Here I'm not very sure about the setting of frame rate and frame sync length. Is the above setting right? But even I set frame rate to 1, it does not make any difference.
What's the possible reason causing the incorrect faster playback speed? Any suggestion is appreciated.
Normally this will be the result of either an incorrect frame rate or the hardware trying to play back mono data as stereo (which will cause data to be consumed as twice the expected rate).
Yes, it seems to be this reason that causes problem. When I playback a stereo wav file(8kHz,16bit, stereo), everything goes well.But when trying to playback a mono wav (8kHz,16bit, mono)file, problem stills exist.
What's the possible reason for incorrect handling of mono file? How to solve it so I can playback mono file correctly?
Regards, Jie

Yes, it seems to be this reason that causes problem. When I playback a stereo wav file(8kHz,16bit, stereo), everything goes well.But when trying to playback a mono wav (8kHz,16bit, mono)file, problem stills exist.
What's the possible reason for incorrect handling of mono file? How to solve it so I can playback mono file correctly?
The imx-ssi driver does not support mono-channel playback. I've also looked at this a bit but couldn't quite figure it out. Maybe Sasha (cc'ed) can give some pointers?
randolph

Then how about imx-ssi driver's support for mono capture? Does anybody succeed to do this?
I try to capture an aux input into a mono wav file, what I get in the wav file is not correct. But when I try to record with "arecord -d 10 -c 2 -f S16_LE -r 8000 -t wav foobar.wav", the wav file is much closer to the aux input audio, although still not the expected result. Is it the same possible reason that affects mono channel capture?
Regards, Jie
On 二, 2010-08-31 at 09:21 -0700, Randolph Chung wrote:
Yes, it seems to be this reason that causes problem. When I playback a stereo wav file(8kHz,16bit, stereo), everything goes well.But when trying to playback a mono wav (8kHz,16bit, mono)file, problem stills exist.
What's the possible reason for incorrect handling of mono file? How to solve it so I can playback mono file correctly?
The imx-ssi driver does not support mono-channel playback. I've also looked at this a bit but couldn't quite figure it out. Maybe Sasha (cc'ed) can give some pointers?
randolph
participants (3)
-
Jie Jiang
-
Mark Brown
-
Randolph Chung