From: Andrew Eikum <aeikum@codeweavers.com>
To: Jonathan Andrews <jon@jonshouse.co.uk>
Cc: alsa-devel@alsa-project.org
Subject: Re: Trying to understand alsa
Date: Thu, 12 Jan 2012 16:12:18 -0600 [thread overview]
Message-ID: <20120112221218.GE24575@foghorn.codeweavers.com> (raw)
In-Reply-To: <1326404651.22083.28.camel@jonspc>
On Thu, Jan 12, 2012 at 09:44:11PM +0000, Jonathan Andrews wrote:
> I have an application that works using 512 sample packets of 22050Hz 16
> bit mono audio. The 'receiver' takes many audio streams from a network
> via UDP, at the moment it pipes them into pulse.
>
> Can alsa buffer audio. At the moment every time I and set an audio
> buffer size I get a negative response from
> snd_pcm_hw_params_set_buffer_size . I'm somewhat confused about the
> units alsa uses ...
>
You don't want to over-specify your requirements. You require a buffer
size of "at least" 3 * 512 frames. So use set_buffer_size_min().
Otherwise ALSA will try to set exactly that buffer size, which can
fail.
Check the function signatures for units. Notice that
set_buffer_size*() all take snd_pcm_uframes_t, that is, the number of
frames you want to store. In ALSA terms, a "frame" is a set of a
single sample for every channel. Since you have mono audio, a frame
and a sample are actually the same unit (for 16 bit stereo audio,
1 frame = 2 samples = 32 bits).
> What I want to do is tell ALSA to hold a buffer of 3 of my packets (3 x
> 1024Bytes, thats 512 x 16 bit samples) while I feed extra packets (1K
> Byte, 512 samples per buffer) in for playback. The packets are arriving
> at roughly the correct rate, I just need a buffer to iron out any
> jitter in network transmit, do I have to do this myself ?
>
> Can somebody help by telling me which numbers I push into which places
> to make it work ?
>
> At the moment I get i keep getting a broken pipe, if I underrun how can
> I make it just wait for me ?
>
If a packet arrives very late (and one will, eventually), you will
underrun. That's unavoidable. You can check for SND_PCM_STATE_XRUN
from snd_pcm_state(). It's undocumented, but you need to call
snd_pcm_avail_update() first to get an accurate reading from
snd_pcm_state(). When an underrun occurs, recover with
snd_pcm_recover() and then start writing data again.
If a packet arrives early, you'll need to check that the ALSA buffer
isn't full (see snd_pcm_avail_update()), and store it within your
application to write later if it is full.
There's some mostly-accurate information here:
http://0pointer.de/blog/projects/guide-to-sound-apis.html
As with all ALSA documentation, it is confusing and often incorrect,
but it's probably the most helpful document I've found.
Good luck!
Andrew
next prev parent reply other threads:[~2012-01-12 22:12 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-12 21:44 Trying to understand alsa Jonathan Andrews
2012-01-12 21:50 ` Fons Adriaensen
2012-01-12 22:12 ` Andrew Eikum [this message]
[not found] ` <1326410207.23310.17.camel@jonspc>
2012-01-13 15:10 ` Andrew Eikum
-- strict thread matches above, loose matches on Subject: below --
2012-01-12 23:36 Jonathan Andrews
2012-01-12 23:36 Jonathan Andrews
2012-01-12 23:45 Jonathan Andrews
2012-01-13 1:25 ` Jonathan Andrews
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=20120112221218.GE24575@foghorn.codeweavers.com \
--to=aeikum@codeweavers.com \
--cc=alsa-devel@alsa-project.org \
--cc=jon@jonshouse.co.uk \
/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;
as well as URLs for NNTP newsgroup(s).