[vlc-devel] lock-free and malloc-free audio output
remi at remlab.net
Wed Nov 25 20:12:36 CET 2009
Le mercredi 25 novembre 2009 16:54:34 Jakob Leben, vous avez écrit :
> 2009/11/25 Rémi Denis-Courmont <remi at remlab.net>
> > > I believe the reason is usage of heap deallocation and mutex
> > > manipulation in jack processing callback of vlc-jack plugin. This seems
> > > to be unavoidable given the current aout API design.
> > Mutex manipulation are just like atomic operation in the non-contending
> > case.
> The problem is most probably the contending cases, since VLC gets kicked
> most often when seeking, which I think might be the time when output buffer
> fifo is most heavily accessed by many pipeline components (and the out fifo
> mutex is the only one accessed in jack process callback).
It's easy to check. Just call vlc_mutex_trylock() and see how often it fails.
> > Latencies upstream of the jack plugin seem like a likely culprit too...
> > It could also be page faults, though it seems unlikely.
> Do you mean concurrency in acquiring the output fifo lock because upstream
> components hold it for too long? From where I'm standing now I don't see
> other reason for upstream affecting jack plugin, since jackd doesn't care
> about data or time stamps or such, it only cares that the client process
> callback returns quickly enough, as much as I know...
I just mean that the whole VLC audio pipeline was not designed with real-time
in mind, especially now that alloca support has been removed...
> > first check what's really at fault...
> I think there is no allocation in jack process callback taking place, only
> deallocation of the buffer acquired from fifo. Maybe we could set up
> another plugin's thread to actually free buffers after use? Although free
> probably uses much less time than malloc, right?
I don't know.
More information about the vlc-devel