[Ffmpeg-devel] alsa input / output
Sat Mar 24 20:17:58 CET 2007
On Sat, Mar 24, 2007 at 07:15:32PM +0100, Michael Niedermayer wrote:
> On Sat, Mar 24, 2007 at 10:57:33AM +0100, Reimar D?ffinger wrote:
> > Hello,
> > On Sat, Mar 24, 2007 at 09:58:40AM +0100, Luca Barbato wrote:
> > > Reimar D?ffinger wrote:
> > > > ALSA always creates flames because quite a few people feel that
> > > > suboptimal design choices are made without the people involved
> > > > recognizing the problems. Which is of course amplified by the fact that
> > > > nobody here is well-informed about it ;-). Unfortunately it seems to me
> > > > that all sound interfaces except maybe jack fully succeed in either making
> > > > simple stuff very difficult (pulseaudio, ALSA) or making advanced stuff
> > > > impossible (arts, esd) (or in the case of OSS having an outdated and
> > > > often broken interface/drivers).
> > >
> > > What about having jack support then ? =)
> > Don't expect too much, but if you send your patch so I can have a look
> > how to do it from the ffmpeg side I could give it a try, I should still
> > remember a bit how to use jack from MPlayer.
> > Btw. is there a ringbuffer implementation in ffmpeg that allows reader
> > and write to be a different thread (aka. the lock-free
> > partially-threadsafe variant)?
> i dunno, check fifo.c/h if its not partially threadsafe, making it so is
> welcome ...
imo it should be welcome as long as it does not depend on the library
calling pthread locking functions. otherwise you had the issue that
whether or not the api is thread-safe depends on how it was compiled,
which is very bad if it's going to be installed systemwide..
as long as it's the lock-free thing, this sounds good! but is there
really such a thing as lock-free in this age where broken cpus like
ppc allow memory writes to take place in any order unless you insert
mem barriers? (and gcc is too broken to insert mem barriers itself
when you use the volatile keyword...)
More information about the ffmpeg-devel