[alsa-devel] Programming ALSA sound device.
perex at perex.cz
Fri Sep 17 10:15:46 CEST 2010
On Thu, 16 Sep 2010, Bankim Bhavsar wrote:
> Producer thread writes sound bytes worth 10 ms every 10 ms to a ring buffer.
> Consumer thread is responsible for writing sound bytes to ALSA sound
> device in a strictly non-blocking fashion.
> Consumer thread checks snd_pcm_avail/snd_pcm_avail_update, fetches
> minimum of sound bytes available in ring buffer and
> availFrames(returned by snd_pcm_avail_update) and writes to sound
> device using snd_pcm_writei().
> Consumer thread polls every 20 ms. However on consumer thread
> snd_pcm_avail/snd_pcm_avail_update() returns 0 at least 3-4 times
> consecutively (total 60-80 ms) and on every 5th-6th poll
> snd_pcm_avail/snd_pcm_avail_update returns full buffer size
> occasionally reporting an under-run. On an average, under-run is
> reported at least 10-15 times a minute which is not desirable.
> Following are the hardware and software parameter settings.
> hardware params:
> 16-bit 44100 stereo
> buffer time 200 ms
> period time 25 ms
> software params:
> start_threshold: full buffer size
> no setting for avail_min
> Alternatively I've tried using wait_for_poll() technique as mentioned
> in the example.
> However poll() unblocks very rapidly and producer ring buffer doesn't
> have enough bytes.
> What's the best technique for PCM playback for such use cases? Is it
> okay to skip calling snd_pcm_avail/snd_pcm_avail_update and directly
> attempt writing to ALSA sound device instead?
> Let me know if more information is required.
Show us snd_pcm_dump() output for your ALSA PCM handle and eventually, try
to compare your code with alsa-lib/test/latency.c what you're doing wrong.
Jaroslav Kysela <perex at perex.cz>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.
More information about the Alsa-devel