[alsa-devel] [PATCH V1 11/11] ASoC: DaVinci: pcm, fix underruns by using sram

[Mark Brown]

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
unrelated functionality.

> > 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)?