Skip to content

start/stop floods with applications using start threshold, e.g. with aplay+S3 #1062

Closed

Description

@kv2019i

Bug moved from FW to driver (previously thesofproject/sof#1572)

Describe the bug
There seems to be an issue with handling a TRIG_START when following conditions apply:

  • stream has been previously running and then restarted (1) S3 suspend+resume, 2) application stopped with SIGSUSPEND, 3) XRUN, or 4) applications which start/stop the stream with snd_pcm_drop() + snd_pcm_prepare() + snd_pcm_start()))
  • application has set the "start_threshold" SW parameter to any lower value than the maximum, or explicitly starts the stream with snd_pcm_start()

With these conditions met, FW is not able to start the stream succesfully, but either ends up in a short start/stop loop causing dozens of XRUNs lasting multiple milliseconds (and making a pretty awful nosie), or in infinite loop (application must be terminated to recover).

This problem is at least a contributing factor to Pulseaudio issues tracked in linux#1000

To Reproduce
To simplify testing, I figured out following way to reproduce this with aplay (but this will impact a wide range of other ALSA applications):

  1. aplay -R 21000 -Dhw:0 -vv -i testfile.wav
  2. suspend aplay with 'ctrl-Z'
  3. resume aplay with 'fg'
  4. go back to (2) until error occurs

The error happens with 21ms start threshdold in this example, but notably
higher values (-R 200000) also cause the issue. Clearly DSP should have plenty of time to resume the stream with this much buffering in place.

Reproduction Rate
5/10

Expected behavior
Playback should resume succesfully.

Impact
Marked is as P2 as DSP should under no circumstance go into a state machine loop like this.

Environment

  1. Branches
    SOF: 0dd6c23 (master)
    Linux: 2712289 (sof-dev head)

Note: attached log file has some additional patches (prints with "KV:"), but the bug is reproduced without these patches with the unmodified version above. The additional patches are to explain the problem better.

  1. Name of the topology file: sof-hda-generic-2ch.tplg
  2. Platform: WHL laptop with HDA codec
  3. Reproducibility Rate: 5/10

Screenshots or console output

Sof-logger file attached.
20190617-soflog.txt

Activity

  1. added
    bugSomething isn't working
    P2Critical bugs or normal features
    WHLApplies to WhiskeyLake platform
    CFLApplies to Coffee Lake platform
    on Jun 27, 2019
  2. self-assigned this
    on Jun 27, 2019
  3. kv2019i commented on Jun 27, 2019

    @kv2019i
    CollaboratorAuthor

    PR1049 now ready for review (not draft anymore) and will address this bug.

    A separate bug filed to track the audio content issue that still happens with PR1049 -> #1062

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

CFLApplies to Coffee Lake platformP2Critical bugs or normal featuresWHLApplies to WhiskeyLake platformbugSomething isn't working

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions