Hi, On Tue, Mar 12, 2019 at 03:03:00PM +0000, Mark Brown wrote: > On Mon, Mar 11, 2019 at 04:43:39PM +0100, Jaroslav Kysela wrote: > > > I would not use any of the "user space" ioctl API to represent the > > hardware bclk requirements. The applications should know just the DMA > > memory layout. > > > Also, think about the multiple simultaneous paths for the audio output > > in the sound controller (so one DMA from the user space to the > > controller, but the controller can do multiple simultaneous outputs > > using different clocks combining different wire buses or so). Yes, it's > > the corner case, but it's another reason to have the bclk code totally > > separated from the user space ALSA's PCM API. > > There's also a range of devices that either don't have visible buses at > all due to integration or which are on buses that look nothing like the > I2S/DSP mode style of bus, rendering the parameters meaningless. Indeed. That's resonable to add no changes to ALSA PCM interface. When suggesting usage of 'rate_num' and 'rate_den', I assumed to change ALSA SoC part internal to have constraints and rules for them, with no changes of ALSA PCM inteface itself. I agree that the dicision of on-wire format should not be exposed to userspace as well. [1] https://mailman.alsa-project.org/pipermail/alsa-devel/2019-March/146261.html Thanks Takashi Sakamoto _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
