[LAD] [Jack-Devel] [FFmpeg-devel] [PATCH] libavdevice: JACK demuxer

[Olivier Guilyardi]

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.
> 
>