From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Alexander <subaparts@yandex.ru>
Cc: alsa-devel@alsa-project.org, ryan@bluewatersys.com,
linux-arm-kernel@lists.infradead.org, lrg@slimlogic.co.uk
Subject: Re: [PATCH 1/3] ASoC: EP93xx I2S and PCM fixes
Date: Thu, 9 Dec 2010 10:54:43 +0000 [thread overview]
Message-ID: <20101209105443.GA4469@rakim.wolfsonmicro.main> (raw)
In-Reply-To: <1291855051.31916.85.camel@r60e>
On Thu, Dec 09, 2010 at 03:37:31AM +0300, Alexander wrote:
> > > - Formats list shortened to just S32_LE, this makes all the DMA transactions right,
> > > while ALSA will do all sample format translation for us.
> > Again, what was the actual problem? 32 bit samples seem very large if
> > the hardware is capable of other formats, especially given that things
> > like MP3 tend to produce 16 bit data.
> It seems that EP93xx DMA could only operate 32 bit words. So the I2S
> module is always feed by 32 bit samples. Incorrect setting of LRCLK (2
> times slower) in original ep93xx-i2s.c masks the problem. DMA takes two
> 16 bit samples instead of one, overall sound speed seems to be normal,
> but you get actually 4000 sampling rate instead of requested 8000 and
> therefore some noise... This is also the reason why the capture function
> not worked at all in this driver...
The approach taken by the original code (while it sounds like it still
has issues is a pretty standard way to deal with limitations in DMA
controllers like this. You often end up programming the DMA controller
to transfer 32 bit chunks and the I2S controller to transfer two 16 bit
samples then let the FIFOs on the edge of the I2S controller sort out
the difference. This means that the DMA controller transfers a stereo
pair of samples at a go, which works well enough. Some of the hardware
configuration may be technically incorrect according to the spec but so
long as the externally observable behaviour is OK that's not an issue.
It may be that there's limitations in the hardware that prevent such a
configuration but I'd like to see more analysis of what's going on here.
next prev parent reply other threads:[~2010-12-09 10:54 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-08 12:01 [PATCH 1/3] ASoC: EP93xx I2S and PCM fixes Alexander
2010-12-08 12:46 ` Mark Brown
2010-12-09 0:37 ` Alexander
2010-12-09 10:54 ` Mark Brown [this message]
2010-12-09 12:17 ` Alexander
2010-12-09 12:34 ` Mark Brown
2010-12-09 21:14 ` Alexander
2010-12-10 15:07 ` Mark Brown
2011-01-16 11:21 ` Alexander
2011-01-16 11:27 ` Mark Brown
2010-12-09 0:43 ` [PATCH] ASoC: EP93xx: sampling rate range extended Alexander
2010-12-09 10:07 ` Liam Girdwood
2010-12-09 11:10 ` Mark Brown
2010-12-09 0:59 ` [PATCH] ASoC: EP93xx: fixed LRCLK rate and DMA oper. in I2S code Alexander
2010-12-09 10:08 ` Liam Girdwood
2011-01-16 12:48 ` Alexander
2011-01-17 14:05 ` Liam Girdwood
2011-01-17 14:07 ` Mark Brown
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=20101209105443.GA4469@rakim.wolfsonmicro.main \
--to=broonie@opensource.wolfsonmicro.com \
--cc=alsa-devel@alsa-project.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=lrg@slimlogic.co.uk \
--cc=ryan@bluewatersys.com \
--cc=subaparts@yandex.ru \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).