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

Stephen Sinclair sinclair at music.mcgill.ca
Mon Dec 20 13:50:53 PST 2010


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-ALSA-Default-to-4-periods-unless-minimal-latency-is-.patch
Type: application/octet-stream
Size: 964 bytes
Desc: not available
Url : http://ccrma-mail.stanford.edu/pipermail/stk/attachments/20101220/89c1b310/attachment.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-ALSA-Don-t-set-the-number-of-periods-unless-it-was-r.patch
Type: application/octet-stream
Size: 2023 bytes
Desc: not available
Url : http://ccrma-mail.stanford.edu/pipermail/stk/attachments/20101220/89c1b310/attachment-0001.obj 


More information about the Stk mailing list