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

[Jakob Leben]

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


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



> > gcc has some atomic operations built in,
> > is this a viable option?
>
> Yes and no. We would need to abstract them away because they are only
> available on a few platforms (and depending on version). On Windows, we may
> need to use Interlocked*() functions instead, and MacOS also has its own.
> In some cases, we would have to rely on inline assembly (e.g. ARMv6). And
> by default, we would have to emulate them.
>

Hmm, yes, I'm aware there is always portability problems with atomic
operations, one way or another...

But that does not even solve allocation problems, does it? So, you should
> 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20091125/375a63db/attachment.html>