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

[Rémi Denis-Courmont]

On Wed, 25 Nov 2009 12:55:32 +0100, Jakob Leben <jakob.leben at gmail.com>
wrote:
> I've been testing the jack output with firewire jack backend. The
> jackd+firewire itself is unusable without being run with realtime
> priority, but in this case the server is much more demanding of
> clients and frequently kicks VLC at small buffer sizes.
> 
> 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.

> Does somebody have a suggestion? 

Latencies upstream of the jack plugin seem like a likely culprit too...
It could also be page faults, though it seems unlikely.

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

But that does not even solve allocation problems, does it? So, you should
first check what's really at fault...

-- 
Rémi Denis-Courmont