Messages in this thread | | | Date | Thu, 5 Jan 2006 15:51:01 +0100 | From | Olivier Galibert <> | Subject | Re: [OT] ALSA userspace API complexity |
| |
On Thu, Jan 05, 2006 at 03:24:18PM +0100, Jaroslav Kysela wrote: > This sentence makes this in my mind: real people = lazy people. The error > codes are documented well.
Actual alsa reference documentation:
int snd_pcm_prepare(snd_pcm_t *pcm)
Prepare PCM for use.
Parameters: pcm PCM handle
Returns: 0 on success otherwise a negative error code
[Beautifully documented error codes and causes]
snd_pcm_sframes_t snd_pcm_writei(snd_pcm_t * pcm, const void *buffer, snd_pcm_uframes_t size )
Write interleaved frames to a PCM.
Parameters: pcm PCM handle buffer frames containing buffer size frames to be written
Returns: a positive number of frames actually written otherwise a negative error code
Return values: -EBADFD PCM is not in the right state (SND_PCM_STATE_PREPARED or SND_PCM_STATE_RUNNING) -EPIPE an underrun occurred -ESTRPIPE a suspend event occurred (stream is suspended and waiting for an application recovery)
If the blocking behaviour is selected, then routine waits until all requested bytes are played or put to the playback ring buffer. The count of bytes can be less only if a signal or underrun occurred.
If the non-blocking behaviour is selected, then routine doesn't wait at all.
[Count of bytes less than the frame count when an underrun, which returns -EPIPE, happened? -EBADFD when the state is XRUN (not it doesn't)? Cause and handling of suspend events?]
Anybody who says the alsa documentation is good never had to use it. At that point I know my simple playing code is incorrect and I have no clue on how to fix it.
> Also, aplay in the alsa-utils package has > good error recovery code including test pcm.c utility in alsa-lib.
A sleep(1) in the error recovery path? Are you people nuts?
Incidentally:
- "A small demo which sends a simple sinusoidal wave to the speakers" requiring close to 900 lines is demented. That's the size of glxgears.c, with 50% of that one being printer support. A complete smartflow example getting a sound stream on the network and playing it with oss takes 160 lines, with 20 lines of copyright-ish at the start. The actual sound part of that is _30_ lines.
- Error and state handling after writei changes depending on the call. We're supposed to guess which one is correct?
Make simple things simple, guys.
OG. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |