On Mon, Jun 08, 2009 at 02:26:32PM -0300, Daniel Ribeiro wrote: > Em Seg, 2009-06-08 ??s 17:53 +0100, Mark Brown escreveu: > > See my reply to Philip - even with frame size his case is going to be > > very hard to cover in a standard fashion since it's not clear what to do > I don't see why. If we provide an API to setup the frame size this is > all magician needs. That depends on what you do with the excess data in a frame - what magician needs to do is to set the frame clock up to run at double rate compared to standard one. Doing this by specifying the frame size means ignoring the rate of the incoming data rather than paying attention to the rate the data is supposed to have and therefore skipping the second channel but either of those two options would be a reasonable response. > If we assume that the standard is frame_size = sample_size * channels, > then there is no need for a frame size API at all. But then magician > case will not be supported correctly. Think about TDM mode for a minute here - there a separate configuration for the sample size on the wire opens the way to using a lower sample size in a given timeslot than the timeslot supports, reducing the need for the CPU to rewrite data. Or to put it another way, I can't see TDM mode working unless the sample size is constrained to always be exactly that desired so it seems sensible to have a standard way of doing that. > > Network mode is just a detail of the implementation of the PXA here - it > > should not be visible outside the pxa-ssp driver. Or to put it another > > way setting a tdm_slot of 1, 1 ought to result in the same behaviour as > > disabling TDM as far as the user is concerned. > But for pxa-ssp this is not the current behaviour. I think we can all agree that the current behaviour is fairly broken, it's kind of orphaned at the minute since nothing is using it. > > I'd like to see all these details handled within the driver - knowing if > > and when network mode are to be set up is the sort of thing that users > > ought to be able to rely on the driver for. > I can cook a patch.. All I need to know is: > Does it needs to support magician non-standard format? Or this will be > handled by userspace? I'd rather come up with a cleaner way of configuring the magician case that's explicit about what it's trying to achieve. It doesn't need to be in user space, though. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel