[alsa-devel] [PATCH] ASoC: define playback and capture streams in dummy codec

[Lars-Peter Clausen]

On 04/12/2013 06:37 PM, Stas Sergeev wrote:
> On Fri, 12 Apr 2013 17:31:19 +0200
> Lars-Peter Clausen <lars at 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