-
Notifications
You must be signed in to change notification settings - Fork 321
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
topology2: Add new token 'playback_pause_supported' and set it true f… #9202
topology2: Add new token 'playback_pause_supported' and set it true f… #9202
Conversation
Changes since v1:
|
3c08efc
to
f9c6de0
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Patch looks good. I only concern is whether we should have more conservative opt-out approach to deploy this to existing system, see thesofproject/linux#5041 (review)
Not in agreement, see comments on the kernel side. I want to keep those tests as telltales of possible issues. Exhibit A is the SoundWire bank switch time out found mostly with pause-release and now found in regular cases now that we're looking into it. |
@@ -1374,6 +1383,8 @@ IncludeByKey.SSP1_ENABLED { | |||
name "$SSP1_PCM_NAME" | |||
id 1 | |||
direction "duplex" | |||
playback_pause_supported "true" | |||
capture_pause_supported "true" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if we use the hda_force_pause_support kernel parameter we don't need to special-case the nocodec topology.
Best to define the token as false always, and gradually re-add support as 'true' if/when ready on a platform-by-platform basis
f9c6de0
to
76910e9
Compare
Changes since v2:
|
76910e9
to
0c44e4b
Compare
… by default We need to face with reality that the pause/resume is a feature that is not well tested (end users are using audio via audio servers and they don't use pause/resume) causing constant issues with no real life benefit: With IPC4 multiple pause/resume will make the delay reporting to be exponentially shoot out, making the reported delay to be unusable. Looks like suspend/resume with paused stream has been broken for a long time and just got noticed (since it was not tested). Add a new token to allow selected PCMs to advertise pause support and keep it false by default. The kernel side will allow ignoring the flag to keep the pause advertised for continued testing while protecting accidental use of it by users. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: thesofproject/linux#5035
Change since v3:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@lgirdwood @kv2019i this can be merged without waiting for CI to be ready - it's however required on the kernel side.
We need to face with reality that the pause/resume is a feature that is not
well tested (end users are using audio via audio servers and they don't
use pause/resume) causing constant issues with no real life benefit:
With IPC4 multiple pause/resume will make the delay reporting to be
exponentially shoot out, making the reported delay to be unusable.
Looks like suspend/resume with paused stream has been broken for a long
time and just got noticed (since it was not tested).
Add a new token to allow selected PCMs to advertise pause support and
keep it false by default.
The kernel side will allow ignoring the flag to keep the pause advertised
for continued testing while protecting accidental use of it by users.
Signed-off-by: Peter Ujfalusi peter.ujfalusi@linux.intel.com
Link: thesofproject/linux#5035