On 04/12/2013 06:37 PM, Stas Sergeev wrote:
On Fri, 12 Apr 2013 17:31:19 +0200 Lars-Peter Clausen lars@metafoo.de wrote:
Well, if not explicitly initialized a field is set to 0. Which is kind of the most restrictive option for many of the fields. E.g. channels_max, rates, formats, etc. When the ASoC core creates a new PCM device it will take the intersection of the CPU DAI and CODEC DAI fields to initialize the fields the PCM. So if for example channels_max is 0 for the CODEC DAI, channels_max will also be 0 for the PCM, no matter what channels_max is set to for the CPU DAI. Same goes for formats and rates. So a dummy CODEC should have set its fields in a way that it is most permissive, so that the intersection of the CODEC DAI fields with the CPU DAI fields will be equal to the CPU DAI fields.
Thanks for an explanation! But what happens when the DAI is considered mute by the effect of such intersection? From what I can see, no callbacks from the DAI driver are called in this case (this is expected), but no error is returned to userspace, and, more importantly, the playback speed is still correct, so the userspace can get a playback position as if the playback is fine. While during the normal playback, if I stop calling snd_pcm_period_elapsed(), userspace is no longer getting the right position. That's why I am confused, I can't easily explain this "no sound but otherwise fine playback" effect, so I am a bit reluctant to try explaining this in a commit msg. Are there are some fallbacks? Such as when the DAI is considered mute, it gets somehow emulated, with the use of the system clock for correct timing etc?
That's actually a bit strange indeed, since you should get an error when you try to open the pcm device.
- Lars