From: Peter Ujfalusi <peter.ujfalusi@ti.com>
To: Steve Calfee <stevecalfee@gmail.com>
Cc: Jarkko Nikula <jhnikula@gmail.com>,
"Premi, Sanjeev" <premi@ti.com>,
"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
"Girdwood, Liam" <lrg@ti.com>,
Peter Hsiang <cdefgab1288@gmail.com>
Subject: Re: beagleboardxm 2.6.39rc4 mcbsp problems.
Date: Fri, 20 May 2011 09:56:56 +0300 [thread overview]
Message-ID: <201105200956.56507.peter.ujfalusi@ti.com> (raw)
In-Reply-To: <4DD5AEA6.6020907@gmail.com>
On Friday 20 May 2011 02:58:30 Steve Calfee wrote:
> On 05/19/11 04:28, Peter Ujfalusi wrote:
> Correct, I can set bit clock to 64*lrclk, 48*lrclk, 128*lrclk, 17*lrclk,
> and 18*lrclk.
Strange, that there is no option for 32*lrclk.
> The audio folks here think that it is normal to send more
> than required bit clocks, data is sent first so just ignore the rest.
Yes, it is allowed. The rest should be ignored.
But I'm afraid, OMAP McBSP can not handle this in a way you (and me) wanted
to.
> It would appear that the mcbsp doesn't really use the lrclk (I think
> called FSX), it just uses a positive transition to start the bit
> shifting for all the requested bits. The falling edge does not start the
> right channel, the shifter keeps going until all requested l/r counts
> have been sent.
Yeah, McBSP only cares about the start condition, it does not care about the
right channel FSX transition.
This is the reason it is not possible to handle the scenario you are aiming
for.
At start condition, it just start to send the data stream (frame1 followed by
frame2 in dual-phase mode - in single phase mode it can send up to 128
frames).
Having said that, there might be a way to actually work this around with
McBSP's multichannel mode. Configuring it for 4 slots, and only shift data for
slot 0, and 2 in case of your setup (16bit data within 32 bitclocks).
It is a long shot, I can not promise that I can take a look right away, but if
you have time.... ;)
> > You should have full stereo sound now.
>
> I do, thanks.
Cool :D
> I am truly amazed that I was able to follow your
> instructions and get it to work first time. You must really know your
> alsa machine implementation.
Thanks, I try.
> The problem is that now I cannot run 44.1Khz audio, I get underruns. I
> am guessing that software is expanding the samples from 16 bits to 32?
> Without your hack 44.1Khz audio works fine (but only audible in the
> first channel).
Hmm. I have used similar mode with twl4030, and tlv320dac33 (S32_LE with
24msbits) without issues with underrun. Let's see.
Can you check /sys/devices/platform/omap-mcbsp.X/dma_op_mode, max_tx_thres for
your McBSP port?
I would suggest to switch the dma_op_mode to threshold mode in any port.
When you play audio try to use bigger periods, something like 10ms:
aplay -Dplughw:0,0 --period-time=10000 -v <your sample>
Replace the -Dplughw:0,0 to point to the wm98095 PCM.
Could you post the output of aplay?
> I talk to Peter every day. He brought up the codec, I am trying to use
> the Beagleboardxm as a generic Linux platform for new codec bringups and
> for following kernel and alsa cutting edge software.
Make sense..
--
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
next prev parent reply other threads:[~2011-05-20 6:56 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-11 13:55 [PATCH] ASoC: omap-mcbsp: Remove restrictive checks for cpu type Sanjeev Premi
2011-05-11 13:55 ` Sanjeev Premi
2011-05-11 13:57 ` Mark Brown
2011-05-11 13:57 ` Mark Brown
2011-05-11 14:44 ` Peter Ujfalusi
2011-05-11 14:44 ` [alsa-devel] " Peter Ujfalusi
2011-05-11 15:38 ` Jarkko Nikula
2011-05-11 15:38 ` Jarkko Nikula
2011-05-11 18:16 ` [alsa-devel] " Steve Calfee
2011-05-11 19:19 ` Premi, Sanjeev
2011-05-11 21:31 ` beagleboardxm 2.6.39rc4 mcbsp problems Steve Calfee
2011-05-12 6:25 ` Jarkko Nikula
2011-05-12 11:01 ` Peter Ujfalusi
2011-05-12 18:43 ` Steve Calfee
2011-05-13 5:59 ` Peter Ujfalusi
2011-05-14 2:47 ` Steve Calfee
2011-05-16 8:54 ` Peter Ujfalusi
2011-05-16 18:07 ` Steve Calfee
2011-05-17 6:37 ` Jarkko Nikula
2011-05-19 1:06 ` Steve Calfee
2011-05-20 0:58 ` Steve Calfee
2011-05-20 6:29 ` Jarkko Nikula
2011-05-20 7:03 ` Peter Ujfalusi
2011-05-21 0:55 ` Steve Calfee
2011-05-17 10:42 ` Peter Ujfalusi
2011-05-19 0:30 ` Steve Calfee
2011-05-19 11:28 ` Peter Ujfalusi
2011-05-19 23:58 ` Steve Calfee
2011-05-20 6:56 ` Peter Ujfalusi [this message]
2011-05-13 12:13 ` [PATCH] ASoC: omap-mcbsp: Remove restrictive checks for cpu type Liam Girdwood
2011-05-13 12:13 ` Liam Girdwood
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201105200956.56507.peter.ujfalusi@ti.com \
--to=peter.ujfalusi@ti.com \
--cc=cdefgab1288@gmail.com \
--cc=jhnikula@gmail.com \
--cc=linux-omap@vger.kernel.org \
--cc=lrg@ti.com \
--cc=premi@ti.com \
--cc=stevecalfee@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.