newsAdvanced Gtk+ Sequencer - News: Implementing cache option for all output backends

 
 
Latest News
GSequencer v2.1.53 for debian buster posted by jkraehemann, Fri 08 Mar 2019 11:01:12 PM UTC - 0 replies
Get emotional as debian buster is going to be released posted by jkraehemann, Thu 07 Mar 2019 12:46:59 AM UTC - 0 replies
State of GSequencer in debian buster posted by jkraehemann, Sun 03 Mar 2019 07:08:32 PM UTC - 0 replies
handling LV2 iriref posted by jkraehemann, Wed 13 Feb 2019 10:20:49 AM UTC - 0 replies
fixed ref-count posted by jkraehemann, Sat 09 Feb 2019 02:46:41 PM UTC - 0 replies
[Submit News]
[79 news in archive]

Implementing cache option for all output backends

Item posted by Joël Krähemann <jkraehemann> on Mon 07 Jan 2019 11:37:40 PM UTC.

Just now, I have completed the pulseaudio caching ability. This allows GSequencer to run with a smaller buffer size than the cache. This is useful regarding non low-latency setup using pulseaudio.

Prior you didn't get the desired BPM above 120 if latency was too big. This is fixed by the caching option.

Cache option for all output backends

I intend to develop for all output backends a cache option. This in view of achieving smother automation.

Since the UI allows you to automate upto a 1/64 of the smallest notation delay. The automation capacity is not fully used.

Assumed you have ALSA setup with 1024 buffer size and running at a samplerate of 44100. By 120 BPMs and 4/4 segmentation, you have a delay of approximately:

In view of buffer size which is 1024 you do:

So of the possible 64 changes only 5 are actually used. But if you have a buffer size of 128 it is slightly different:

Over the thumb you get smother automation with smaller buffer size.


by Joël

No messages in Implementing cache option for all output backends

 

Back to the top


Powered by Savane 3.4