On Mon, March 26, 2018 9:38 am, Christopher Obbard wrote: Ok, three orders of magnitude is a pretty significant difference. So is this a BeagleBone Black or something similar? If so I run the RT kernels from the RCN repo, never had any problem with those so might be a good starting point. The design of jackd is not about throughput, it is about low latency. If you want better throughput, use larger period sizes. That is not really specific to jack, that is just a general principle in computing, if you want the best throughput using a general purpose computer design you should bundle your data into larger groups so that the processor has to handle fewer interrupts and the DMA controller(s) can run in the most efficient configuration. If you want the lowest latency you will have to trade off some throughput for that. If you want really low latency and high throughput you will likely have to design custom hardware with pipelined processing (e.g. some of the cut-through switch designs used for Infiniband and very low latency HPC Ethernet switches). That is a more advanced topic than how to get jackd running on an off the shelf processor. both to 70-80. Why not start off reading the linux audio and jack FAQs that explain how you should configure your RT system? It sounds like you are getting ready to re-discover all of that information the long and hard way. Might be entertaining and educational but probably is no the best use of your time. http://jackaudio.org/faq/linux_rt_config.html http://jackaudio.org/faq/linux_group_sched.html I thought there was a page somewhere with suggestions on RT priority settings, but I do not see it on the jackaudio FAQ or wiki pages. The rtirq script from Rui might be useful: http://www.rncbc.org/jack/ (link is toward the bottom) There may be some useful info here: https://wiki.linuxaudio.org/wiki/system_configuration but unfortunately the low latency page is from 2000, there have been quite a few changes in kernel setup since then, so I don't know how useful the low latency wiki page actually is on linuxaudio.org these days. The short version is you want the interrupt for your sound hardware to be highest, then jack right after that. There probably won't be any other RT tasks on a single use system, so it probably won't matter whether you set the sound IRQ and jackd priorities to 90 and 89, or 70 and 69, just make sure they are higher than the default for non-RT tasks, which I think is 50. The applications using jackd actually run the RT audio thread in jackd context, so unless I misunderstood something it should not in principle matter what the priority of the (main thread) of the other applications is set. better? Could be better for scheduling latency, but for IRQ driven tasks like handling the sound hardware I don't know if it matters or not. written by me. There appears to be a TI McASP driver in the kernel tree already, any reason you are not using that? Just asking, I have not tried to base anything on that driver yet myself. http://processors.wiki.ti.com/index.php/Sitara_Linux_Audio_Driver_Overview that handles specifics of the platform driver settings needed, and any control interfaces. OK, it sounds like maybe that is actually what you did, just wrote the codec portion and used the existing McASP driver to handle the I2S/TDM interface pieces. Not worth the trouble at this point. If you get a system that is mostly working and just has an occasional problem it might be worth optimizing, but it sounds like right now the system is pretty broken, so look for big problems, not small optimizations you could make. Make sure you have RT scheduling enabled for whatever user account you are using, try again and get the entire startup log. OK, then make sure you are really clear about when you are trying to debug problems with e.g. 32 frame setting vs. problems with the 128 frames setting, since it looks like you have different problems with the different period sizes. Then start with Rui's rtirq script. Some of the devices in the default script are x86 specific, and even some of those are probably outdated, but the framework is great, put the devices you want in the configuration file and run the script, it will set everything for you. application.... I don't think the application RT priority matters, if I understand correctly jackd will be allocating the thread that the application uses for audio callback, so that thread of the application should run at jackd priority, so for a simple embedded system you would just need to set the sound hardware IRQ the highest, then jackd after that (with the -R argument, default values is probably OK), then everything else can run at non-RT default. I think non-RT default is 50 and jackd default is 70 based on what I have seen on x86 machines. Just this, but honestly the original jackd developers took care of almost everything for you, you shouldn't need to know much about the low level details just to get it running. https://wiki.linuxfoundation.org/realtime/documentation/start -- Chris Caudle