From: Vinod Koul <vkoul@kernel.org>
To: Charles Keepax <ckeepax@opensource.cirrus.com>
Cc: patches@opensource.cirrus.com, alsa-devel@alsa-project.org,
tiwai@suse.com
Subject: Re: [PATCH 3/4] ALSA: compress: Don't allow drain operations on capture streams
Date: Tue, 9 Jul 2019 17:06:33 +0530 [thread overview]
Message-ID: <20190709113633.GL2911@vkoul-mobl> (raw)
In-Reply-To: <20190709105211.11741-3-ckeepax@opensource.cirrus.com>
On 09-07-19, 11:52, Charles Keepax wrote:
> Partial drain and next track are intended for gapless playback and
> don't really have an obvious interpretation for a capture stream, so
> makes sense to not allow those operations on capture streams. Drain
Sounds right
> would make sense on a capture stream but currently the implementation
> of drain involves the kernel waiting for the DSP to consume its
> available data, whereas a capture drain would involve waiting for
> user-space to consume the data available on the DSP. Disallow drain
> on capture streams until that is implemented.
Well it in unclear to me about the support required in kernel! Kernel
issues drain request to DSP and waits for that to be done. When DSP has
encoded and copied the data the notification should make drain complete.
So I dont see anything in kernel required for that
>
> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
> ---
> sound/core/compress_offload.c | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/sound/core/compress_offload.c b/sound/core/compress_offload.c
> index e1a216fd832f9..c7d56cee0d510 100644
> --- a/sound/core/compress_offload.c
> +++ b/sound/core/compress_offload.c
> @@ -829,6 +829,10 @@ static int snd_compr_drain(struct snd_compr_stream *stream)
> break;
> }
>
> + /* drain not implemented for capture streams yet */
> + if (stream->direction == SND_COMPRESS_CAPTURE)
> + return -EPERM;
> +
> retval = stream->ops->trigger(stream, SND_COMPR_TRIGGER_DRAIN);
> if (retval) {
> pr_debug("SND_COMPR_TRIGGER_DRAIN failed %d\n", retval);
> @@ -847,6 +851,10 @@ static int snd_compr_next_track(struct snd_compr_stream *stream)
> if (stream->runtime->state != SNDRV_PCM_STATE_RUNNING)
> return -EPERM;
>
> + /* next track doesn't have any meaning for capture streams */
> + if (stream->direction == SND_COMPRESS_CAPTURE)
> + return -EPERM;
> +
> /* you can signal next track if this is intended to be a gapless stream
> * and current track metadata is set
> */
> @@ -874,6 +882,10 @@ static int snd_compr_partial_drain(struct snd_compr_stream *stream)
> break;
> }
>
> + /* partial drain doesn't have any meaning for capture streams */
> + if (stream->direction == SND_COMPRESS_CAPTURE)
> + return -EPERM;
> +
> /* stream can be drained only when next track has been signalled */
> if (stream->next_track == false)
> return -EPERM;
> --
> 2.11.0
--
~Vinod
next prev parent reply other threads:[~2019-07-09 11:39 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-09 10:52 [PATCH 1/4] ALSA: compress: Fix regression on compressed capture streams Charles Keepax
2019-07-09 10:52 ` [PATCH 2/4] ALSA: compress: Prevent bypasses of set_params Charles Keepax
2019-07-09 10:52 ` [PATCH 3/4] ALSA: compress: Don't allow drain operations on capture streams Charles Keepax
2019-07-09 11:36 ` Vinod Koul [this message]
2019-07-09 12:58 ` Charles Keepax
2019-07-09 10:52 ` [PATCH 4/4] ALSA: compress: Be more restrictive about when a drain is allowed Charles Keepax
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190709113633.GL2911@vkoul-mobl \
--to=vkoul@kernel.org \
--cc=alsa-devel@alsa-project.org \
--cc=ckeepax@opensource.cirrus.com \
--cc=patches@opensource.cirrus.com \
--cc=tiwai@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox