Topic: Blocked buffer size choices in alsa for rme hammerfall
The smallest buffer allowed by alsa is 64 though on windows it's 16 as far as i remember. Any solutions to set buffer smaller than 64?
Check the TotalMix forum!
Pages 1
You are not logged in. Please login or register.
RME User Forum → Linux → Blocked buffer size choices in alsa for rme hammerfall
The smallest buffer allowed by alsa is 64 though on windows it's 16 as far as i remember. Any solutions to set buffer smaller than 64?
The smallest buffer size is 32 samples @single speed (44.1/48 kHz), 64 @double speed, 128@ quad speed.
The difference between 32 and 64 samples is small, 0,73ms for in and for out, as you can see in this comparison chart with values at 44.1 kHz: https://www.tonstudio-forum.de/blog/ent … cts-en-de/
I wouldn't worry about it too much, I am also using 64 samples with an UFX III which is low enough, puts less stress on the system and a little bit more prevention against audio loss under load.
For pure recording, you would use much higher values anyway to provide the best protection against audio loss.
For mixing and mastering: if you are using CPU hungry VST or VSTi and depending on the complexity of the project, you can't use the minimum buffer size anyway. I remember that I had Ozone in my DAW sum, and it needed at minimum 256 or even 512 samples buffer size (at single speed) to not cause audio interruptions, which was finally the reason for not using it anymore.
Anyway i would like to use buffer 32. Perhaps, code of ko module can be edited for unblocking 32. Currently i use the hack of feeding recorded signal into second soundcard set at 32 via spdif. I don't use heavy load plugins and even disable all pdc everywhere. Buffer 32 is enough for 50track project mixing provided plugin chains' total calculation time from first tracks' plugin to last plugin of masterbus does not exceed the time of the buffer. A plugin's calculation time varies from dozens to hundreds microseconds. It's not even cpu hogging which counts but the above mentioned. Therefore the longer is calculation time of a plugin the more potential it has to ruin rt operation. Busses, sends and folder tracks also add to ruining rt. Responsiveness of the daw is important to me.
Hdsp.c has 2 lines: period_bytes_min and static const unsigned int hdsp_period_sizes
Possible to replace 64 by 32 in first line and add 32 into second line? And then to recompile the module
Hdsp.c has 2 lines: period_bytes_min and static const unsigned int hdsp_period_sizes
Possible to replace 64 by 32 in first line and add 32 into second line? And then to recompile the module
I would ask the author of the code via mail.
They never answer...
One thing which frightens is that 8 values of buffers are assigned to 0-7 for latencies, so if i add additional number all can be messed up to a risky degree. Also other lines may be needed to modify as they claim period 2 is required and 32s may be required to be changed to 16s as well.
I have taken the risk of modifying those and some other lines (the general idea was to replace 64-8192 range by 32-4096), compiling and loading of modded module, i could select buffer 32 but playback did not work and i had to revert to normal ko.
aplay -v --dump-hw-params -fdat -d1 -Dhw:0,0 /dev/zero pleasantly showed decrease of buffer to 64 from 128 and period to 32 from 64 but as mentioned above playback did not work.
RME User Forum → Linux → Blocked buffer size choices in alsa for rme hammerfall
Powered by PunBB, supported by Informer Technologies, Inc.