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.