Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] start/stop of SSP/nodec stream interferes with another stream #1526

Closed
kv2019i opened this issue Jun 6, 2019 · 4 comments · Fixed by #1589
Closed

[BUG] start/stop of SSP/nodec stream interferes with another stream #1526

kv2019i opened this issue Jun 6, 2019 · 4 comments · Fixed by #1589
Labels
APL Applies to Apollolake platform bug Something isn't working as expected

Comments

@kv2019i
Copy link
Collaborator

kv2019i commented Jun 6, 2019

Describe the bug
This is a clone of Linux bug thesofproject/linux#854
The history is a bit complex to follow, but upon study of the bug today, the case is as follows:

Two PCM playback clients connected to SSP in nocodec mode. One client is kept stream, while other continuously starts and stops.

To Reproduce
Aplay instructions in
thesofproject/linux#854 (comment)

Reproduction Rate
1/10

Expected behavior
Starting and stopping one stream does not interfere with another stream.

Impact
End-product cases with multiple pipelines will show errors (e.g. a UI sound feedback may interfere with HDMI output).

Environment
APL UP2 pcm512x & APL UP2 nocodec
sof (master): 92fc706
kernel (topic/sof-dev): 80a2cb8
topology: sof-apl-pcm512x.tplg & sof-apl-nocodec.tplg

Screenshots or console output
See thesofproject/linux#854 (comment)

@kv2019i kv2019i added bug Something isn't working as expected APL Applies to Apollolake platform labels Jun 6, 2019
@kv2019i
Copy link
Collaborator Author

kv2019i commented Jun 6, 2019

soflog.txt

Annotated bits from above log.
client 1 (all the time running) is started

    0      2         PIPE 14.62   2799191127.291667        22.031250 src/audio/pipeline.c:607 	pipeline_trigger()
    0      2         HOST         2799191131.406250         4.114583     src/audio/host.c:262 	host_trigger()
    0      2          DMA         2799191135.572917         4.166667 intel/cavs/hda-dma.c:531 	hda-dmac: 5 channel 1 -> start
    0      2          DMA         2799191139.218750         3.645833 intel/cavs/hda-dma.c:367 	hda-dmac: 5 channel 1 -> enable
    0      2       VOLUME         2799191176.510417        37.291668 udio/volume/volume.c:464 	volume_trigger()
    0      2          SRC         2799191180.468750         3.958333  src/audio/src/src.c:682 	src_trigger()
    0      2        MIXER         2799191184.479167         4.010417    src/audio/mixer.c:211 	mixer_trigger()
    0      2         COMP         2799191187.916667         3.437500 rc/audio/component.c:105 	comp_set_state(), state already set to 5

Then client 2 (start/stop in loop) is stopped and started and start fails

    0      2         PIPE 1.9     2817044901.093750       166.718750 src/audio/pipeline.c:378 	pipeline_prepare()
    0      2         HOST         2817044905.052083         3.958333     src/audio/host.c:614 	host_prepare()
    0      2       VOLUME         2817044918.489583        13.437500 udio/volume/volume.c:522 	volume_prepare()
    0      2        MIXER         2817044931.770833        13.281250    src/audio/mixer.c:358 	mixer_prepare()
    0      1         COMP         2817045834.635417       902.864563 rc/audio/component.c:237 	comp_get_copy_limits() error: sink component buffer has not enough free bytes for copy
    0      2         COMP         2817045840.156250         5.520833 of/audio/component.h:726 	comp_overrun(), ((dev->comp.id << 16) | sink->free) = 131072, 

Xrun recovery fails for client 2, but that also brings down client 1:

    0      2         PIPE 14.62   2817439722.968750        21.041666 src/audio/pipeline.c:607 	pipeline_trigger()
    0      2         HOST         2817439726.770833         3.802083     src/audio/host.c:262 	host_trigger()
    0      2          DMA         2817439730.833333         4.062500 intel/cavs/hda-dma.c:626 	hda-dmac: 5 channel 1 -> stop
    0      2       VOLUME         2817439735.156250         4.322917 udio/volume/volume.c:464 	volume_trigger()
    0      2          SRC         2817439739.062500         3.906250  src/audio/src/src.c:682 	src_trigger()
    0      2        MIXER         2817439742.812500         3.750000    src/audio/mixer.c:211 	mixer_trigger()
    0      2          IPC         2817439894.218750       151.406250    src/ipc/handler.c:328 	ipc: comp 56 -> free
    0      2         PIPE 14.62   2817439915.260417        21.041666 src/audio/pipeline.c:686 	pipeline_reset()

@lgirdwood
Copy link
Member

@kv2019i are these two pipelines connected via the mixer ? or are they not connected. Just confused seeing HDMI and SSP then seeing MIXER in the logs.

@kv2019i
Copy link
Collaborator Author

kv2019i commented Jun 7, 2019

@lgirdwood wrote:

@kv2019i are these two pipelines connected via the mixer ? or are they not connected. Just confused seeing HDMI and SSP then seeing MIXER in the logs.

Good point, yes they are. This is the standard pipe of:
https://github.com/thesofproject/sof/blob/master/tools/topology/sof-apl-nocodec.m4

tplg

Updated the title to reflect this related to two streams connected via mixer.

@tlauda
Copy link
Contributor

tlauda commented Jun 7, 2019

@kv2019i Fail happens when you are stopping client 0 and client 1 is running. As long as you are stopping client 1 everything is working. It doesn't really matter, because it's still a bug, but just wanted to make sure you are aware of that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
APL Applies to Apollolake platform bug Something isn't working as expected
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants