How to use ALSA's snd_pcm_writei() ?

Question

Hi everybody,

Can someone explain how snd_pcm_writei

snd_pcm_sframes_t snd_pcm_writei(snd_pcm_t *pcm, const void *buffer,
                                 snd_pcm_uframes_t size)

works?

I have used it like so:

for (int i = 0; i < 1; i++) {
   f = snd_pcm_writei(handle, buffer, frames);

   ...
}

Full source code at http://pastebin.com/m2f28b578

Does this mean, that I shouldn't give snd_pcm_writei() the number of all the frames in buffer, but only

sample_rate * latency = frames

?

So if I e.g. have: sample_rate = 44100 latency = 0.5 [s] all_frames = 100000

The number of frames that I should give to snd_pcm_writei() would be

sample_rate * latency = frames 44100*0.5 = 22050

and the number of iterations the for-loop should be?:

(int) 100000/22050 = 4; with frames=22050

and one extra, but only with

100000 mod 22050 = 11800

frames?

Is that how it works?

Louise

p_c_m.html#gf13067c0ebde29118ca05af76e5b17a9">http://www.alsa-project.org/alsa-doc/alsa-lib/group_p_c_m.html#gf13067c0ebde29118ca05af76e5b17a9

Answer 1

frames should be the number of frames (samples) you want to write from the buffer. Your system's sound driver will start transferring those samples to the sound card right away, and they will be played at a constant rate.

The latency is introduced in several places. There's latency from the data buffered by the driver while waiting to be transferred to the card. There's at least one buffer full of data that's being transferred to the card at any given moment, and there's buffering on the application side, which is what you seem to be concerned about.

To reduce latency on the application side you need to write the smallest buffer that will work for you. If your application performs a DSP task, that's typically one window's worth of data.

There's no advantage in writing small buffers in a loop - just go ahead and write everything in one go - but there's an important point to understand: to minimize latency, your application should write to the driver no faster than the driver is writing data to the sound card, or you'll end up piling up more data and accumulating more and more latency.

For a design that makes producing data in lockstep with the sound driver relatively easy, look at jack (http://jackaudio.org/) which is based on registering a callback function with the sound playback engine. In fact, you're probably just better off using jack instead of trying to do it yourself if you're really concerned about latency.