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