On Tue, 2010-10-19 at 17:48 -0500, pl bossart wrote: > >> As this is used to transfer speech frames from/to cellular modem that have specific timing constraints (and modem also uses the I2S path to send some side-info), the Alsa SoC interface cannot be used. > > > > What makes you say this? You have provided no detail on what problems > > you believe exist and since ASoC is a *very* thin wrapper around the > > core ALSA for DMA stuff it is very surprising that you would see any > > issues here that don't also affect plain ALSA. If there are any issues > > then it would seem better to resolve these within the current framework > > rather than completely discarding the entire existing infrastructure. > > Louis meant ALSA rather than ASOC. We use burst transfers to reduce > round-trip delay, the whole notion of periods/period elapsed/ring > buffer doesn't make sense here and there is in-band signalling that > should not be interpreted as samples. If ALSA had a simplified API for > byte streams sent over a serial output, we would have no problems > using it and of course ASOC would be used then. Is the inband signaling here done in software ? I'd expect this to be multiplexed in the DAI by the hardware leaving the software to send PCM bursts to the CODEC/MODEM/whatever like Peter's DAC33 driver. Liam -- Freelance Developer, SlimLogic Ltd ASoC and Voltage Regulator Maintainer. http://www.slimlogic.co.uk _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel