[alsa-devel] [PATCH] ASoC: soc-pcm: always cancel any pending delayed stream shutdown

[Mark Brown]

On Wed, Oct 22, 2014 at 05:25:11PM +0000, Palacios, Hector wrote:

Fix your mailer to word wrap within paragraphs.

> On Wed, 22 Oct 2014 18:28, Mark Brown wrote:
> > On Wed, Oct 22, 2014 at 04:14:53PM +0200, Hector Palacios wrote:
> >> After playback a shutdown is scheduled to happen within 5 seconds.
> >> If another playback takes place before the scheduled work times out, 
> >> the work is cancelled, but if a recording takes place, the work will 
> >> shutdown in the middle of the recording, causing problems.

> > You're not saying what the problems are, just that they might be caused.

> Sorry, your right. When I do a recording 2 seconds after a previous
> playback, and later play the recorded sound I hear 3 seconds of
> correct audio and then I continue to hear good audio but mixed with
> noise and at a higher volume, as if the codec had reseted certain
> parameters to some default values.

That definitely sounds like a driver bug.

> > Starting or stopping a playback should have no impact on a running 
> > capture stream, users could always start and stop streams manually 
> > anyway.  It sounds like you're working around some problem in drivers.

> I see. I tested this with Freescale SGTL5000 on an i.MX6 platform. The
> shutdown of the playback is eventually calling the set_bias_level()
> hook of the codec to SND_SOC_BIAS_PREPARE and then again to
> SND_SOC_BIAS_STANDBY which may eventually turn off the regulators.
> Anyway the problem doesn't seem to be on this codec hook because I set
> it to NULL and the problem was reproducible. I thought it was the
> dapm->bias_level being set to STANDBY on snd_soc_dapm_set_bias_level()
> in the middle of the capture that did something to the workflow of the
> capture stream, but I'm no expert on the architecture of the sound
> layer and didn't see any other call to the codec functions that could
> be causing the issue. 

Check for any interactions with the CODEC register map, and make sure
that you're using the latest version of the driver since it's had quite
a few problems.  If it is something interacting with the device you
should be able to see it if you log all interactions with the device.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20141028/96312a10/attachment.sig>