<div class="gmail_quote">2009/11/25 Rémi Denis-Courmont <span dir="ltr"><<a href="mailto:remi@remlab.net">remi@remlab.net</a>></span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">
> I believe the reason is usage of heap deallocation and mutex manipulation<br>
> in jack processing callback of vlc-jack plugin. This seems to be<br>
> unavoidable given the current aout API design.<br>
<br>
</div>Mutex manipulation are just like atomic operation in the non-contending<br>
case.</blockquote><div><br></div><div>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).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Latencies upstream of the jack plugin seem like a likely culprit too...<br>
It could also be page faults, though it seems unlikely.</blockquote><div><br></div><div>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...</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
> gcc has some atomic operations built in,<br>
> is this a viable option?<br>
<br>
</div>Yes and no. We would need to abstract them away because they are only<br>
available on a few platforms (and depending on version). On Windows, we may<br>
need to use Interlocked*() functions instead, and MacOS also has its own.<br>
In some cases, we would have to rely on inline assembly (e.g. ARMv6). And<br>
by default, we would have to emulate them.<br></blockquote><div><br></div><div>Hmm, yes, I'm aware there is always portability problems with atomic operations, one way or another... </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

But that does not even solve allocation problems, does it? So, you should<br>
first check what's really at fault...</blockquote><div><br></div><div>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?</div>
</div><br>