![]() So while I might see the meter at 50% with one plugin, at first I think “wow that seems high” - but then I add like 10 more instances of the same plugin and hey - it’s still 50%. Also, I noticed Ardour’s DSP load meter does not increase linearly as I add more plugins. Dropping to 2 periods at the same buffer size unleashes the torrent of x-runs. I can load plugins and watch the load meter hit 99% but without “x-running”. I think the limit on my machine is buffer size 32 with 3 periods. With threadirqs enabled along with the various other realtimeconfigquickscan recommendations and an RME usb interface, I found that up to a point, while Ardour’s DSP load meter might be spiking close to or even hitting 100%, there will be very few/no x-runs. So again that makes it difficult to know for sure whether they are all running under similar time constraints. I couldn’t find any built in tool to measure round trip latency in either Reaper or Bitwig. So who knows maybe there are some sneaky extra buffers behind the scenes in Bitwig?Īrdour provides a tool to measure round trip latency on the audio setup dialog. Reaper and Ardour both give the option to select at least 2 or 3 periods, and I found that at very small buffer sizes the extra period can be the difference between hundreds of x-runs and almost none. How many buffer periods is Bitwig using? In the ALSA backend setup it only gives the option to set buffer size, and I kind of just assume it’s using 2 but can’t be sure without measuring round trip latency. I think I read somewhere on this forum that even JACK and Ardour have different DSP load algorithms that presents JACK in a slightly more flattering light. I couldn’t find any way to see a count of x-runs in Reaper or Bitwig.ĭifferent DAWs could be measuring/calculating DSP load differently, I don’t know if the closed source DAWs publish how they calculate load. This might lead to the impression that Ardour is “worse” when in fact it may just be more honest. If there are a lot of x-runs then they are easy to hear sure, but it’s quite possible that the occasional x-run goes by in other DAWs without the user ever being notified or realizing. I have made similar observations comparing Ardour, Reaper and Bitwig but I came to the tentative opinion that these kinds of head-to-head comparisons may be flawed due to a few reasons:Īrdour is the only DAW I know of that prominently displays the x-run count. To be clear, I don’t ever run Bitwig Studio or Tracktion but downloaded them just to check I wasn’t crazy and that REAPER was doing some weird anticipatory fx voodoo via in the 11MB it takes up on my SSD.Īnyway, I’m wondering if a debug would help or providing my current laptop system specs or whether it is just a fact of life that I simply can’t get that low a latency with those particular plugins on Ardour and on this particular system? I will say that the difference is night and day and that my system seems highly optimized for realtime audio work based on realtimeconfigquickscan, wine-tkg-git, fsync settings and the performance in the other three DAWs. In either case REAPER, Bitwig Studio and Tracktion perform flawlessly at low latencies whereas Ardour chokes immediately with hundreds of x-runs and DSP hitting 100%. Two simple examples are sfizz + dragonfly hall reverb send (native) or sforzando + Liquidsonics Cinematic Rooms send (via yabridge). ![]() My brain and fingers prefer 64 samples / 2 period wherever possible and I can achieve this in every DAW I’ve tried aside from Ardour. ![]() In both Ardour 6.6 and 6.7 (I assume previous versions too) I’m finding a massive difference between Ardour’s DSP/x-run count and other Linux native DAWs.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |