[alsa-devel] [PATCH 1/4] ASoC: pxa-ssp: enhance I2S and add Left_J support
broonie at opensource.wolfsonmicro.com
Mon Jun 8 19:41:50 CEST 2009
On Mon, Jun 08, 2009 at 07:18:16PM +0200, pHilipp Zabel wrote:
> On Mon, Jun 8, 2009 at 6:38 PM, Mark
> Which makes me wonder, whether it wouldn't generally be more accurate
> to calculate the DMA transfer size as ssp_framewidth *
> number_of_active_slots. Decreasing the DMA transfer size instead of
> throwing away half the data (whether it is due to misconfiguration or
> due to a strange special case like mine) should be a sane default?
Yeah, it's kind of random and depends on what the effect you're trying
to achieve is - do you want to preserve the data or the sample rate?
Neither is immediately obviously the correct thing in the general case.
> > It occurs to me that this is something that it might be better to work
> > around this with a user space plugin which rewrites the sample formats
> Please, don't do this to me :)
> As it works the way it is now, I don't see how moving this to
> userspace improves things (except that you'd get rid of the two code
> lines quoted above).
It's not so much the move to user space as the bit where we're able to
say to the CPU driver "treat this data as a mono stream rather than
stereo" which makes the problem a whole lot easier, I think? At the
minute user space is the only place that has hooks to do that.
I'll have a think about this and see if I can come up with a clean way
of doing that in kernel.
> >> ? ? set_tdm_slot(1,1);
> >> especially as I don't really need network mode at all.
> > Same issue with "it's a surprise it works" applies here.
> See above, reducing the DMA transfer size works as expected.
Yeah, I'm thinking in terms of the generic interface rather than the
behaviour of the specific hardware - I'd expect something doing I2S
natively would be more likely to fail the other way.
More information about the Alsa-devel