"Ben" <ben@xxxxxxx> writes: > There was an article a few months back in Linux Journal that described > how to "lock" a thread onto a processor (and disallow any other threads > form running on that processor). If you were to lock the JACK process > into a single processor on an SMP box, wouldn't you effectively get > very low latency without any kernel patching or anything? You'd have > to use lock-free-fifo's to talk to the other processor (which is > running the UI, etc) of course. And you'd use a polling model to read/ > write data to the soundcard. This has the potential for slightly lower latency, but only works on SMP boxes. That is very system-specific, and quite difficult to manage. The JACK server has several threads, not all of them realtime. Plus, each external client runs in its own process with a separate address space and a dedicated realtime thread for running JACK callbacks. Some clients also require additional realtime threads, depending on their needs. As an engineering tradeoff, it is hard to justify making fundamental changes purely for SMP. In the current computer market, blazingly fast uni-processor systems are so cheap that it's hard for most users to justify the cost of an SMP. > Does ALSA have it's own thread in addition to the JACK thread, and > would it have to be on the same processor? No, jackd uses one of its realtime threads to call ALSA. > I'm not a Linux/Intel architecture guru, so forgive me if I've missed > some obvious points. The only "obvious" point is that this stuff is always more compicated than it seems... ;-) -- joq
