* snd_pcm_wait function @ 2012-11-10 16:43 Enno Fennema 2012-11-10 17:20 ` Clemens Ladisch 0 siblings, 1 reply; 8+ messages in thread From: Enno Fennema @ 2012-11-10 16:43 UTC (permalink / raw) To: alsa-devel The documentation says this functions waits for the pcm to become ready for I/O. I am not sure what ready means in this context. I assume entering the PREPARED state. Is that correct? Is there a function to wait for entering the SETUP state. In particular I would like to wait for pcm_snd_drain to finish. Appreciate any help. Enno Fennema ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: snd_pcm_wait function 2012-11-10 16:43 snd_pcm_wait function Enno Fennema @ 2012-11-10 17:20 ` Clemens Ladisch 0 siblings, 0 replies; 8+ messages in thread From: Clemens Ladisch @ 2012-11-10 17:20 UTC (permalink / raw) To: Enno Fennema; +Cc: alsa-devel Enno Fennema wrote: > The documentation says this functions waits for the pcm to become ready for I/O. > I am not sure what ready means in this context. Ready for playback/capture, i.e., some frames are available. > Is there a function to wait for entering the SETUP state. In particular I would > like to wait for pcm_snd_drain to finish. This is not possible. alsa-lib is not thread-safe, so while another thread is executing snd_pcm_drain, you cannot access the same PCM device. Let the other thread send a message after snd_pcm_drain has finished. Regards, Clemens ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: snd_pcm_wait function @ 2012-11-12 7:23 Enno Fennema 2012-11-12 7:36 ` Clemens Ladisch 0 siblings, 1 reply; 8+ messages in thread From: Enno Fennema @ 2012-11-12 7:23 UTC (permalink / raw) To: clemens; +Cc: alsa-devel, daniellsanz2 Thanks for your reply. I may not have expressed myself clearly. I appear to have the opposite problem from Daniel Sanz re Non-blocking snd_pcm_drain (also posted 10 Nov). He wants the new sound to start immediately. I want to close the pcm AFTER the sound finished. The docs say calling drain() puts the pcm in the DRAINING state. When I obtain the state immediately after drain() it is already SETUP. I hoped a state change from DRAINING to SETUP would be the right time to close the pcm but there appears to be no such state change. Currently I solved my problem by a usleep() based on an estimate of the time needed to finish playing the last samples in the buffer. If there is a more elegant way I would like to know. Otherwise I will stick with usleep(), Regards, Enno ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: snd_pcm_wait function 2012-11-12 7:23 Enno Fennema @ 2012-11-12 7:36 ` Clemens Ladisch 2012-11-12 20:57 ` Trent Piepho 0 siblings, 1 reply; 8+ messages in thread From: Clemens Ladisch @ 2012-11-12 7:36 UTC (permalink / raw) To: Enno Fennema; +Cc: alsa-devel, daniellsanz2 Enno Fennema wrote: > I want to close the pcm AFTER the sound finished. Then close it after snd_pcm_drain() has returned. > The docs say calling drain() puts the pcm in the DRAINING state. It also waits until the device has drained (unless the device is in non-blocking mode). > When I obtain the state immediately after drain() it is already SETUP. > I hoped a state change from DRAINING to SETUP would be the right time > to close the pcm but there appears to be no such state change. That change happens immediately before snd_pcm_drain() returns. Regards, Clemens ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: snd_pcm_wait function 2012-11-12 7:36 ` Clemens Ladisch @ 2012-11-12 20:57 ` Trent Piepho 2012-11-13 0:15 ` Daniel Sanz 0 siblings, 1 reply; 8+ messages in thread From: Trent Piepho @ 2012-11-12 20:57 UTC (permalink / raw) To: Clemens Ladisch; +Cc: Enno Fennema, alsa-devel, daniellsanz2 You do have to fill to a full period before calling drain, or it won't work in a very useful way. It only stops when periods elapse. So if you have a half full period of audio at the end of the buffer you'll get garbage when it plays to the end of that period before stopping. On Mon, Nov 12, 2012 at 2:36 AM, Clemens Ladisch <clemens@ladisch.de> wrote: > Enno Fennema wrote: >> I want to close the pcm AFTER the sound finished. > > Then close it after snd_pcm_drain() has returned. > >> The docs say calling drain() puts the pcm in the DRAINING state. > > It also waits until the device has drained (unless the device is in > non-blocking mode). > >> When I obtain the state immediately after drain() it is already SETUP. >> I hoped a state change from DRAINING to SETUP would be the right time >> to close the pcm but there appears to be no such state change. > > That change happens immediately before snd_pcm_drain() returns. > > > Regards, > Clemens > _______________________________________________ > Alsa-devel mailing list > Alsa-devel@alsa-project.org > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: snd_pcm_wait function 2012-11-12 20:57 ` Trent Piepho @ 2012-11-13 0:15 ` Daniel Sanz 2012-11-13 4:45 ` Trent Piepho 0 siblings, 1 reply; 8+ messages in thread From: Daniel Sanz @ 2012-11-13 0:15 UTC (permalink / raw) To: Trent Piepho; +Cc: Enno Fennema, alsa-devel, Clemens Ladisch Can I expect that there won't be any pending frames (so no need to call snd_pcm_drain) if I always use snd_pcm_writei to write multiples of the period size? And what if the sound is very short or the period size is big? the latency of hardware is negligible? Thanks, On Mon, Nov 12, 2012 at 9:57 PM, Trent Piepho <tpiepho@gmail.com> wrote: > You do have to fill to a full period before calling drain, or it won't > work in a very useful way. It only stops when periods elapse. So if > you have a half full period of audio at the end of the buffer you'll > get garbage when it plays to the end of that period before stopping. > > On Mon, Nov 12, 2012 at 2:36 AM, Clemens Ladisch <clemens@ladisch.de> wrote: >> Enno Fennema wrote: >>> I want to close the pcm AFTER the sound finished. >> >> Then close it after snd_pcm_drain() has returned. >> >>> The docs say calling drain() puts the pcm in the DRAINING state. >> >> It also waits until the device has drained (unless the device is in >> non-blocking mode). >> >>> When I obtain the state immediately after drain() it is already SETUP. >>> I hoped a state change from DRAINING to SETUP would be the right time >>> to close the pcm but there appears to be no such state change. >> >> That change happens immediately before snd_pcm_drain() returns. >> >> >> Regards, >> Clemens >> _______________________________________________ >> Alsa-devel mailing list >> Alsa-devel@alsa-project.org >> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: snd_pcm_wait function 2012-11-13 0:15 ` Daniel Sanz @ 2012-11-13 4:45 ` Trent Piepho 2012-11-16 10:41 ` Daniel Sanz 0 siblings, 1 reply; 8+ messages in thread From: Trent Piepho @ 2012-11-13 4:45 UTC (permalink / raw) To: Daniel Sanz; +Cc: Enno Fennema, alsa-devel, Clemens Ladisch snd_pcm_drain() will drain all the pending periods. In effect, it rounds up however many frames are left in the buffer to the next whole period. There is no way to just drain a partially full period. If you always wrote full periods, and didn't use non-blocking mode so that each writei call always wrote everything before returning, then you shouldn't have a partially filled period at the end of the buffer. ALSA has the exact buffer pointer value of the app pointer and also when a period should elapse, and could easily tell you the buffer fill value mod period size, but I don't think there is any API for that. On Mon, Nov 12, 2012 at 7:15 PM, Daniel Sanz <daniellsanz2@gmail.com> wrote: > Can I expect that there won't be any pending frames (so no need to > call snd_pcm_drain) if I always use snd_pcm_writei to write multiples > of the period size? > > And what if the sound is very short or the period size is big? the > latency of hardware is negligible? > > Thanks, > > On Mon, Nov 12, 2012 at 9:57 PM, Trent Piepho <tpiepho@gmail.com> wrote: >> You do have to fill to a full period before calling drain, or it won't >> work in a very useful way. It only stops when periods elapse. So if >> you have a half full period of audio at the end of the buffer you'll >> get garbage when it plays to the end of that period before stopping. >> >> On Mon, Nov 12, 2012 at 2:36 AM, Clemens Ladisch <clemens@ladisch.de> wrote: >>> Enno Fennema wrote: >>>> I want to close the pcm AFTER the sound finished. >>> >>> Then close it after snd_pcm_drain() has returned. >>> >>>> The docs say calling drain() puts the pcm in the DRAINING state. >>> >>> It also waits until the device has drained (unless the device is in >>> non-blocking mode). >>> >>>> When I obtain the state immediately after drain() it is already SETUP. >>>> I hoped a state change from DRAINING to SETUP would be the right time >>>> to close the pcm but there appears to be no such state change. >>> >>> That change happens immediately before snd_pcm_drain() returns. >>> >>> >>> Regards, >>> Clemens >>> _______________________________________________ >>> Alsa-devel mailing list >>> Alsa-devel@alsa-project.org >>> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: snd_pcm_wait function 2012-11-13 4:45 ` Trent Piepho @ 2012-11-16 10:41 ` Daniel Sanz 0 siblings, 0 replies; 8+ messages in thread From: Daniel Sanz @ 2012-11-16 10:41 UTC (permalink / raw) To: Trent Piepho; +Cc: Enno Fennema, alsa-devel, Clemens Ladisch Thanks, Trent, I've been playing a bit with snd_pcm_drain, snd_pcm_writei, blocking mode, non-blocking mode, etc. but even if I fill a full last period, audio does not play from the beginning to end unless I call snd_pcm_drain just before closing the stream. I think there is some concept that I'm missing about how ALSA works, or maybe my driver/ALSA configuration is broken (I'm using Arch Linux). Do you have a brief example of playing a short WAV file using ALSA? On Tue, Nov 13, 2012 at 5:45 AM, Trent Piepho <tpiepho@gmail.com> wrote: > snd_pcm_drain() will drain all the pending periods. In effect, it > rounds up however many frames are left in the buffer to the next whole > period. There is no way to just drain a partially full period. > > If you always wrote full periods, and didn't use non-blocking mode so > that each writei call always wrote everything before returning, then > you shouldn't have a partially filled period at the end of the buffer. > > ALSA has the exact buffer pointer value of the app pointer and also > when a period should elapse, and could easily tell you the buffer fill > value mod period size, but I don't think there is any API for that. > > On Mon, Nov 12, 2012 at 7:15 PM, Daniel Sanz <daniellsanz2@gmail.com> wrote: >> Can I expect that there won't be any pending frames (so no need to >> call snd_pcm_drain) if I always use snd_pcm_writei to write multiples >> of the period size? >> >> And what if the sound is very short or the period size is big? the >> latency of hardware is negligible? >> >> Thanks, >> >> On Mon, Nov 12, 2012 at 9:57 PM, Trent Piepho <tpiepho@gmail.com> wrote: >>> You do have to fill to a full period before calling drain, or it won't >>> work in a very useful way. It only stops when periods elapse. So if >>> you have a half full period of audio at the end of the buffer you'll >>> get garbage when it plays to the end of that period before stopping. >>> >>> On Mon, Nov 12, 2012 at 2:36 AM, Clemens Ladisch <clemens@ladisch.de> wrote: >>>> Enno Fennema wrote: >>>>> I want to close the pcm AFTER the sound finished. >>>> >>>> Then close it after snd_pcm_drain() has returned. >>>> >>>>> The docs say calling drain() puts the pcm in the DRAINING state. >>>> >>>> It also waits until the device has drained (unless the device is in >>>> non-blocking mode). >>>> >>>>> When I obtain the state immediately after drain() it is already SETUP. >>>>> I hoped a state change from DRAINING to SETUP would be the right time >>>>> to close the pcm but there appears to be no such state change. >>>> >>>> That change happens immediately before snd_pcm_drain() returns. >>>> >>>> >>>> Regards, >>>> Clemens >>>> _______________________________________________ >>>> Alsa-devel mailing list >>>> Alsa-devel@alsa-project.org >>>> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2012-11-16 10:41 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-11-10 16:43 snd_pcm_wait function Enno Fennema 2012-11-10 17:20 ` Clemens Ladisch -- strict thread matches above, loose matches on Subject: below -- 2012-11-12 7:23 Enno Fennema 2012-11-12 7:36 ` Clemens Ladisch 2012-11-12 20:57 ` Trent Piepho 2012-11-13 0:15 ` Daniel Sanz 2012-11-13 4:45 ` Trent Piepho 2012-11-16 10:41 ` Daniel Sanz
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox