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)? _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
