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. > > _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
