Re: Programming ALSA sound device.

[Jaroslav Kysela <perex@perex.cz>]

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.