[alsa-devel] [PATCH V1 11/11] ASoC: DaVinci: pcm, fix underruns by using sram
broonie at opensource.wolfsonmicro.com
Tue Jul 7 11:31:32 CEST 2009
On Mon, Jul 06, 2009 at 06:10:25PM -0700, Troy Kisky wrote:
> Mark Brown wrote:
> > that causes issues in situations like TDM since there
> > can be transfers going on independantly of the CPU which may need the
> > clocks running. Not everything will be able to gate the clocks, too.
> What is TDM? time division multiplexing? You mean the frame carries
> more than just audio data? I think I'm misunderstanding something.
> Can you elaborate please.
Yes, time division multiplexing. The extra signals could be non-audio
or they could be audio. For example, you could have the CPU, CODEC and
a bluetooth chip connected to a single bus. In such a scenario you
could have audio going directly between bluetooth and the CODEC with no
CPU involvement (allowing the CPU to suspend itself during a call).
That's not the only case - sometimes people do other things that need
the clocks running even when audio is off like sharing them with some
> > Is it perhaps saner to just look at the current position as being the
> > position of the transfer to SRAM? This does mean more variation from
> > the point at which data is audibly playing but on the other hand as far
> Hmm. Good point. I just wanted as accurate lip-sync as possible.
Yeah, it's tricky to know what's best.
> > battery life by setting up very big DMAs. On a similar vein is it worth
> > considering making this feature entirely optional and/or falling back to
> > non-SRAM if SRAM allocation fails?
> Yes Chris Ring also asked for that, and it is fairly easy to allocate another
> SDRAM buffer to use for the SRAM. But I'd rather another patch after this
Incremental patches sounds fine to me.
> if I need to use plaform data. Maybe audio_sram_buffer_size = 0 in platform
> data to mean use SDRAM?
The only potential problem I see there is that that'd make disabling the
SDRAM the default. I guess if people have been living without it so far
that's not a big problem, though, and it'll stop people getting surprised
by audio grabbing SDRAM when they weren't expecting it.
I guess if you're using SDRAM there's no need for the double buffering
(though that could be a third patch)?
More information about the Alsa-devel