Alsa-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
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>

       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