From: Clemens Ladisch <clemens@ladisch.de>
To: Trent Piepho <tpiepho@gmail.com>
Cc: alsa-devel@alsa-project.org
Subject: Re: snd_pcm_drain and partial periods
Date: Thu, 24 Nov 2011 15:17:42 +0100 [thread overview]
Message-ID: <4ECE5206.4060408@ladisch.de> (raw)
In-Reply-To: <CA+7tXii1Ah5Z7UxyHr0=jNALt-qORQ0fG8WcNiAGWuSxbMq=7g@mail.gmail.com>
Trent Piepho wrote:
> Say an application does not write a full multiple of the period size
> with snd_pcm_writei(). It's playing a clip and the clip ends and it
> doesn't happen to end on a multiple of 6000 frames or whatever the
> period size is.
>
> Now the application calls snd_pcm_drain() to wait for the clip to finish.
>
> How does the driver know to stop when it gets to the end of the
> supplied data?
It doesn't.
> It seems like the driver will keep playing until it calls
> snd_pcm_period_elapsed() at the end of the final period. Then the
> alsa pcm layer will call the ->trigger() method and stop the stream.
Yes.
> Hopefully before the driver has started the next DMA for the next
> period!
Let's hope that the FIFOs are large enough so that the actual playback
hasn't yet reached the period boundary ...
> I don't see any documentation for snd_pcm_drain() that says it will
> keep playing until it finishes a period, even if the data runs out
> before hand. "For playback wait for all pending frames to be played
> and then stop the PCM." Seems pretty clear that only the pending
> frames are played and not the rest of a period.
ALSA will stop the device when it realizes that it has run out of data
(just like an underrun). This might happen before the period boundary
if there is some call to snd_pcm_status() or _delay() that reads the
current position (and if the hardware also supports reading the current
position).
It's racy and undocumented, but there's nothing a driver can do about
this.
Regards,
Clemens
next prev parent reply other threads:[~2011-11-24 14:16 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CA+7tXihfkZd6+UmnwJiyLgwo+6PoU9fWvzNhz7FKzy7DNgAWMw@mail.gmail.com>
2011-11-23 23:44 ` snd_pcm_drain and partial periods Trent Piepho
2011-11-24 14:17 ` Clemens Ladisch [this message]
2011-11-25 16:37 ` Trent Piepho
2011-11-25 17:38 ` Clemens Ladisch
2011-11-27 6:05 ` Trent Piepho
2011-11-28 1:16 ` 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=4ECE5206.4060408@ladisch.de \
--to=clemens@ladisch.de \
--cc=alsa-devel@alsa-project.org \
--cc=tpiepho@gmail.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 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.