All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Raymond Yau <superquad.vortex2@gmail.com>, Takashi Iwai <tiwai@suse.de>
Cc: ALSA Development Mailing List <alsa-devel@alsa-project.org>
Subject: Re: [RFC PATCH 2/4] ALSA: core: add .notify callback for pcm ops
Date: Thu, 09 Jul 2015 09:35:07 +0200	[thread overview]
Message-ID: <559E242B.7030003@linux.intel.com> (raw)
In-Reply-To: <CAN8cciYNQNXNzLgfFt=eXy4BVvYJaYfPPdwaCPUOJmuZO38LkQ@mail.gmail.com>

On 7/9/15 9:25 AM, Raymond Yau wrote:
>>>
>>> When appl_ptr is updated let low-level driver know.
>>>
>>> This is only enabled when the NO_REWIND hardware flag is used,
>>> so that the low-level driver/hardware to opportunistically pre-fetch
>>> data.
>>>
>>> FIXME: should we rely on .ack for this?
>>> Signed-off-by: Pierre-Louis Bossart <
> pierre-louis.bossart@linux.intel.com>
>>
>> Hmm, OK, so the forward is allowed but with workarounds...
>> But then why rewind won't work in a similar way?  DSP might be able to
>> cancel some of inflight data.
>>
>> In other words, I see no reason to strict notify callback only for
>> no_rewinds.  This is an optional ops in anyway.
>>
>> Also, I find the name "notify" a bit too ambiguous.  In this case,
>> it's notifying the applptr change.  So, a name related with the
>> function would be more understandable.
>>
>>
>
> If driver specify no rewind flag, should alsa lib
>
> 1) return error when application call snd_pcm_rewind() and
> snd_pcm_forward() ?

no, it would return 0 on rewind and the number of frames on forward. In 
other words the value returned is consistent with the function prototype 
which has no scope for errors.

> 2) return zero when call snd_pcm_rewindable() and snd_pcm_forwardable()

again zero for rewind and the actual number for forward.

> How can the application recover when hw_ptr is behind appl_ptr when stop
> threshold is set to boundary ?

Don't understand the question, there is no change here.

> Do you mean compressed audio stream don't support rewind and forward ?

You can't rewind in a compressed bitstream in general without losing 
sync or missing state information when there are dependencies between 
frames (linear prediction or filter with history). Forward is the same.
Some encoders allow for skips to well identified markers but random 
access is not possible or desired in general.

> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>

  reply	other threads:[~2015-07-09  7:35 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-08 10:10 [RFC PATCH 0/4] better support for bursty DMA usages Pierre-Louis Bossart
2015-07-08 10:10 ` [RFC PATCH 1/4] ALSA: core: let low-level driver or userspace disable rewinds Pierre-Louis Bossart
2015-07-08 14:21   ` Takashi Iwai
2015-07-08 16:58     ` Pierre-Louis Bossart
2015-07-11 17:06   ` Alexander E. Patrakov
2015-07-14  3:32     ` Raymond Yau
2015-07-14 17:39       ` Alexander E. Patrakov
2015-07-15  1:23         ` Raymond Yau
2015-07-15  4:51           ` Alexander E. Patrakov
2015-07-28 14:19     ` Pierre-Louis Bossart
2015-07-28 15:43       ` Alexander E. Patrakov
2015-07-29 17:46         ` Pierre-Louis Bossart
2015-07-30  6:11           ` Alexander E. Patrakov
2015-07-30 13:46             ` Pierre-Louis Bossart
2015-07-08 10:10 ` [RFC PATCH 2/4] ALSA: core: add .notify callback for pcm ops Pierre-Louis Bossart
2015-07-08 14:27   ` Takashi Iwai
2015-07-08 17:10     ` Pierre-Louis Bossart
2015-07-09 14:44       ` Takashi Iwai
2015-07-09  7:25     ` Raymond Yau
2015-07-09  7:35       ` Pierre-Louis Bossart [this message]
2015-07-08 10:10 ` [RFC PATCH 3/4] ALSA: core: add report of max dma burst Pierre-Louis Bossart
2015-07-08 14:37   ` Takashi Iwai
2015-07-08 17:46     ` Pierre-Louis Bossart
2015-07-10  2:35       ` Raymond Yau
2015-07-10 17:13         ` Lars-Peter Clausen
2015-07-11 17:46     ` Alexander E. Patrakov
2015-07-11 18:28       ` Jaroslav Kysela
2015-07-16  2:11         ` Raymond Yau
2015-07-08 10:10 ` [RFC PATCH 4/4] ALSA: hda: add default value for max_dma_burst Pierre-Louis Bossart
2015-07-08 14:31 ` [RFC PATCH 0/4] better support for bursty DMA usages Takashi Iwai
2015-07-08 17:50   ` Pierre-Louis Bossart
2015-07-15 10:14 ` Raymond Yau
2015-07-15 10:38   ` Alexander E. Patrakov
2015-07-22 14:44     ` Raymond Yau

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=559E242B.7030003@linux.intel.com \
    --to=pierre-louis.bossart@linux.intel.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=superquad.vortex2@gmail.com \
    --cc=tiwai@suse.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.