Alsa-Devel Archive on lore.kernel.org
 help / color / Atom feed
From: Vinod Koul <vkoul@kernel.org>
To: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Cc: alsa-devel@alsa-project.org, khw0178.kim@samsung.com,
	Takashi Iwai <tiwai@suse.de>,
	s47.kang@samsung.com, lgirdwood@gmail.com, tiwai@suse.com,
	kimty@samsung.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: Tue, 6 Oct 2020 11:51:05 +0530
Message-ID: <20201006062105.GQ2968@vkoul-mobl> (raw)
In-Reply-To: <2bf52360-bd11-b4cd-b255-8a5610b4aa5f@linux.intel.com>

On 01-10-20, 10:28, Pierre-Louis Bossart wrote:
> 
> 
> 
> > > > > 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?
> 
> what about variable bit-rate? or cases where you have a 'bit reservoir' in
> previous frames?
> 
> You really cannot in general translate bytes to time with compressed data,
> which is the reason we introduced the API in the first place...
> 
> Userspace *may* know the duration for specific formats or based on metadata,
> but in some cases the only way to know is actually to decode the data.
> 
> I suggest we keep the compressed API based on bytes and non-periodic events
> when the bytes were consumed/generated.

Changing the API away from bytes was not proposed so not sure...

The SM in kernel might be bit more convoluted so was wondering if we can
handle this in userland. The changelog for this patch says that for
test case was sending whole file, surely that is not an optimal approach.
Should we allow folks to send whole file to kernel and then issue
partial drain?

-- 
~Vinod

  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
2020-10-01 15:28       ` Pierre-Louis Bossart
2020-10-06  6:21         ` Vinod Koul [this message]
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=20201006062105.GQ2968@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