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. http://www.alsa-project.org/alsa-doc/alsa-lib/_2test_2pcm_8c-example.html 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
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.