All of lore.kernel.org
 help / color / mirror / Atom feed
From: Clemens Ladisch <clemens@ladisch.de>
To: Patrick Lai <plai@codeaurora.org>
Cc: alsa-devel <alsa-devel@alsa-project.org>
Subject: Re: Handle large period size end-of-stream situation
Date: Wed, 03 Apr 2013 18:49:02 +0200	[thread overview]
Message-ID: <515C5D7E.6000609@ladisch.de> (raw)
In-Reply-To: <515C459A.5070209@codeaurora.org>

Patrick Lai wrote:
> Data is transferred in chunk equal to period size.

Data is transferred in whatever chunk size the hardware uses.

The period size specifies when the hardware raises an interrupt.
If some application is blocking, this interrupt is the only mechanism
by which userspace is woken up.

> At the end of playback, there may not be enough audio data left in the
> music stream to fill entire period. If remaining audio data only takes
> up very small chunk of period, playback takes longer to stop. Given
> that period size I have to deal with is quite large, this problem is
> observed easily. If my understanding is correct, what is the standard/
> recommended way of handling end of stream case?

I guess you wouldn't ask if your hardware supported smaller periods? ;-)

Use non-blocking writes, and use some other timer to wait for the actual
data to be played.  (But if the hardware cannot report the current
playback position accurately, ALSA won't notice that the playback has
reached the end.)


Regards,
Clemens

  reply	other threads:[~2013-04-03 16:49 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-03 15:07 Handle large period size end-of-stream situation Patrick Lai
2013-04-03 16:49 ` Clemens Ladisch [this message]
2013-04-03 22:22   ` Patrick Lai
2013-04-04  5:35 ` Gabriel M. Beddingfield
2013-04-04  9:27   ` Clemens Ladisch
2013-04-04 15:09     ` Gabriel M. Beddingfield
2013-04-04 17:08       ` Clemens Ladisch

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=515C5D7E.6000609@ladisch.de \
    --to=clemens@ladisch.de \
    --cc=alsa-devel@alsa-project.org \
    --cc=plai@codeaurora.org \
    /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.