Is it limited by the OS? I have 16GB and yet I am only allowed to use 2gb selecting the ASIO driver or 4gb selecting MME driver. Is there any way to make the software recognize more than that?
Are those limits causing a problem? If not, don’t worry about it… remember that the memory needs to get shared with other apps / DLLs / drivers and the OS itself. It isn’t all there for Ardour’s benefit.
How did you conclude that there is a limit?
Unless you use an old 32bit processor or i836 (x32) application the memory per process is not limited to 2^32 bytes.
I am on Ardour 8.6.0, Windows 10, i5 processor, 16gb of ram.
Whenever I configure audio setup at Ardour start I only get to select a maximum of 2048 or 4096 samples of buffer size depending wether I use my interface or not.
It was my understanding that the maximum I should be able to select is directly related to the ammount of available RAM I have, thus I’m missing a larger buffer size availability. And since I recall having been able to select up until 8192 in my old Linux laptop I am inferring this has to do with some OS limitation.
John I’m actually asking because the project I’m working on right now is becoming very heavy to manage and I hoped that extending the buffer size I could work more easily without having to deactivate all plugins.
2048/4096/8192 are values that relate to the number of samples your audio interface wants processed in a single chunk. It is completely and totally unrelated to RAM. The possible values are controlled by the audio interface you are using.
1 Like
Yes @bluebones there’s just been a small misunderstanding at your end.
I checked here and you’re absolutely right… ASIO shows me a limit of 2048 samples whereas MME is slightly higher at 4096. But luckily there’s another backend available called Jack. You need to install it seperately but that one goes up to 8192:-
1 Like
Thank you for that explanation Paul. Still is kind of weird for me that on Linux and same interface I was able to select 8192 samples, then on Windows is 2048 for the same interface if I choose ASIO or 4096 if I choose MME driver, which in result hints me that drivers are also a factor here, and since there’s different need for them across OS I have to also suspect Windows is working some evil there xD
Now John your suggestion is something totally new for me, never thought JACK could be also “something” in Windows. Will dig into it.
Anyway apart from fiddling with Jack is there something I could be better focusing on to get the system to run more smoothly here? DSP is always showing 80% and more, affecting playback and recording 
Yes, the device driver layer can also affect the available choices.
Since JACK has to use either ASIO or MME on Windows, it will not have any significant effect on the available buffer sizes.
If you’re at 80% DSP with a buffer size of 4096 you either need a new computer or different plugins.
1 Like
The obvious way is to try and reduce the number of plugins you’re using.
I you, for instance, have a a similar reverb plugin on every track then maybe set up a bus with that reverb instead, and send the tracks to that bus.
That way you’ll get a similar effect but with one single plugin instead of maybe five or ten.
1 Like
Paul, it might work differently on Windows. What I see here is this:-
PortAudio+ASIO+Asio4All offers from 64 samples up to 2048 samples
Jack+PortAudio+Asio4All offers from 8 samples up to 8192 samples
JACK just lists all, without probing the device. Chances are that those buffersizes won’t work, and jackd silently falls back to the closest available one.
Wow Robin… there’s something I never knew but you’re right! With the same session I took a note of its DSP reading and any setting higher than 2048 just gives me the same reading 
You might be missing something here: in general, you want to keep the buffer size as small as possible, generally less than 1024 samples.
That’s also a generalisation: smaller buffer sizes mean less latency, but will also increase CPU use, but for a lot of common cases (such as real-time monitoring) low-latency is important.
Ultimately, it’s about compromises.
Cheers,
Keith
Yes that is an important factor, but I am monitoring directly from interface so latency for me becomes kinda secondary to CPU use.
Yes, that’s fair. And I think that, in a lot of cases, people stress too much about latency. It can be important, but with hardware monitoring (If that’s usable) then it’s largely irrelevant.
However, I think the difference on CPU load tends to be at the lower buffer settings. I think the difference in CPU usage between, say, 1024 and 2048 samples is pretty negligible.
Cheers,
Keith
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.