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

[Stas Sergeev]

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?