[alsa-devel] Trying to understand alsa
jon at jonshouse.co.uk
Fri Jan 13 00:45:40 CET 2012
On Thu, 2012-01-12 at 16:12 -0600, Andrew Eikum wrote:
> 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().
I cant find any reference to "set_buffer_size_min" in the ALSA API
documentation I have or the link you provided ?
snd_pcm_hw_params_set_buffer_time_near() is the closest and that seems
to take an argument in useconds.
> Otherwise ALSA will try to set exactly that buffer size, which can
> 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:
> As with all ALSA documentation, it is confusing and often incorrect,
> but it's probably the most helpful document I've found.
Many thanks for the help,
More information about the Alsa-devel