All of 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 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.