[Stk] default number of buffers should be higher for alsa

[Tristan Matthews]

Hi Stephen,

I wonder if this behaviour could be related to the fact that in
RtAudio, snd_pcm_open is called with the SND_PCM_ASYNC flag, rather
than the SND_PCM_NONBLOCK flag. The difference is described here:

    /* If SND_PCM_NONBLOCK is used, read / write access to the    */
    /* PCM device will return immediately. If SND_PCM_ASYNC is    */
    /* specified, SIGIO will be emitted whenever a period has             */
    /* been completely processed by the soundcard.                           */

source: http://www.suse.de/~mana/alsa090_howto.html

I noticed this because I've been comparing RtAudio's ALSA backend
against GStreamer's, and this one of the noticeable differences. If
RtAudio used the NONBLOCK flag, the steps would be to wait for free
space in the pcm buffer for at most a specified timeout (in GStreamer,
it's 4 times the period time) before writing to the pcm buffer,
something like:

snd_pcm_wait(handle[0], TIMEOUT);
result = snd_pcm_writei( handle[0], buffer, stream_.bufferSize );

I was thinking of starting a branch to improve RtApiAlsa, namely to
allow it to work when another program is using the sound card.
Resolving this clicking issue would be another good fix to have in
this branch.

-t

2010/12/20 Stephen Sinclair <sinclair at music.mcgill.ca>
>
> Hi,
>
> For a while I've had problems with lots of clicking when using RtAudio
> with ALSA--I thought it was my own applications until I realized that
> even the crtsine and playsaw examples also have this problem.  It's
> quite bad: there is a click after every buffer.  I was very confused
> because there are no xruns/underflows reported.  Moreover it seemed to
> happen more on some computers than others, particularly my eeePC
> netbook.  I finally took the time to investigate properly.
>
> As you might expect, the problem turned out to be related to the
> numberOfBuffers option.  Since I was not setting this, I assumed it
> would be a reliable constant, and I had tried fixing the problem by
> just using larger buffers.  Setting numberOfBuffers to 3 or 4 fixed
> the problem.
>
> I found at least one post on a message forum that seemed to indicate
> that this is a known problem with the HDA Intel chipset: it doesn't
> work correctly with only two buffers, and needs at least 3.  In my
> observation, even with 3 there are some subtle clicking sounds that go
> away with 4.
>
> While increasing the number of buffers does increase latency,
> interestingly it also allows you to reduce the buffer size, so you can
> sort of compensate. (To a point.  Once the "real" latency as reported
> by ALSA goes below about 300 frames, it starts to click like crazy, no
> matter what the period size/count.)
>
> Anyways, looking through RtAudio, it seems like if numberOfBuffers is
> not specified, it gets set to 2, which corresponds with the "minimal
> latency" option.  Imho, one solution would be to _default_ to a
> higher, safer value for number of buffers, and still allow users to
> specify lower numbers if they wish.  It seems to sort of defeat the
> point of having a flag to "minimize latency" if the lowest number of
> buffers is selected by default.
>
> Another solution would be to just not call the ..set_periods_near()
> function, which would correspond with system defaults.  In practice,
> at least on my system, this seems to have quite a lot more latency
> though, about 8000 frames.
>
> Either way I think it would be best to choose a safer default, say at
> least 4.  Users who need lower latency will be expected to set the
> flag or numberOfBuffers options as needed.
>
> Attached are two patches; one for a higher default, and one to not
> call the set_periods_near function if no number of buffers or the
> minimize latency flag was selected.  I'm not sure what the best option
> is, it depends on whether by-default low latency is considered
> important.
>
> Steve
>
> _______________________________________________
> Stk mailing list
> Stk at ccrma.stanford.edu
> http://ccrma-mail.stanford.edu/mailman/listinfo/stk
>



--
Tristan Matthews
email: tristan at sat.qc.ca
web: http://tristanswork.blogspot.com