[alsa-devel] trouble with alsa, wolfson, and TI OMAP35xx McBSP
I'm having difficulties getting a Wolfson codec running on McBSP1 of an OMAP 35xx. Here are the particulars:
1) Using Linux kernel 2.6.27-omap1, with an ALSA sound driver ported from a Wolfson supplied source tree labeled 2.6.29 (“dev” branch) 2) Using the TI OMAP3530 SOC married to a Wolfson WM8978 codec via McBSP1. I2C control, I2S pcm data. 3) We are running the codec digital block at 1.8V and the analog block at 3.3V 4) The WM8978 codec is synthesizing FCLK and BCLK, codec is the master. McBsp is the slave. 5) FCLK=44.1KHz, BCLK= 32 * FCLK, MCLK = 13Mhz 6) Framing is I2S stereo, 16 bit word
I'm seeing two main problems:
Problem 1: The WM8978 sample rate PLL does not seem to be stable while DCVDD = DBVDD = 1.8V. FCLK mean = 44.5KHz and jittering. Increasing DCVDD and DBVDD voltage above 2V increases PLL stability. We have a workaround for this for now.
Problem 2: Test tone is being presented by the user application, providing a 1Khz tone sampled at 44.1Khz. The data are S16_LE, right channel only. Left channel is quiet. The data seems to slip back and forth from left to right channel. This is reproducable and verified with a scope trace.
Anybody have any ideas what might be going wrong here? Traces for codec reg dump and mcbsp are attached.
Thanks, twebb
-----Original Message----- From: linux-omap-owner@vger.kernel.org [mailto:linux-omap- owner@vger.kernel.org] On Behalf Of twebb Sent: Wednesday, April 22, 2009 12:58 PM
Problem 2: Test tone is being presented by the user application, providing a 1Khz tone sampled at 44.1Khz. The data are S16_LE, right channel only. Left channel is quiet. The data seems to slip back and forth from left to right channel. This is reproducable and verified with a scope trace.
I recollect this issue from years back of OSS driver -> i2s is configured as dual phase - mcbsp sends data on both edges, and if the data write happen on the wrong edge for the wrong phase, we might get mix up.. if I recollect right, configuration for mcbsp was done as a single phase with the right edge as a trigger for transfer, the transfer size was set as 32 bytes (both channels).. this essentially guarentees that mcbsp will never mix up channels.
Regards, Nishanth Menon
On Wed, 22 Apr 2009 20:05:40 +0200 "ext Menon, Nishanth" nm@ti.com wrote:
Test tone is being presented by the user application, providing a 1Khz tone sampled at 44.1Khz. The data are S16_LE, right channel only. Left channel is quiet. The data seems to slip back and forth from left to right channel. This is reproducable and verified with a scope trace.
Is this slipping happening in middle of playback or between the tracks?
I recollect this issue from years back of OSS driver -> i2s is configured as dual phase - mcbsp sends data on both edges, and if the data write happen on the wrong edge for the wrong phase, we might get mix up.. if I recollect right, configuration for mcbsp was done as a single phase with the right edge as a trigger for transfer, the transfer size was set as 32 bytes (both channels).. this essentially guarentees that mcbsp will never mix up channels.
Thanks Menon! This is sounds a information we should try out. OMAP2420 in N810 is especially suffering from channel swapping between the tracks and I haven't found time to look any deeper :-(
I know there is a fix for DaVinci (commit fb0ef645f2c546f8297b2fbf9b2b8fff4a7455e8) but I would like to find out are there any other or simpler way to fix it than mixing DMA and DAI setup.
Jarkko
On Wed, Apr 22, 2009 at 01:58:01PM -0400, twebb wrote:
Problem 1: The WM8978 sample rate PLL does not seem to be stable while DCVDD = DBVDD = 1.8V. FCLK mean = 44.5KHz and jittering. Increasing DCVDD and DBVDD voltage above 2V increases PLL stability. We have a workaround for this for now.
Can I suggest that you contact Wolfson's applications support team regarding this issue - there's a web form at:
http://www.wolfsonmicro.com/support/technical/
Looking at the datasheet the PLL is specified as requiring a minimum of 1.9V - see page 6 of:
http://www.wolfsonmicro.com/uploads/documents/en/WM8978_Rev4.3.pdf
Problem 2: Test tone is being presented by the user application, providing a 1Khz tone sampled at 44.1Khz. The data are S16_LE, right channel only. Left channel is quiet. The data seems to slip back and forth from left to right channel. This is reproducable and verified with a scope trace.
Anybody have any ideas what might be going wrong here? Traces for codec reg dump and mcbsp are attached.
There have been some recent threads on this list regarding the configuration of the McBSP port configuration for various formats - it's probably worth checking the latest changes to the OMAP code in the topic/asoc branch of:
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git
That said, I2S with the CODEC as clock master is one of the most common configurations for OMAP so I'd expect it to be well tested. Have you tried testing recording?
Also CCing in Peter and Jarkko, our resident OMAP audio experts.
On Wednesday 22 April 2009 20:58:01 ext twebb wrote:
Problem 2: Test tone is being presented by the user application, providing a 1Khz tone sampled at 44.1Khz. The data are S16_LE, right channel only. Left channel is quiet. The data seems to slip back and forth from left to right channel. This is reproducable and verified with a scope trace.
Anybody have any ideas what might be going wrong here? Traces for codec reg dump and mcbsp are attached.
As Jarkko already asked: are you seeing the channel switch while running or is it happens on playback start?
AFAIK this phenomena can be also seen on Beagle board.
I have done some investigation regarding to these, but so far I can not say that I know what causes it.
BTW: these are separate issues (startup switch and runtime switch).
Thanks, twebb
On Thursday 23 April 2009 10:20, Peter Ujfalusi wrote:
On Wednesday 22 April 2009 20:58:01 ext twebb wrote:
Problem 2: Test tone is being presented by the user application, providing a 1Khz tone sampled at 44.1Khz. The data are S16_LE, right channel only. Left channel is quiet. The data seems to slip back and forth from left to right channel. This is reproducable and verified with a scope trace.
Anybody have any ideas what might be going wrong here? Traces for codec reg dump and mcbsp are attached.
As Jarkko already asked: are you seeing the channel switch while running or is it happens on playback start?
AFAIK this phenomena can be also seen on Beagle board.
I have done some investigation regarding to these, but so far I can not say that I know what causes it.
BTW: these are separate issues (startup switch and runtime switch).
I just want to declare an interest in this investigation. Many months back I was working on a SAM9260 board with wm8731 codec; the project is rather 'background' at present. One of the outstanding unresolved (not really investigated much either) issues was of channel swapping at start of capture or playback. It never changed during operation, but each start time the channels would be randomly correct or swapped.
Does this indicate that the implementation/drivers of i2s has a fundamental ambiguity? Is it not rigidly defined which channel should follow a rising edge of L/R clock?
Alan
On Thu, Apr 23, 2009 at 12:04:05PM +0100, Alan Horstmann wrote:
Does this indicate that the implementation/drivers of i2s has a fundamental ambiguity? Is it not rigidly defined which channel should follow a rising edge of L/R clock?
It's clearly defined to be that the left channel follows the falling edge of LRCLK (ie, the left channel data is transmitted while LRCLK is low). However, not all CPUs do a wonderful job of implementing this - some of the older Samsung chips need a workaround for synchronisation, for example.
On Thursday 23 April 2009 14:04:05 ext Alan Horstmann wrote:
On Thursday 23 April 2009 10:20, Peter Ujfalusi wrote:
On Wednesday 22 April 2009 20:58:01 ext twebb wrote:
Problem 2: Test tone is being presented by the user application, providing a 1Khz tone sampled at 44.1Khz. The data are S16_LE, right channel only. Left channel is quiet. The data seems to slip back and forth from left to right channel. This is reproducable and verified with a scope trace.
Anybody have any ideas what might be going wrong here? Traces for codec reg dump and mcbsp are attached.
As Jarkko already asked: are you seeing the channel switch while running or is it happens on playback start?
AFAIK this phenomena can be also seen on Beagle board.
I have done some investigation regarding to these, but so far I can not say that I know what causes it.
BTW: these are separate issues (startup switch and runtime switch).
I just want to declare an interest in this investigation. Many months back I was working on a SAM9260 board with wm8731 codec; the project is rather 'background' at present. One of the outstanding unresolved (not really investigated much either) issues was of channel swapping at start of capture or playback. It never changed during operation, but each start time the channels would be randomly correct or swapped.
So in case of OMAP35XX, when the switch happens?
I have a theory, which needs to be checked for the startup switch in OMAP: I think what is happening, that the McBSP module got enabled earlier then the DMA is started. This leads to and underrun situation in McBSP (no data in the buffer), so McBSP will transmit _something_ when the start condition for the I2S is met. When the DMA starting to push data to McBSP, than valid data will be shifted out. McBSP is shifting word by word manner. So if the first word transmit need to be done, when the buffer is empty, it starts to shift the word, than the data arrives from the DMA, the next word will be valid data -> you will have a nice channel switch.
Is this makes sense?
Does this indicate that the implementation/drivers of i2s has a fundamental ambiguity? Is it not rigidly defined which channel should follow a rising edge of L/R clock?
Alan
On Thu, Apr 23, 2009 at 02:52:24PM +0300, Peter Ujfalusi wrote:
I have a theory, which needs to be checked for the startup switch in OMAP: I think what is happening, that the McBSP module got enabled earlier then the DMA is started. This leads to and underrun situation in McBSP (no data in the buffer), so McBSP will transmit _something_ when the start condition for the I2S is met. When the DMA starting to push data to McBSP, than valid data will be shifted out. McBSP is shifting word by word manner. So if the first word transmit need to be done, when the buffer is empty, it starts to shift the word, than the data arrives from the DMA, the next word will be valid data -> you will have a nice channel switch.
Is this makes sense?
Sounds entirely plausible to me.
Hi everyone.
We are working with bringing up another audio codec with the Beagle Board.
Probably the issue we are seeing is related: we are having problems when doing playback and observe that the information corresponding to 2 channels is being sent only through the left channel. We might have some other problems too, since we are new to this kind of development, but maybe our observations or yours could be useful to stabilize the Beagle platform code.
Best regards,
Alex B.
On Thu, Apr 23, 2009 at 4:20 AM, Peter Ujfalusi peter.ujfalusi@nokia.com wrote:
On Wednesday 22 April 2009 20:58:01 ext twebb wrote:
Problem 2: Test tone is being presented by the user application, providing a 1Khz tone sampled at 44.1Khz. The data are S16_LE, right channel only. Left channel is quiet. The data seems to slip back and forth from left to right channel. This is reproducable and verified with a scope trace.
Anybody have any ideas what might be going wrong here? Traces for codec reg dump and mcbsp are attached.
As Jarkko already asked: are you seeing the channel switch while running or is it happens on playback start?
AFAIK this phenomena can be also seen on Beagle board.
I have done some investigation regarding to these, but so far I can not say that I know what causes it.
BTW: these are separate issues (startup switch and runtime switch).
Thanks, twebb
-- Péter -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Apr 23, 2009 at 11:50:25AM -0500, Alejandro Blanca G. wrote:
Probably the issue we are seeing is related: we are having problems when doing playback and observe that the information corresponding to 2 channels is being sent only through the left channel. We might have some other problems too, since we are new to this kind of development, but maybe our observations or yours could be useful to stabilize the Beagle platform code.
Please check out the current ASoC branch - as previously mentioned there has been quite a bit of work recently on the McBSP audio formatting:
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6
On Thu, Apr 23, 2009 at 2:20 AM, Peter Ujfalusi peter.ujfalusi@nokia.comwrote:
On Wednesday 22 April 2009 20:58:01 ext twebb wrote:
Problem 2: Test tone is being presented by the user application, providing a 1Khz tone sampled at 44.1Khz. The data are S16_LE, right channel only. Left channel is quiet. The data seems to slip back and forth from left to right channel. This is reproducable and verified with a scope trace.
Anybody have any ideas what might be going wrong here? Traces for codec reg dump and mcbsp are attached.
As Jarkko already asked: are you seeing the channel switch while running or is it happens on playback start?
AFAIK this phenomena can be also seen on Beagle board.
I have done some investigation regarding to these, but so far I can not say that I know what causes it.
BTW: these are separate issues (startup switch and runtime switch).
I have seen the startup switch happening and I investigated it a bit. The XDISABLE bit solution discussed on the list earlier did not solve the problem fully, additionally I needed to add check for the FIFO state before clearing XDISABLE.
Simplified:
1. Set XDISABLE bit 2. Start DMA 3. Start serial port. 4. Wait for the DMA to put data into McBSP FIFO (there is status you can poll for this) 5. Clear XDISABLE bit.
I found that without step #4 the FIFO would sometimes be empty on step #5 and switching happened because first word sent was bogus and second was the first audio word.
This was on OMAP2430.
- Juha
participants (9)
-
Alan Horstmann -
Alejandro Blanca G. -
Jarkko Nikula -
Juha Kuikka -
Mark Brown -
Mark Brown -
Menon, Nishanth -
Peter Ujfalusi -
twebb