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

PrevNext  Index
DateSun, 08 Mar 2009 00:51:48 +0100
From Olivier Guilyardi <[hidden] at samalyse dot com>
ToPaul Davis <[hidden] at linuxaudiosystems dot com>
Cc[hidden] at lists dot linuxaudio dot org, Guillaume Pellerin <[hidden] at parisson dot com>, FFmpeg development discussions and patches <[hidden] at mplayerhq dot hu>, [hidden] at jackaudio dot org
Follow-UpMichael Niedermayer Re: [LAD] [FFmpeg-devel] [Jack-Devel] [PATCH] libavdevice: JACK demuxer
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.
> 
> 
PrevNext  Index

1236469934.17554_0.ltw:2,a <49B30894.9010501 at samalyse dot com>