<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Mar 1, 2015 at 9:42 AM, Len Ovens <span dir="ltr"><<a href="mailto:len@ovenwerks.net" target="_blank">len@ovenwerks.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Sun, 1 Mar 2015, Robert Jonsson wrote:<br>
<br>
</span><div><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2015-02-28 21:17 GMT+01:00 Len Ovens <<a href="mailto:len@ovenwerks.net" target="_blank">len@ovenwerks.net</a>>:<br>
<br>
I can only answer some of these questions. The 1010s will have<br>
slightly lower latency. Mine runs at 16/2,<br>
<br>
<br>
I sometimes wonder about numbers like these and if I'm doing something wrong or<br>
if it's incredibly hardware dependent. I've never ever come close to running at<br>
16/2 in a stable manner. 128/2 I could run reasonbly stable with the Delta 44.<br>
Now with firewire it's harder still.<br>
Do you really get this without xruns? Any magic tricks? How much have you tweaked<br>
your settings to get there?<br>
</blockquote>
<br></div></div>
I should add a bit about FW/USB cards. This is just general stuff. It seems that there is a lowest point jack will even start latency wise:<br>
ice1712 - 16/2<br>
ens1370 - 32/2<br>
fw - 32/2<br>
USB - 64/2<br>
Intel HDA - 64/3<br>
<br>
These seem to be based on the size of the HW buffer in the IF itself and/or the bus protocol in use. AES67 suggests 16/3 (1ms) and I suspect both FW and USB may bennefit from /3 as well after reading the AES67 reasoning for 3 buffer use.<br></blockquote><div><br></div><div>all audio interfaces have a hardware limit on the smallest sized buffer (period) they can use. it is partly based on the internal design of the interface itself, but also affected by the bus minimum transfer size. multichannel cards can theoretically use a smaller buffer because they don't bump into the bus transfer limit, but in an era when even the builtin HDA has 6 or 8 channels, this isn't much of a difference any more. <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Anyway, all of the things I do for a PCI audio IF, I would also do for the USB or FW host card. In a desktop machine, I would tend not to trust any onboard FW or USB hosting, choosing rather to buy a PCIe card and treat that card the same as I would a PCI(e) audio card. I have found with USB audio IFs that when setting up /etc/default/rtirq it is best to single out the USB port I am using for sound. So rather than ordering things:<br>
<br>
RTIRQ_NAME_LIST="rtc usb i8042"<br></blockquote><div><br></div><div>there's almost no reason to use the RTC on any modern system. high frequency timers are on every motherboard and in combination with a tickless kernel (the default these days), the cpu overhead is massively reduced even as resolution is increased.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Also it occurs to me... swappiness 10... and make sure to have enough memory that no swapping ever takes place :) An unimportant thing like a workspace pager that gets swapped out... can stop audio dead if the user has the soft synth on a different workspace they need to adjust.</blockquote><div><br></div><div>this should NEVER be true. if it is true then the synth is misdesigned or the video driver is incorrectly written.<br><br></div><div>JACK (1) goes to some considerable lengths to make sure that the relevant code of its clients can never be swapped out. JACK 2 makes a similar though slightly less sophisticated effort.<br></div><br></div></div></div>