[FFmpeg-devel] [Jack-Devel] [PATCH] libavdevice: JACK demuxer
Sun Mar 15 11:49:59 CET 2009
Paul Davis <paul at linuxaudiosystems.com> writes:
> 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.
Have you considered the option that you have been wrong for more than
> 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.
Of course you'd say that. Before you do, however, please compare
FFmpeg's version of some other bits with others out there that we
could have copied. Our code is generally both smaller and more
efficient. What makes you think the Jack ring buffer is so perfect
that it cannot possibly be improved upon.
> furthermore, you would be very foolish to imagine (especially based
> on your incredibly naive comments about uint8_t)
What exactly are you referring to here?
> 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,
Proof by old age doesn't sit well with us.
> and we are absolutely confident that our buffers are
Proof by absolute self-conviction doesn't impress us either. If it
did, we'd by now be believing in very many gods indeed.
> (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.
Writing SMP-safe code using shared buffers without any form of memory
barriers is next to impossible. This is because the exact time and
order in which writes happen is generally unpredictable. If you claim
to have solved this problem you'll have to show something better than
hand-waving as proof.
> if you don't understand why it works without them, then you should
> probably refrain from commenting on the design of these buffers at
I'm guessing it works because you use only x86 and because you got
lucky. Many other architectures have much more relaxed memory models,
particularly with regards to ordering and SMP visibility.
Your attitude reminds me of an insulted religious fanatic, desperately
searching for arguments in favour his belief of choice, without
If you want to discuss technical matters, please use technical
arguments. If you have none, please go away.
mans at mansr.com
More information about the ffmpeg-devel