Alsa-Devel Archive on lore.kernel.org
 help / color / Atom feed
From: Vinod Koul <vkoul@kernel.org>
To: Takashi Iwai <tiwai@suse.de>
Cc: 'Pierre-Louis Bossart' <pierre-louis.bossart@linux.intel.com>,
	alsa-devel@alsa-project.org, khw0178.kim@samsung.com,
	kimty@samsung.com, s47.kang@samsung.com, lgirdwood@gmail.com,
	tiwai@suse.com, hmseo@samsung.com,
	Gyeongtaek Lee <gt82.lee@samsung.com>,
	pilsun.jang@samsung.com, tkjung@samsung.com
Subject: Re: [PATCH] ALSA: compress: allow pause and resume during draining
Date: Thu, 1 Oct 2020 15:59:38 +0530
Message-ID: <20201001102938.GU2968@vkoul-mobl> (raw)
In-Reply-To: <s5heemlklo0.wl-tiwai@suse.de>

On 29-09-20, 10:54, Takashi Iwai wrote:
> On Tue, 29 Sep 2020 10:40:51 +0200,
> Gyeongtaek Lee wrote:
> > 
> > On 9/29/20 04:13 PM, Takashi Iwai wrote:
> > >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.
> > Thank you for the review.
> > I think that I should resend the original patch.
> 
> Let's wait a bit for other opinions.  We may add rather a new flag
> instead of introducing a new state, too, for example.

I was out for a week, back now ;-)

So bigger question is if kernel should handle this change or we ask
userspace to handle this. Userland knows that bit rate is less so small
buffer can be for longer duration so instead of sending dumb X bytes,
should it not scale the buffer based on bit rate?

From that premise the partial_drain should be invoked only for last
write().

Also, I am bit skeptical for adding changes to states while we are
draining (that too partial one)... is this change driving complex
changes and should we push back to have this implemented better in
userland..?

> 
> Also, I'm not sure about any side-effect to drivers that expect the
> pause only during the running state.  We might need some check for a
> capability flag?
> 
> In anyway, the timing is bad; it's too late for 5.10 to apply such a
> core change.  Can we postpone this for 5.11?

Yes this needs more thinking, I am still not convinced kernel should
handle it!

Regards
-- 
~Vinod

  parent reply index

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20200929084051epcas2p35fb2228ed1bdfce6a7ddf5b37c944823@epcas2p3.samsung.com>
2020-09-29  8:40 ` Gyeongtaek Lee
2020-09-29  8:54   ` Takashi Iwai
2020-09-29  9:17     ` Gyeongtaek Lee
2020-09-29 14:00       ` Pierre-Louis Bossart
2020-10-01 10:29     ` Vinod Koul [this message]
2020-10-01 15:28       ` Pierre-Louis Bossart
2020-10-06  6:21         ` Vinod Koul
2020-10-06 14:57           ` Pierre-Louis Bossart
2020-10-08  9:49             ` Gyeongtaek Lee
2020-10-09 15:13               ` Takashi Iwai
2020-10-09 17:43                 ` Jaroslav Kysela
2020-10-10  9:08                   ` Takashi Iwai
2020-10-12  5:25                     ` Vinod Koul
2020-10-12  7:01                       ` Takashi Iwai
2020-10-12 12:24                         ` Vinod Koul
2020-10-12 13:29                           ` Jaroslav Kysela
2020-10-12 13:55                             ` Vinod Koul
2020-10-12 14:10                               ` Jaroslav Kysela
2020-10-12 14:21                                 ` Takashi Iwai
2020-10-12 14:46                                   ` Jaroslav Kysela
2020-10-12 14:59                                     ` Takashi Iwai
2020-10-15 10:47                                       ` Gyeongtaek Lee
2020-10-20  5:23                                         ` Gyeongtaek Lee
2020-10-26  9:18                                         ` Gyeongtaek Lee
2020-10-26 17:01                                           ` Takashi Iwai
2020-10-27  1:56                                             ` Gyeongtaek Lee
     [not found] <CGME20200928105009epcas2p4a65d50d9d09800281395a490d1844ef3@epcas2p4.samsung.com>
2020-09-28 10:50 ` Gyeongtaek Lee
2020-09-28 11:13   ` Jaroslav Kysela
2020-09-28 14:34     ` Pierre-Louis Bossart
2020-09-29  1:51       ` Gyeongtaek Lee
2020-09-29  7:12         ` Takashi Iwai
2020-09-29 17:27           ` Jaroslav Kysela
2020-09-30  9:35             ` Takashi Iwai
2020-09-30  9:57               ` Jaroslav Kysela
2020-09-30 10:33                 ` Takashi Iwai
2020-09-30 11:23                   ` Jaroslav Kysela
2020-10-01 10:35               ` Vinod Koul

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=20201001102938.GU2968@vkoul-mobl \
    --to=vkoul@kernel.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=gt82.lee@samsung.com \
    --cc=hmseo@samsung.com \
    --cc=khw0178.kim@samsung.com \
    --cc=kimty@samsung.com \
    --cc=lgirdwood@gmail.com \
    --cc=pierre-louis.bossart@linux.intel.com \
    --cc=pilsun.jang@samsung.com \
    --cc=s47.kang@samsung.com \
    --cc=tiwai@suse.com \
    --cc=tiwai@suse.de \
    --cc=tkjung@samsung.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

Alsa-Devel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/alsa-devel/0 alsa-devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 alsa-devel alsa-devel/ https://lore.kernel.org/alsa-devel \
		alsa-devel@alsa-project.org
	public-inbox-index alsa-devel

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.alsa-project.alsa-devel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git