blockSize dosn't work?

[_.-lucas-._]

Hi

Is there a problems with the block size?

This dosn't make any sound:

(

o = Server.local.options;

o.blockSize_( 4410 );

s.boot;

)

{ SinOsc.ar(440, 0, 0.1) }.play(s);

when boot the message is:

SC_AudioDriver: sample rate = 44100.000000, driver's block size = 512

Thanks

Lucas

[Andrew Pascoe]

Block sizes should be powers of two.  Also, the "driver's block size"  
refers to the option hardwareBufferSize, which is a different  
setting.  (This should also be a power of two.)

--Andrew

On 23.04.2009, at 08:26, Lucas Samaruga wrote:

> Hi
>
> Is there a problems with the block size?
> This dosn't make any sound:
>
> (
> o = Server.local.options;
> o.blockSize_( 4410 );
> s.boot;
> )
>
> { SinOsc.ar(440, 0, 0.1) }.play(s);
>
> when boot the message is:
>
> SC_AudioDriver: sample rate = 44100.000000, driver's block size = 512
>
> Thanks
> Lucas
>

_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/

[stwbass]

If I run your code and run s.options.dump, the blockSize is as you've set it. It seems that if you set SCs block size is larger than the hardware's there is no sound. I might go out on a whim and ask if you're trying to set the block size like a k-rate in Csound? I only ask because of the new block size is 1/10 of a typical sampling rate.

sw

On Thu, Apr 23, 2009 at 10:21 AM, Andrew Pascoe <aylutar@...> wrote:

Block sizes should be powers of two.  Also, the "driver's block size" refers to the option hardwareBufferSize, which is a different setting.  (This should also be a power of two.)

--Andrew

On 23.04.2009, at 08:26, Lucas Samaruga wrote:

Hi

Is there a problems with the block size?
This dosn't make any sound:

(
o = Server.local.options;
o.blockSize_( 4410 );
s.boot;
)

{ SinOsc.ar(440, 0, 0.1) }.play(s);

when boot the message is:

SC_AudioDriver: sample rate = 44100.000000, driver's block size = 512

Thanks
Lucas

_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/

--
Scott Worthington
stwbass@...
www.scottworthington.com

[James Harkins-2]

What would be the benefit of a 0.1sec control rate? That's going to be
really bad for kr UGen shapes (which will turn into 0.1sec line
segments instead of nice curves), timing resolution on the server,
probably more stuff I can't think of now.

Whatever cpu savings you think you might get by slowing down control
rate, it's probably not worth it.

On the other hand, if you were trying to set the "driver's block size":

o.hardwareBufferSize = ***;  // expected to be a power of 2

The only time I changed this, though, was to lower it to get less
audio input latency.

hjh

On Thu, Apr 23, 2009 at 8:26 AM, Lucas Samaruga <samarugalucas@...> wrote:

> Hi
> Is there a problems with the block size?
> This dosn't make any sound:
> (
> o = Server.local.options;
> o.blockSize_( 4410 );
> s.boot;
> )
> { SinOsc.ar(440, 0, 0.1) }.play(s);
> when boot the message is:
> SC_AudioDriver: sample rate = 44100.000000, driver's block size = 512
> Thanks
> Lucas
>

--
James Harkins /// dewdrop world
jamshark70@...
http://www.dewdrop-world.net

"Come said the Muse,
Sing me a song no poet has yet chanted,
Sing me the universal."  -- Whitman

_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/

[James Harkins-2]

On Thu, Apr 23, 2009 at 10:44 AM, James Harkins <jamshark70@...> wrote:
> What would be the benefit of a 0.1sec control rate? That's going to be
> really bad for kr UGen shapes (which will turn into 0.1sec line
> segments instead of nice curves)...

e.g.,

s.options.blockSize = 4096;
s.boot;

{ K2A.ar(SinOsc.kr(1)) }.plot(1);

Yick.

hjh


--
James Harkins /// dewdrop world
jamshark70@...
http://www.dewdrop-world.net

"Come said the Muse,
Sing me a song no poet has yet chanted,
Sing me the universal."  -- Whitman

_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/

[_.-lucas-._]

On Thu, Apr 23, 2009 at 10:21 AM, Andrew Pascoe <aylutar@...> wrote:

Block sizes should be powers of two.  

El 23/04/2009, a las 11:27, Scott Worthington escribió:

If I run your code and run s.options.dump, the blockSize is as you've set it. It seems that if you set SCs block size is larger than the hardware's there is no sound.

Yes, powers of two less than or equal the hardwareBufferSize (thanks James!)

I don't find this restrictions in the documentation.

I might go out on a whim and ask if you're trying to set the block size like a k-rate in Csound? I only ask because of the new block size is 1/10 of a typical sampling rate.

Yes, I'm doing a language/environment comparison and have Csound code with that kr (the idea is to achieve the same result signal, or so).

El 23/04/2009, a las 11:44, James Harkins escribió:

What would be the benefit of a 0.1sec control rate? That's going to be
really bad for kr UGen shapes (which will turn into 0.1sec line
segments instead of nice curves), timing resolution on the server,
probably more stuff I can't think of now.

Perhaps only a methodological difference betwen both, or the resources are different.

What do you think?

Thanks you very much.