From: Nate Case <ncase@xes-inc.com>
To: alsa-devel@alsa-project.org
Subject: snd_pcm_avail() and snd_pcm_avail_update() always returns buffer_size
Date: Wed, 10 Apr 2013 10:09:16 -0500 (CDT) [thread overview]
Message-ID: <9206524.125916.1365606552656.JavaMail.ncase@ncase1> (raw)
In-Reply-To: <7690603.125468.1365197646502.JavaMail.ncase@natec>
Hello,
I'm debugging an issue where both snd_pcm_avail_update() and
snd_pcm_avail() are always returning buffer_size, even after
successfully calling snd_pcm_writei() repeatedly.
This is causing problems when I first start playback. My goal was to
fill up the playback buffer until it's almost full when first starting,
and then enter my regular playback loop where I write period_size
at a time.
However, I'm not able to tell when the playback buffer is full from
snd_pcm_avail() or snd_pcm_avail_update() as expected. In case it's
useful, the full snd_pcm_dump() output of the playback device is
available here:
http://pastebin.com/ai3e0cer
To summarize the configuration, I'm using a chain of PCM devices
that looks like this:
Soft volume ->
Rate conversion ->
Route conversion ->
HW PCM (USB audio)
(notes: buffer_size for soft volume PCM is 640 [80ms], period size is
160 [20ms]. buffer_size for HW PCM is 3846 and period_size is 960. I'm
opening the playback device in blocking mode, although the same thing
appears to happen in non-blocking mode)
Here is the sequence of events I'm seeing:
1) Call snd_pcm_writei() with 160 frames successfully. Function
returns immediately in less than 1ms because the buffer is empty.
2) snd_pcm_avail() returns 640 (expected 640-160 = 480)
snd_pcm_dump() shows the following for the HW PCM device:
appl_ptr : 960
hw_ptr : 0
3) Call snd_pcm_writei() again with 160 frames successfully. Function
returns immediately again.
4) snd_pcm_avail() returns 640 (expected 480-160 = 320)
snd_pcm_dump() shows the following for the HW PCM device:
appl_ptr : 1920
hw_ptr : 0
5) Cycle repeats two more times, with these values for apply_ptr/hw_ptr
reported after each subsequent snd_pcm_writei() call:
appl_ptr : 2880
hw_ptr : 288
appl_ptr : 3840
hw_ptr : 288
All along, snd_pcm_avail() returns 640.
6) Call snd_pcm_writei() with 160 frames again. This time, the buffer
is actually full, so it blocks for 20 ms as expected.
7) snd_pcm_avail() returns 640
snd_pcm_dump() shows the following for the HW PCM device:
appl_ptr : 4800
hw_ptr : 960
8) Continue this loop, with each subsequent snd_pcm_writei() call
blocking for 20 ms, while snd_pcm_avail() always returns 640.
Any ideas on why this could be happening? Or am I misunderstanding
something here?
Thanks,
Nate Case <ncase@xes-inc.com>
next parent reply other threads:[~2013-04-10 15:09 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <7690603.125468.1365197646502.JavaMail.ncase@natec>
2013-04-10 15:09 ` Nate Case [this message]
2013-04-17 19:00 ` snd_pcm_avail() and snd_pcm_avail_update() always returns buffer_size Nate Case
2013-04-20 16:53 ` Gabriel M. Beddingfield
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=9206524.125916.1365606552656.JavaMail.ncase@ncase1 \
--to=ncase@xes-inc.com \
--cc=alsa-devel@alsa-project.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox