Re: [PATCH] ASoC: define playback and capture streams in dummy codec

From: Stas Sergeev <stsp@list.ru>
To: Lars-Peter Clausen <lars@metafoo.de>
Cc: ALSA devel <alsa-devel@alsa-project.org>,
	"Gabriel M. Beddingfield" <gabrbedd@gmail.com>,
	stsp@users.sourceforge.net
Subject: Re: [PATCH] ASoC: define playback and capture streams in dummy codec
Date: Fri, 12 Apr 2013 23:19:15 +0400	[thread overview]
Message-ID: <51685E33.4080401@list.ru> (raw)
In-Reply-To: <51683C7F.6080803@metafoo.de>

12.04.2013 20:55, Lars-Peter Clausen пишет:
> On 04/12/2013 06:37 PM, Stas Sergeev wrote:
>> 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.
Ah great!
Next week I'll double-check that the fall-back is actually
in userspace (in an android media stack perhaps), and
that will be enough info for the reasonable commit msg. :)
Thanks for your help!
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel