[vlc-devel] lock-free and malloc-free audio output

[Rémi Denis-Courmont]

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.

-- 
Rémi Denis-Courmont
http://www.remlab.net/