New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Server fails to start with `s.options.blockSize` != 16 #40

Closed
giuliomoro opened this Issue Apr 30, 2017 · 7 comments

Comments

Projects
None yet
4 participants
@giuliomoro
Copy link

giuliomoro commented Apr 30, 2017

s = Server.default;
s.options.numAnalogInChannels = 8;
s.options.numAnalogOutChannels = 8;
s.options.numDigitalChannels = 16;
s.options.blockSize = 32;
s.options.numInputBusChannels = 2;
s.options.numOutputBusChannels = 2;
s.options.postln;

s.waitForBoot({
});

if s.options.blockSize != 16 then the server cannot be started and it errors out terminate called without an active exception.
Note that 16 is the default blocksize for Bela.

@jpburstrom

This comment has been minimized.

Copy link

jpburstrom commented May 2, 2017

This should work if you adjust s.options.hardwareBufferSize to equal s.options.blockSize.

@sensestage

This comment has been minimized.

Copy link
Collaborator

sensestage commented Jun 5, 2017

I think in standard SC you can make the blockSize smaller than the hardwareBufferSize, but not larger. This makes sense as you have to have samples ready for a hardware callback.

On Bela the hardwareBufferSize is usually 16, and I believe (off the top of my head) that that is hardcoded at the moment. So indeed, the blockSize should be 16 or smaller.

@sensestage

This comment has been minimized.

Copy link
Collaborator

sensestage commented Jun 5, 2017

So - this should be fixed in the documentation - and perhaps a check when setting the blockSize to something larger than the hardwareBufferSize.

@LFSaw

This comment has been minimized.

Copy link

LFSaw commented Jun 13, 2017

actually, as mentioned in #33, I found that I have to set both block-size an hardware-buffer-size to be equal for scsynth to run properly. Sizes of 32 resp. 64 worked as well (and made buffer-underruns appear less).

@sensestage

This comment has been minimized.

Copy link
Collaborator

sensestage commented Jul 18, 2017

Now a warning is posted when the hardwareBufferSize is smaller than the blockSize.
So I think it is a clear user error right now.

SC's blockSize can be smaller than the hardwareBufferSize.

@sensestage

This comment has been minimized.

Copy link
Collaborator

sensestage commented Jul 18, 2017

But, doesn't generate proper audio then...

@sensestage

This comment has been minimized.

Copy link
Collaborator

sensestage commented Jul 18, 2017

Fixed via: 017c59c

The blockSize takes precedence over the set hardwareBufferSize.

@sensestage sensestage closed this Jul 18, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment