[PATCH] ALSA: compress: allow pause and resume during draining
With a stream with low bitrate, user can't pause or resume the stream near the end of the stream because current ALSA doesn't allow it. If the stream has very low bitrate enough to store whole stream into the buffer, user can't do anything except stop the stream and then restart it from the first. If pause and resume is allowed during draining, user experience can be enhanced.
Signed-off-by: Gyeongtaek Lee gt82.lee@samsung.com --- sound/core/compress_offload.c | 34 ++++++++++++++++++++++++++-------- 1 file changed, 26 insertions(+), 8 deletions(-)
diff --git a/sound/core/compress_offload.c b/sound/core/compress_offload.c index 0e53f6f31916..90b437f302a0 100644 --- a/sound/core/compress_offload.c +++ b/sound/core/compress_offload.c @@ -708,11 +708,20 @@ static int snd_compr_pause(struct snd_compr_stream *stream) { int retval;
- if (stream->runtime->state != SNDRV_PCM_STATE_RUNNING) + switch (stream->runtime->state) { + case SNDRV_PCM_STATE_RUNNING: + retval = stream->ops->trigger(stream, + SNDRV_PCM_TRIGGER_PAUSE_PUSH); + if (!retval) + stream->runtime->state = SNDRV_PCM_STATE_PAUSED; + break; + case SNDRV_PCM_STATE_DRAINING: + retval = stream->ops->trigger(stream, + SNDRV_PCM_TRIGGER_PAUSE_PUSH); + break; + default: return -EPERM; - retval = stream->ops->trigger(stream, SNDRV_PCM_TRIGGER_PAUSE_PUSH); - if (!retval) - stream->runtime->state = SNDRV_PCM_STATE_PAUSED; + } return retval; }
@@ -720,11 +729,20 @@ static int snd_compr_resume(struct snd_compr_stream *stream) { int retval;
- if (stream->runtime->state != SNDRV_PCM_STATE_PAUSED) + switch (stream->runtime->state) { + case SNDRV_PCM_STATE_PAUSED: + retval = stream->ops->trigger(stream, + SNDRV_PCM_TRIGGER_PAUSE_RELEASE); + if (!retval) + stream->runtime->state = SNDRV_PCM_STATE_RUNNING; + break; + case SNDRV_PCM_STATE_DRAINING: + retval = stream->ops->trigger(stream, + SNDRV_PCM_TRIGGER_PAUSE_RELEASE); + break; + default: return -EPERM; - retval = stream->ops->trigger(stream, SNDRV_PCM_TRIGGER_PAUSE_RELEASE); - if (!retval) - stream->runtime->state = SNDRV_PCM_STATE_RUNNING; + } return retval; }
base-commit: a1b8638ba1320e6684aa98233c15255eb803fac7
Dne 28. 09. 20 v 12:50 Gyeongtaek Lee napsal(a):
With a stream with low bitrate, user can't pause or resume the stream near the end of the stream because current ALSA doesn't allow it. If the stream has very low bitrate enough to store whole stream into the buffer, user can't do anything except stop the stream and then restart it from the first. If pause and resume is allowed during draining, user experience can be enhanced.
It seems that we need a new state to handle the pause + drain condition for this case.
With this proposed change, the pause state in drain is invisible.
Jaroslav
On 9/28/20 6:13 AM, Jaroslav Kysela wrote:
Dne 28. 09. 20 v 12:50 Gyeongtaek Lee napsal(a):
With a stream with low bitrate, user can't pause or resume the stream near the end of the stream because current ALSA doesn't allow it. If the stream has very low bitrate enough to store whole stream into the buffer, user can't do anything except stop the stream and then restart it from the first. If pause and resume is allowed during draining, user experience can be enhanced.
It seems that we need a new state to handle the pause + drain condition for this case.
With this proposed change, the pause state in drain is invisible.
Indeed it's be much nicer to have a new state, e..g SNDRV_PCM_STATE_DRAINING_PAUSED.
One concern is that states are defined in uapi/sound/asoc.h, so wouldn't this have impacts on userspace as well? We'd change the value of SNDRV_PCM_STATE_LAST.
On 9/28/20 11:35 PM, Pierre-Louis Bossart wrote:
On 9/28/20 6:13 AM, Jaroslav Kysela wrote:
Dne 28. 09. 20 v 12:50 Gyeongtaek Lee napsal(a):
With a stream with low bitrate, user can't pause or resume the stream near the end of the stream because current ALSA doesn't allow it. If the stream has very low bitrate enough to store whole stream into the buffer, user can't do anything except stop the stream and then restart it from the first. If pause and resume is allowed during draining, user experience can be enhanced.
It seems that we need a new state to handle the pause + drain condition for this case.
With this proposed change, the pause state in drain is invisible.
Indeed it's be much nicer to have a new state, e..g SNDRV_PCM_STATE_DRAINING_PAUSED.
Ok. I will add the new state.
One concern is that states are defined in uapi/sound/asoc.h, so wouldn't this have impacts on userspace as well? We'd change the value of SNDRV_PCM_STATE_LAST.
I also agree that adding new state and increase LAST value in the header of uapi could be dangerous. So, I added it to comress_offload.h for now. It could be merged into snd_pcm_state_t in someday with big changes. Could you review the fixed patch below?
With a stream with low bitrate, user can't pause or resume the stream near the end of the stream because current ALSA doesn't allow it. If the stream has very low bitrate enough to store whole stream into the buffer, user can't do anything except stop the stream and then restart it from first. If pause, resume are allowed during draining, user experience can be enhanced.
New state for pause during draining is defined in compress_offload.h for now. If PCM_STATEs in uapi/sound/asound.h is changed, pcm libraries and userspace application will be affected.
Signed-off-by: Gyeongtaek Lee gt82.lee@samsung.com Cc: stable@vger.kernel.org --- include/uapi/sound/compress_offload.h | 3 ++ sound/core/compress_offload.c | 47 ++++++++++++++++++++++----- 2 files changed, 41 insertions(+), 9 deletions(-)
diff --git a/include/uapi/sound/compress_offload.h b/include/uapi/sound/compress_offload.h index 7184265c0b0d..f30b9851d1d7 100644 --- a/include/uapi/sound/compress_offload.h +++ b/include/uapi/sound/compress_offload.h @@ -189,4 +189,7 @@ struct snd_compr_metadata { #define SND_COMPR_TRIGGER_DRAIN 7 /*FIXME move this to pcm.h */ #define SND_COMPR_TRIGGER_NEXT_TRACK 8 #define SND_COMPR_TRIGGER_PARTIAL_DRAIN 9 + +/* FIXME move this to asound.h */ +#define SNDRV_PCM_STATE_DRAINING_PAUSED (SNDRV_PCM_STATE_LAST + 1) #endif diff --git a/sound/core/compress_offload.c b/sound/core/compress_offload.c index 0e53f6f31916..58fbe0d99431 100644 --- a/sound/core/compress_offload.c +++ b/sound/core/compress_offload.c @@ -151,6 +151,7 @@ static int snd_compr_free(struct inode *inode, struct file *f) case SNDRV_PCM_STATE_RUNNING: case SNDRV_PCM_STATE_DRAINING: case SNDRV_PCM_STATE_PAUSED: + case SNDRV_PCM_STATE_DRAINING_PAUSED: data->stream.ops->trigger(&data->stream, SNDRV_PCM_TRIGGER_STOP); break; default: @@ -431,6 +432,7 @@ static __poll_t snd_compr_poll(struct file *f, poll_table *wait) case SNDRV_PCM_STATE_RUNNING: case SNDRV_PCM_STATE_PREPARED: case SNDRV_PCM_STATE_PAUSED: + case SNDRV_PCM_STATE_DRAINING_PAUSED: if (avail >= stream->runtime->fragment_size) retval = snd_compr_get_poll(stream); break; @@ -708,11 +710,23 @@ static int snd_compr_pause(struct snd_compr_stream *stream) { int retval;
- if (stream->runtime->state != SNDRV_PCM_STATE_RUNNING) + switch (stream->runtime->state) { + case SNDRV_PCM_STATE_RUNNING: + retval = stream->ops->trigger(stream, + SNDRV_PCM_TRIGGER_PAUSE_PUSH); + if (!retval) + stream->runtime->state = SNDRV_PCM_STATE_PAUSED; + break; + case SNDRV_PCM_STATE_DRAINING: + retval = stream->ops->trigger(stream, + SNDRV_PCM_TRIGGER_PAUSE_PUSH); + if (!retval) + stream->runtime->state = + SNDRV_PCM_STATE_DRAINING_PAUSED; + break; + default: return -EPERM; - retval = stream->ops->trigger(stream, SNDRV_PCM_TRIGGER_PAUSE_PUSH); - if (!retval) - stream->runtime->state = SNDRV_PCM_STATE_PAUSED; + } return retval; }
@@ -720,11 +734,22 @@ static int snd_compr_resume(struct snd_compr_stream *stream) { int retval;
- if (stream->runtime->state != SNDRV_PCM_STATE_PAUSED) + switch (stream->runtime->state) { + case SNDRV_PCM_STATE_PAUSED: + retval = stream->ops->trigger(stream, + SNDRV_PCM_TRIGGER_PAUSE_RELEASE); + if (!retval) + stream->runtime->state = SNDRV_PCM_STATE_RUNNING; + break; + case SNDRV_PCM_STATE_DRAINING_PAUSED: + retval = stream->ops->trigger(stream, + SNDRV_PCM_TRIGGER_PAUSE_RELEASE); + if (!retval) + stream->runtime->state = SNDRV_PCM_STATE_DRAINING; + break; + default: return -EPERM; - retval = stream->ops->trigger(stream, SNDRV_PCM_TRIGGER_PAUSE_RELEASE); - if (!retval) - stream->runtime->state = SNDRV_PCM_STATE_RUNNING; + } return retval; }
@@ -835,7 +860,9 @@ static int snd_compress_wait_for_drain(struct snd_compr_stream *stream) */
ret = wait_event_interruptible(stream->runtime->sleep, - (stream->runtime->state != SNDRV_PCM_STATE_DRAINING)); + (stream->runtime->state != SNDRV_PCM_STATE_DRAINING) && + (stream->runtime->state != + SNDRV_PCM_STATE_DRAINING_PAUSED)); if (ret == -ERESTARTSYS) pr_debug("wait aborted by a signal\n"); else if (ret) @@ -857,6 +884,7 @@ static int snd_compr_drain(struct snd_compr_stream *stream) case SNDRV_PCM_STATE_SETUP: case SNDRV_PCM_STATE_PREPARED: case SNDRV_PCM_STATE_PAUSED: + case SNDRV_PCM_STATE_DRAINING_PAUSED: return -EPERM; case SNDRV_PCM_STATE_XRUN: return -EPIPE; @@ -909,6 +937,7 @@ static int snd_compr_partial_drain(struct snd_compr_stream *stream) case SNDRV_PCM_STATE_SETUP: case SNDRV_PCM_STATE_PREPARED: case SNDRV_PCM_STATE_PAUSED: + case SNDRV_PCM_STATE_DRAINING_PAUSED: return -EPERM; case SNDRV_PCM_STATE_XRUN: return -EPIPE;
base-commit: a1b8638ba1320e6684aa98233c15255eb803fac7
On Tue, 29 Sep 2020 03:51:35 +0200, Gyeongtaek Lee wrote:
On 9/28/20 11:35 PM, Pierre-Louis Bossart wrote:
On 9/28/20 6:13 AM, Jaroslav Kysela wrote:
Dne 28. 09. 20 v 12:50 Gyeongtaek Lee napsal(a):
With a stream with low bitrate, user can't pause or resume the stream near the end of the stream because current ALSA doesn't allow it. If the stream has very low bitrate enough to store whole stream into the buffer, user can't do anything except stop the stream and then restart it from the first. If pause and resume is allowed during draining, user experience can be enhanced.
It seems that we need a new state to handle the pause + drain condition for this case.
With this proposed change, the pause state in drain is invisible.
Indeed it's be much nicer to have a new state, e..g SNDRV_PCM_STATE_DRAINING_PAUSED.
Ok. I will add the new state.
One concern is that states are defined in uapi/sound/asoc.h, so wouldn't this have impacts on userspace as well? We'd change the value of SNDRV_PCM_STATE_LAST.
I also agree that adding new state and increase LAST value in the header of uapi could be dangerous. So, I added it to comress_offload.h for now. It could be merged into snd_pcm_state_t in someday with big changes. Could you review the fixed patch below?
Hrm, this resulted in rather more complex changes than the original patch. It shows that introducing yet another state is no good idea for this particular case.
Since the possible application's behavior after this pause is as same as the normal pause (i.e. either resuming pause or dropping), I find it OK to take the original approach.
thanks,
Takashi
With a stream with low bitrate, user can't pause or resume the stream near the end of the stream because current ALSA doesn't allow it. If the stream has very low bitrate enough to store whole stream into the buffer, user can't do anything except stop the stream and then restart it from first. If pause, resume are allowed during draining, user experience can be enhanced.
New state for pause during draining is defined in compress_offload.h for now. If PCM_STATEs in uapi/sound/asound.h is changed, pcm libraries and userspace application will be affected.
Signed-off-by: Gyeongtaek Lee gt82.lee@samsung.com Cc: stable@vger.kernel.org
include/uapi/sound/compress_offload.h | 3 ++ sound/core/compress_offload.c | 47 ++++++++++++++++++++++----- 2 files changed, 41 insertions(+), 9 deletions(-)
diff --git a/include/uapi/sound/compress_offload.h b/include/uapi/sound/compress_offload.h index 7184265c0b0d..f30b9851d1d7 100644 --- a/include/uapi/sound/compress_offload.h +++ b/include/uapi/sound/compress_offload.h @@ -189,4 +189,7 @@ struct snd_compr_metadata { #define SND_COMPR_TRIGGER_DRAIN 7 /*FIXME move this to pcm.h */ #define SND_COMPR_TRIGGER_NEXT_TRACK 8 #define SND_COMPR_TRIGGER_PARTIAL_DRAIN 9
+/* FIXME move this to asound.h */ +#define SNDRV_PCM_STATE_DRAINING_PAUSED (SNDRV_PCM_STATE_LAST + 1) #endif diff --git a/sound/core/compress_offload.c b/sound/core/compress_offload.c index 0e53f6f31916..58fbe0d99431 100644 --- a/sound/core/compress_offload.c +++ b/sound/core/compress_offload.c @@ -151,6 +151,7 @@ static int snd_compr_free(struct inode *inode, struct file *f) case SNDRV_PCM_STATE_RUNNING: case SNDRV_PCM_STATE_DRAINING: case SNDRV_PCM_STATE_PAUSED:
- case SNDRV_PCM_STATE_DRAINING_PAUSED: data->stream.ops->trigger(&data->stream, SNDRV_PCM_TRIGGER_STOP); break; default:
@@ -431,6 +432,7 @@ static __poll_t snd_compr_poll(struct file *f, poll_table *wait) case SNDRV_PCM_STATE_RUNNING: case SNDRV_PCM_STATE_PREPARED: case SNDRV_PCM_STATE_PAUSED:
- case SNDRV_PCM_STATE_DRAINING_PAUSED: if (avail >= stream->runtime->fragment_size) retval = snd_compr_get_poll(stream); break;
@@ -708,11 +710,23 @@ static int snd_compr_pause(struct snd_compr_stream *stream) { int retval;
- if (stream->runtime->state != SNDRV_PCM_STATE_RUNNING)
- switch (stream->runtime->state) {
- case SNDRV_PCM_STATE_RUNNING:
retval = stream->ops->trigger(stream,SNDRV_PCM_TRIGGER_PAUSE_PUSH);if (!retval)stream->runtime->state = SNDRV_PCM_STATE_PAUSED;break;- case SNDRV_PCM_STATE_DRAINING:
retval = stream->ops->trigger(stream,SNDRV_PCM_TRIGGER_PAUSE_PUSH);if (!retval)stream->runtime->state =SNDRV_PCM_STATE_DRAINING_PAUSED;break;- default: return -EPERM;
- retval = stream->ops->trigger(stream, SNDRV_PCM_TRIGGER_PAUSE_PUSH);
- if (!retval)
stream->runtime->state = SNDRV_PCM_STATE_PAUSED;
- } return retval;
}
@@ -720,11 +734,22 @@ static int snd_compr_resume(struct snd_compr_stream *stream) { int retval;
- if (stream->runtime->state != SNDRV_PCM_STATE_PAUSED)
- switch (stream->runtime->state) {
- case SNDRV_PCM_STATE_PAUSED:
retval = stream->ops->trigger(stream,SNDRV_PCM_TRIGGER_PAUSE_RELEASE);if (!retval)stream->runtime->state = SNDRV_PCM_STATE_RUNNING;break;- case SNDRV_PCM_STATE_DRAINING_PAUSED:
retval = stream->ops->trigger(stream,SNDRV_PCM_TRIGGER_PAUSE_RELEASE);if (!retval)stream->runtime->state = SNDRV_PCM_STATE_DRAINING;break;- default: return -EPERM;
- retval = stream->ops->trigger(stream, SNDRV_PCM_TRIGGER_PAUSE_RELEASE);
- if (!retval)
stream->runtime->state = SNDRV_PCM_STATE_RUNNING;
- } return retval;
}
@@ -835,7 +860,9 @@ static int snd_compress_wait_for_drain(struct snd_compr_stream *stream) */
ret = wait_event_interruptible(stream->runtime->sleep,
(stream->runtime->state != SNDRV_PCM_STATE_DRAINING));
(stream->runtime->state != SNDRV_PCM_STATE_DRAINING) &&(stream->runtime->state !=SNDRV_PCM_STATE_DRAINING_PAUSED));@@ -857,6 +884,7 @@ static int snd_compr_drain(struct snd_compr_stream *stream) case SNDRV_PCM_STATE_SETUP: case SNDRV_PCM_STATE_PREPARED: case SNDRV_PCM_STATE_PAUSED:
- case SNDRV_PCM_STATE_DRAINING_PAUSED: return -EPERM; case SNDRV_PCM_STATE_XRUN: return -EPIPE;
@@ -909,6 +937,7 @@ static int snd_compr_partial_drain(struct snd_compr_stream *stream) case SNDRV_PCM_STATE_SETUP: case SNDRV_PCM_STATE_PREPARED: case SNDRV_PCM_STATE_PAUSED:
- case SNDRV_PCM_STATE_DRAINING_PAUSED: return -EPERM; case SNDRV_PCM_STATE_XRUN: return -EPIPE;
base-commit: a1b8638ba1320e6684aa98233c15255eb803fac7
2.21.0
Dne 29. 09. 20 v 9:12 Takashi Iwai napsal(a):
On Tue, 29 Sep 2020 03:51:35 +0200, Gyeongtaek Lee wrote:
On 9/28/20 11:35 PM, Pierre-Louis Bossart wrote:
On 9/28/20 6:13 AM, Jaroslav Kysela wrote:
Dne 28. 09. 20 v 12:50 Gyeongtaek Lee napsal(a):
With a stream with low bitrate, user can't pause or resume the stream near the end of the stream because current ALSA doesn't allow it. If the stream has very low bitrate enough to store whole stream into the buffer, user can't do anything except stop the stream and then restart it from the first. If pause and resume is allowed during draining, user experience can be enhanced.
It seems that we need a new state to handle the pause + drain condition for this case.
With this proposed change, the pause state in drain is invisible.
Indeed it's be much nicer to have a new state, e..g SNDRV_PCM_STATE_DRAINING_PAUSED.
Ok. I will add the new state.
One concern is that states are defined in uapi/sound/asoc.h, so wouldn't this have impacts on userspace as well? We'd change the value of SNDRV_PCM_STATE_LAST.
I also agree that adding new state and increase LAST value in the header of uapi could be dangerous. So, I added it to comress_offload.h for now. It could be merged into snd_pcm_state_t in someday with big changes. Could you review the fixed patch below?
I don't see a big problem to improve the API, but don't forget to increase the SNDRV_COMPRESS_VERSION, so the user space apps can check for this new behaviour.
Hrm, this resulted in rather more complex changes than the original patch. It shows that introducing yet another state is no good idea for this particular case.
I don't think so. The states should be isolated and it's clearly a new state and the resulted code at least gives a commented idea, what's going on. It seems that the compress driver state is not exported to the user space at the moment, so I would consider this extension as harmless. We can add this state to asound.h so the user space can be updated. We may use this state for the standard PCM devices one day, too. It makes sense to reserve it sooner than later.
BTW: Offtopic - Why compress code returns EPERM if the state is not correct? It's not about the permissions. The EBADFD is much better code in this case.
Jaroslav
Since the possible application's behavior after this pause is as same as the normal pause (i.e. either resuming pause or dropping), I find it OK to take the original approach.
thanks,
Takashi
On Tue, 29 Sep 2020 19:27:17 +0200, Jaroslav Kysela wrote:
Dne 29. 09. 20 v 9:12 Takashi Iwai napsal(a):
On Tue, 29 Sep 2020 03:51:35 +0200, Gyeongtaek Lee wrote:
On 9/28/20 11:35 PM, Pierre-Louis Bossart wrote:
On 9/28/20 6:13 AM, Jaroslav Kysela wrote:
Dne 28. 09. 20 v 12:50 Gyeongtaek Lee napsal(a):
With a stream with low bitrate, user can't pause or resume the stream near the end of the stream because current ALSA doesn't allow it. If the stream has very low bitrate enough to store whole stream into the buffer, user can't do anything except stop the stream and then restart it from the first. If pause and resume is allowed during draining, user experience can be enhanced.
It seems that we need a new state to handle the pause + drain condition for this case.
With this proposed change, the pause state in drain is invisible.
Indeed it's be much nicer to have a new state, e..g SNDRV_PCM_STATE_DRAINING_PAUSED.
Ok. I will add the new state.
One concern is that states are defined in uapi/sound/asoc.h, so wouldn't this have impacts on userspace as well? We'd change the value of SNDRV_PCM_STATE_LAST.
I also agree that adding new state and increase LAST value in the header of uapi could be dangerous. So, I added it to comress_offload.h for now. It could be merged into snd_pcm_state_t in someday with big changes. Could you review the fixed patch below?
I don't see a big problem to improve the API, but don't forget to increase the SNDRV_COMPRESS_VERSION, so the user space apps can check for this new behaviour.
Hrm, this resulted in rather more complex changes than the original patch. It shows that introducing yet another state is no good idea for this particular case.
I don't think so. The states should be isolated and it's clearly a new state and the resulted code at least gives a commented idea, what's going on. It seems that the compress driver state is not exported to the user space at the moment, so I would consider this extension as harmless. We can add this state to asound.h so the user space can be updated. We may use this state for the standard PCM devices one day, too. It makes sense to reserve it sooner than later.
Well, adding a new state can be cumbersome sometimes. For example, the code like below may hit a segfault out of sudden after the upgrade:
const char *states[SNDRV_PCM_STATE_LAST + 1] = { [SNDRV_PCM_STATE_RUNNING] = "running", .... };
printf("current state = %s\n", states[s]);
It's not much frequent breakage, but this can give certainly some incompatibilities even in the source code level.
That's the reason I'm reluctant to add a new state unless it's a must. As mentioned, the expected application's behavior is just like the normal pause state, either resuming pause or dropping. The only case where a new state would help for application is at most that they may foresee beforehand which state it'll go after the resume, to drain or to running. If this is a must-to-have feature, we can reconsider.
BTW: Offtopic - Why compress code returns EPERM if the state is not correct? It's not about the permissions. The EBADFD is much better code in this case.
Indeed that sounds inconsistent, but I'm afraid it too late to change? Suppose some code already depending on the error code. Who knows...
thanks,
Takashi
Dne 30. 09. 20 v 11:35 Takashi Iwai napsal(a):
On Tue, 29 Sep 2020 19:27:17 +0200, Jaroslav Kysela wrote:
Dne 29. 09. 20 v 9:12 Takashi Iwai napsal(a):
On Tue, 29 Sep 2020 03:51:35 +0200, Gyeongtaek Lee wrote:
On 9/28/20 11:35 PM, Pierre-Louis Bossart wrote:
On 9/28/20 6:13 AM, Jaroslav Kysela wrote:
Dne 28. 09. 20 v 12:50 Gyeongtaek Lee napsal(a): > With a stream with low bitrate, user can't pause or resume the stream > near the end of the stream because current ALSA doesn't allow it. > If the stream has very low bitrate enough to store whole stream into > the buffer, user can't do anything except stop the stream and then > restart it from the first. > If pause and resume is allowed during draining, user experience can be > enhanced.
It seems that we need a new state to handle the pause + drain condition for this case.
With this proposed change, the pause state in drain is invisible.
Indeed it's be much nicer to have a new state, e..g SNDRV_PCM_STATE_DRAINING_PAUSED.
Ok. I will add the new state.
One concern is that states are defined in uapi/sound/asoc.h, so wouldn't this have impacts on userspace as well? We'd change the value of SNDRV_PCM_STATE_LAST.
I also agree that adding new state and increase LAST value in the header of uapi could be dangerous. So, I added it to comress_offload.h for now. It could be merged into snd_pcm_state_t in someday with big changes. Could you review the fixed patch below?
I don't see a big problem to improve the API, but don't forget to increase the SNDRV_COMPRESS_VERSION, so the user space apps can check for this new behaviour.
Hrm, this resulted in rather more complex changes than the original patch. It shows that introducing yet another state is no good idea for this particular case.
I don't think so. The states should be isolated and it's clearly a new state and the resulted code at least gives a commented idea, what's going on. It seems that the compress driver state is not exported to the user space at the moment, so I would consider this extension as harmless. We can add this state to asound.h so the user space can be updated. We may use this state for the standard PCM devices one day, too. It makes sense to reserve it sooner than later.
Well, adding a new state can be cumbersome sometimes. For example, the code like below may hit a segfault out of sudden after the upgrade:
const char *states[SNDRV_PCM_STATE_LAST + 1] = { [SNDRV_PCM_STATE_RUNNING] = "running", .... };
printf("current state = %s\n", states[s]);
It's not much frequent breakage, but this can give certainly some incompatibilities even in the source code level.
alsa-lib has already the correct protection for this case:
const char *snd_pcm_state_name(const snd_pcm_state_t state) { if (state > SND_PCM_STATE_LAST) return NULL; return snd_pcm_state_names[state]; }
If there's no check, it's a clear bug.
That's the reason I'm reluctant to add a new state unless it's a must. As mentioned, the expected application's behavior is just like the normal pause state, either resuming pause or dropping. The only case where a new state would help for application is at most that they may foresee beforehand which state it'll go after the resume, to drain or to running. If this is a must-to-have feature, we can reconsider.
I don't agree here. It's much better to not hide the state related transitions even in the kernel in my eyes. For example drivers may behave differently when they resume from running+pause or drain+pause states.
The correct SNDRV_PCM_STATE_LAST is just an implementation issue, which can be easily solved.
Jaroslav
On Wed, 30 Sep 2020 11:57:45 +0200, Jaroslav Kysela wrote:
Dne 30. 09. 20 v 11:35 Takashi Iwai napsal(a):
On Tue, 29 Sep 2020 19:27:17 +0200, Jaroslav Kysela wrote:
Dne 29. 09. 20 v 9:12 Takashi Iwai napsal(a):
On Tue, 29 Sep 2020 03:51:35 +0200, Gyeongtaek Lee wrote:
On 9/28/20 11:35 PM, Pierre-Louis Bossart wrote:
On 9/28/20 6:13 AM, Jaroslav Kysela wrote: > Dne 28. 09. 20 v 12:50 Gyeongtaek Lee napsal(a): >> With a stream with low bitrate, user can't pause or resume the stream >> near the end of the stream because current ALSA doesn't allow it. >> If the stream has very low bitrate enough to store whole stream into >> the buffer, user can't do anything except stop the stream and then >> restart it from the first. >> If pause and resume is allowed during draining, user experience can be >> enhanced. > > It seems that we need a new state to handle the pause + drain condition for > this case. > > With this proposed change, the pause state in drain is invisible.
Indeed it's be much nicer to have a new state, e..g SNDRV_PCM_STATE_DRAINING_PAUSED.
Ok. I will add the new state.
One concern is that states are defined in uapi/sound/asoc.h, so wouldn't this have impacts on userspace as well? We'd change the value of SNDRV_PCM_STATE_LAST.
I also agree that adding new state and increase LAST value in the header of uapi could be dangerous. So, I added it to comress_offload.h for now. It could be merged into snd_pcm_state_t in someday with big changes. Could you review the fixed patch below?
I don't see a big problem to improve the API, but don't forget to increase the SNDRV_COMPRESS_VERSION, so the user space apps can check for this new behaviour.
Hrm, this resulted in rather more complex changes than the original patch. It shows that introducing yet another state is no good idea for this particular case.
I don't think so. The states should be isolated and it's clearly a new state and the resulted code at least gives a commented idea, what's going on. It seems that the compress driver state is not exported to the user space at the moment, so I would consider this extension as harmless. We can add this state to asound.h so the user space can be updated. We may use this state for the standard PCM devices one day, too. It makes sense to reserve it sooner than later.
Well, adding a new state can be cumbersome sometimes. For example, the code like below may hit a segfault out of sudden after the upgrade:
const char *states[SNDRV_PCM_STATE_LAST + 1] = { [SNDRV_PCM_STATE_RUNNING] = "running", .... };
printf("current state = %s\n", states[s]);
It's not much frequent breakage, but this can give certainly some incompatibilities even in the source code level.
alsa-lib has already the correct protection for this case:
const char *snd_pcm_state_name(const snd_pcm_state_t state) { if (state > SND_PCM_STATE_LAST) return NULL; return snd_pcm_state_names[state]; }
If there's no check, it's a clear bug.
That's not what I meant; the code I showed was just an example implying that the addition of a new state may require the deep code change that can't be caught by a compiler. It may be silently broken.
And imagine the user-space library code that contains handling of the PCM state. All those has to be updated as well to deal with a new state, not only alsa-lib.
IOW, by adding a new item to an exposed attribute like PCM state, the possibly needed change would be spread over all lib / application code, and its influence shouldn't be underestimated. If it were only some internal change in alsa-lib, I won't be concerned at all.
That's the reason I'm reluctant to add a new state unless it's a must. As mentioned, the expected application's behavior is just like the normal pause state, either resuming pause or dropping. The only case where a new state would help for application is at most that they may foresee beforehand which state it'll go after the resume, to drain or to running. If this is a must-to-have feature, we can reconsider.
I don't agree here. It's much better to not hide the state related transitions even in the kernel in my eyes. For example drivers may behave differently when they resume from running+pause or drain+pause states.
Yes, but that's basically the driver's business. As mentioned, "if this is a must-to-have feature" for applications, we'll need to reconsider. But it's not clear from the scenario yet. (FWIW, if any, we may add another function to tell the after-resume state, too; this might be even safer from the compatibility POV, although it can be more complicated.)
The correct SNDRV_PCM_STATE_LAST is just an implementation issue, which can be easily solved.
How easily solvable -- that's the question :)
thanks,
Takashi
Dne 30. 09. 20 v 12:33 Takashi Iwai napsal(a):
On Wed, 30 Sep 2020 11:57:45 +0200, Jaroslav Kysela wrote:
Dne 30. 09. 20 v 11:35 Takashi Iwai napsal(a):
On Tue, 29 Sep 2020 19:27:17 +0200, Jaroslav Kysela wrote:
Dne 29. 09. 20 v 9:12 Takashi Iwai napsal(a):
On Tue, 29 Sep 2020 03:51:35 +0200, Gyeongtaek Lee wrote:
On 9/28/20 11:35 PM, Pierre-Louis Bossart wrote: > On 9/28/20 6:13 AM, Jaroslav Kysela wrote: >> Dne 28. 09. 20 v 12:50 Gyeongtaek Lee napsal(a): >>> With a stream with low bitrate, user can't pause or resume the stream >>> near the end of the stream because current ALSA doesn't allow it. >>> If the stream has very low bitrate enough to store whole stream into >>> the buffer, user can't do anything except stop the stream and then >>> restart it from the first. >>> If pause and resume is allowed during draining, user experience can be >>> enhanced. >> >> It seems that we need a new state to handle the pause + drain condition for >> this case. >> >> With this proposed change, the pause state in drain is invisible. > > Indeed it's be much nicer to have a new state, e..g > SNDRV_PCM_STATE_DRAINING_PAUSED. Ok. I will add the new state. > > One concern is that states are defined in uapi/sound/asoc.h, so wouldn't > this have impacts on userspace as well? We'd change the value of > SNDRV_PCM_STATE_LAST. > I also agree that adding new state and increase LAST value in the header of uapi could be dangerous. So, I added it to comress_offload.h for now. It could be merged into snd_pcm_state_t in someday with big changes. Could you review the fixed patch below?
I don't see a big problem to improve the API, but don't forget to increase the SNDRV_COMPRESS_VERSION, so the user space apps can check for this new behaviour.
Hrm, this resulted in rather more complex changes than the original patch. It shows that introducing yet another state is no good idea for this particular case.
I don't think so. The states should be isolated and it's clearly a new state and the resulted code at least gives a commented idea, what's going on. It seems that the compress driver state is not exported to the user space at the moment, so I would consider this extension as harmless. We can add this state to asound.h so the user space can be updated. We may use this state for the standard PCM devices one day, too. It makes sense to reserve it sooner than later.
Well, adding a new state can be cumbersome sometimes. For example, the code like below may hit a segfault out of sudden after the upgrade:
const char *states[SNDRV_PCM_STATE_LAST + 1] = { [SNDRV_PCM_STATE_RUNNING] = "running", .... };
printf("current state = %s\n", states[s]);
It's not much frequent breakage, but this can give certainly some incompatibilities even in the source code level.
alsa-lib has already the correct protection for this case:
const char *snd_pcm_state_name(const snd_pcm_state_t state) { if (state > SND_PCM_STATE_LAST) return NULL; return snd_pcm_state_names[state]; }
If there's no check, it's a clear bug.
That's not what I meant; the code I showed was just an example implying that the addition of a new state may require the deep code change that can't be caught by a compiler. It may be silently broken.
And imagine the user-space library code that contains handling of the PCM state. All those has to be updated as well to deal with a new state, not only alsa-lib.
IOW, by adding a new item to an exposed attribute like PCM state, the possibly needed change would be spread over all lib / application code, and its influence shouldn't be underestimated. If it were only some internal change in alsa-lib, I won't be concerned at all.
That's the reason I'm reluctant to add a new state unless it's a must. As mentioned, the expected application's behavior is just like the normal pause state, either resuming pause or dropping. The only case where a new state would help for application is at most that they may foresee beforehand which state it'll go after the resume, to drain or to running. If this is a must-to-have feature, we can reconsider.
I don't agree here. It's much better to not hide the state related transitions even in the kernel in my eyes. For example drivers may behave differently when they resume from running+pause or drain+pause states.
Yes, but that's basically the driver's business. As mentioned, "if this is a must-to-have feature" for applications, we'll need to reconsider. But it's not clear from the scenario yet. (FWIW, if any, we may add another function to tell the after-resume state, too; this might be even safer from the compatibility POV, although it can be more complicated.)
The correct SNDRV_PCM_STATE_LAST is just an implementation issue, which can be easily solved.
How easily solvable -- that's the question :)
My proposal is reasonable - use the new state only internally in the kernel for the moment, but update the headers and SNDRV_PCM_STATE_LAST now so the depending code can be updated until the new state is exposed to the user space, too. Something like future reservation. I believe that we need this state also for the standard PCM API.
The SNDRV_PCM_STATE_LAST was added because it was supposed to be changed. It great to keep the 100% driver compatibility but not if it forces us to do hidden changes.
Another way is to activate the new state (and behaviour) conditionally using a new parameter / flag or so from the user space. In this case, both sides know what to do.
Jaroslav
On 30-09-20, 11:35, Takashi Iwai wrote:
On Tue, 29 Sep 2020 19:27:17 +0200, Jaroslav Kysela wrote:
BTW: Offtopic - Why compress code returns EPERM if the state is not correct? It's not about the permissions. The EBADFD is much better code in this case.
That would be me ;-)
Indeed that sounds inconsistent, but I'm afraid it too late to change? Suppose some code already depending on the error code. Who knows...
The probability of that seems lesser ;D ... There are no public upstream users who would care about this. Only public use is QC dragon board and we use tinyplay, which does not care.
Downstream Android HAL would care but chances of them looking at this error code are less (i will check with Qualcomm HAL to see)...
Should we try fixing it?
participants (5)
-
Gyeongtaek Lee -
Jaroslav Kysela -
Pierre-Louis Bossart -
Takashi Iwai -
Vinod Koul