7 Mar
2009
7 Mar
'09
7:51 p.m.
Michael, Paul has answered you on jack-devel. See below.
Note: I'm cross-posting this mail to linux-audio-dev, since Michael has recently
subscribed to it. At least, we should be able to discuss together in there.
Paul Davis wrote :
I have no idea how any of you have kept this
conversation going when one
of the main protagonists is not even subscribed to one of the two
mailing lists, and i suspect that one of the others isn't subscribed to
the other. perhaps the FFmpeg-devel list doesn't require membership.
anyway, i've finally had enough of reading Michael's stuff about
buffers, timing and so forth and felt obligated to comment.
michael - i would politely request that you stop shooting off at the
mouth about stuff that the JACK community has been dealing with for more
than 9 years.
you do not need to write your own ring buffer code - JACK's is LGPL'ed
and you are free (and probably even recommended) to copy it.
furthermore, you would be very foolish to imagine (especially based on
your incredibly naive comments about uint8_t) that you understand the
subtleties of these buffers. the JACK community (and a couple of other
exclusively audio-focused development groups) have been working with
this buffer design for many, many years, and we are absolutely confident
that our buffers are (a) SMP/multi-core safe (b) as efficient as they
can be without using assembler. you should also be aware that there are
very good arguments for the current structure of the ringbuffer code,
which explicitly does NOT use any memory barriers. if you don't
understand why it works without them, then you should probably refrain
from commenting on the design of these buffers at all.