host: remove reset in stop to keep status

[xiulipan]

Need to keep status of host comp at when we stop.

Check ALSA handler for these XRUN patterns to make sure no more bugs happen

depend on #169 to fix #161

[xiulipan]

seems to fix #128 on APL
@keqiaozhang please confirm that.

[lgirdwood]

@xiulipan can you tell us why we need to keep the status ?

[tlauda]

I think pointers reset by this function aren't used for Host DMA anyway, so I doubt it changes anything on APL.

[tlauda]

Have you verified this change? I think ALSA expects position to be reset after stop.

[xiulipan]

@lgirdwood @tlauda

host_elements_reset is function is not needed at all.
in the host.c we use struct dma_sg_elem to save the pointer info of which block the host is reading and writing,
On BYT, we use data in it to give the copy position through dma_set_config

                       lli_desc->dar =
                                 (uint32_t)sg_elem->dest | PLATFORM_HOST_DMA_MASK;
                       lli_desc->sar = (uint32_t)sg_elem->src;

If we reset after each stop, we will get some mismatch from the buffer pointer position in comp buffer and dma copy pointer.

Not sure if host_pointer_reset is not needed. But by removing this function, some kind of noise is gone both on BYT and APL.
Need to figure out by more debug.

but from the code

static int host_pointer_reset(struct comp_dev *dev)
{
	struct host_data *hd = comp_get_drvdata(dev);

	/* reset buffer pointers */
	if (hd->host_pos)
		*hd->host_pos = 0;
	hd->local_pos = 0;
	hd->report_pos = 0;
	dev->position = 0;

	return 0;
}

The local_pos is also be reset. But as now we need to keep what we have in buffer, this pointer should be be cleaned.

[ghost]

@lgirdwood @tlauda
I think keep the history position data during the XRUN stop, it makes sense.
Actually, when the ALSA XRUN happens, appl_ptr and hw_ptr is like this below:
runtime->control->appl_ptr == runtime->status->hw_ptr.
that is XRUN's reason, that is also the pointer's status after reset or prepare operation in the ALSA.
but i think the BDL's register is not reset during this stop/start process in ALSA.

the below is the call stack to configure the host dma's hardware pointer on kernel side,
this is the only way to configure the kernel's dma pointer (maybe should call it BDL).
that means, when the pipeline stop for xrun,
the ALSA does not do the re-configure on the BDL's hardware pointer again.
we can add the log in the call-stack below to confirm this point.

the BDL's parameter configuration call-stack show below:
snd_pcm_ioctl() "when you use aplay, its call-stack will like this below"
snd_pcm_common_ioctl(SNDRV_PCM_IOCTL_HW_PARAMS)
snd_pcm_hw_params_user()
snd_pcm_hw_params()
substream->ops->hw_params()
sof_pcm_hw_params()
snd_sof_pcm_platform_hw_params()
sdev->ops->pcm_hw_params()
hda_dsp_pcm_hw_params()
hda_dsp_stream_hw_params()

Sure, if the ALSA did not do this re-configuration for BDL, we could use another way to fix this.
we let the ALSA call this call-stack when the XRUN is detected in the ALSA.

[lgirdwood]

@xiulipan can you update us on test results

[lgirdwood]

Please cleanup.

[ghost]

@lgirdwood @tlauda
From the analysis, MAYBE there is an issue in the ALSA.
when the XRUN happens, the appl_ptr == hw_ptr. the stop/start command will be sent out.
BUT before we start again, the ALSA might not clear the buffer. the history audio data
would be transmitted again to firmware. That will cause noises.

[xiulipan]

@lgirdwood
Test with APL and BYT.
Now random noise after XRUN injection is gone.
Cleanup is made, just remove these two reset functions.

[xiulipan]

@lgirdwood
I checked out that there are some

continuous-integration/travis-ci/pr Pending — The Travis CI build is in progress

Now in the PR.
I checked that and found it seems to be an online CI?
It seems it will start from rebuilt the docker? Do you think we may have some docker image for it use to speed up the test? I go to check the log and find it spend most of the time on docker build

[lgirdwood]

@xiulipan yes it uses docker, I spent a few hours and added it today. However, the travis build will exceed the time limit when it tries to build initial container. We probably want to use a pre-built container and pass this to travis. Please see https://docs.travis-ci.com/user/docker/#examples. Our Dockerfile also needs updated to use new gcc 8.1 too. Can you create a feature issue for both gcc8.1 and pre-built travis container and assign yourself. Thanks

[lgirdwood]

I've manually stopped travis due to container build time out.

[xiulipan]

@lgirdwood
Cool, it seems we will have new helper.
I will add the issues and update the docker files and try to set the Travis CI

[lgirdwood]

@xiulipan great, I've disabled Travis until this is ready than we can re-enable