Re: simple PCM helper function

Jaroslav Kysela
2006-01-10T12:26:59Z

On Mon, 9 Jan 2006, James Courtier-Dutton wrote:

> Jaroslav Kysela wrote:
>
> > Hi all,
> >
> > I added three functions to alsa-lib - PCM API:
> >
> > /*
> > * application helpers - these functions are implemented on top
> > * of the basic API
> > */
> >
> > int snd_pcm_recover(snd_pcm_t *pcm, int err, int silent);
> > int snd_pcm_set_params(snd_pcm_t *pcm,
> > snd_pcm_format_t format,
> > snd_pcm_access_t access,
> > unsigned int channels,
> > unsigned int rate,
> > int soft_resample,
> > unsigned int latency);
> > int snd_pcm_get_params(snd_pcm_t *pcm,
> > snd_pcm_uframes_t *buffer_size,
> > snd_pcm_uframes_t *period_size);
> >
> > These functions are intended for "lazy" people who are doing just
> > simple command line players or recorders and don't want to bother with
> > the ALSA details. The implementation comes from strong attitude against
> > alsa-lib on LKML by some people.
> > Please, look to them and tell me, if I missed something useable.
> > The really "minimalistic" example using these functions is in
> > alsa-lib/test/pcm_min.c (compile the code typing 'make pcm_min' in the
> > test directory).
> >
> > Jaroslav
> >
> >
> Would it not have been better to provide a similar few function calls,
> but use a method similar to MaxOSX. I.e. callback based. I.e. Set
> parameters, and one of the parameters is the callback function of the
> user's program. The application would then not care how big the sound
> hardware buffer size was.

Yes, the callback method might be an alternative, but the standard way is
simply write samples to device, so we shouldn't remove it.

The callback would just be:

> snd_pcm_callback(void *private, /* Private information provided by the
> user application at set_params call */ void *buffer, /* Frame buffer */
> snd_pcm_uframes_t number_of_samples_please, /* number of samples for
> frame buffer */
> snd_pcm_format_t format, /* Might not be needed, but the same
> format. */
> snd_pcm_uframe_t delay, /* Estimate of delay between the current
> time, and the time when the same will reach the DAC */
> int status); /* RUNNING, XRUN etc. */
>
> Where "number_of_samples_please" is likely to be the period size.
> One could therefore drop the

You must also add a new function "snd_pcm_check_for_space()" or something
like this. The app callback will be called from this function. Also, the
app callback function should probably take same parameters as
snd_pcm_mmap_begin() handles (areas, offset), because we support more
ring buffer organization schemes.

So, to all others, is this mechanism worth to implement?

audio_callback(areas, offset, samples, status) {
if (status)
status = snd_pcm_recover();
if (status) {
/* handle error here */
return;
}
... process new samples here, i/o from areas at specified offset ...
}

main() {
snd_pcm_open()
snd_pcm_set_params()
snd_pcm_set_callback(audio_callback);
while (1) {
poll();
if (poll_set_audio_fd)
if (snd_pcm_check_for_space() < 0)
/* handle error here */
}
}
Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs