I'm looking for recommended specs for a Windows laptop dedicated to
real-time Csound performance. What are the 3-4 most important items to
consider?

The on-board sound is a non-issue; but how important is processor type and
speed, as well as amount of memory? (I assume the faster speed and more
memory the better.)

Art Hunkins

Is there a reason you need to use windows for the performances? I have 
had excellent results doing live shows with csound5 on linux, the 
latency and stability is awesome. It's not difficult to do a dual boot 
so that you can do the show in linux if that csound is all that will be 
running.

Iain

Art Hunkins wrote:
> I'm looking for recommended specs for a Windows laptop dedicated to
> real-time Csound performance. What are the 3-4 most important items to
> consider?
> 
> The on-board sound is a non-issue; but how important is processor type and
> speed, as well as amount of memory? (I assume the faster speed and more
> memory the better.)
> 
> Art Hunkins
> 

Latency on Windows is very small with ASIO. I have been running with cs 
buffers of 200 samples and
'very low latency' ASIO settings, which here mean something like 32 or 64 
samples.  Audio processing works
like a treat, almost like dedicated hardware.

Victor

At 04:23 18/11/2005, you wrote:
>Is there a reason you need to use windows for the performances? I have had 
>excellent results doing live shows with csound5 on linux, the latency and 
>stability is awesome. It's not difficult to do a dual boot so that you can 
>do the show in linux if that csound is all that will be running.
>
>Iain
>
>Art Hunkins wrote:
>>I'm looking for recommended specs for a Windows laptop dedicated to
>>real-time Csound performance. What are the 3-4 most important items to
>>consider?
>>The on-board sound is a non-issue; but how important is processor type and
>>speed, as well as amount of memory? (I assume the faster speed and more
>>memory the better.)
>>Art Hunkins
>--
>Send bugs reports to this list.
>To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk

Victor Lazzarini
Music Technology Laboratory
Music Department
National University of Ireland, Maynooth 

> Latency on Windows is very small with ASIO. I have been running with cs 
> buffers of 200 samples and
> 'very low latency' ASIO settings, which here mean something like 32 or 
> 64 samples.  Audio processing works
> like a treat, almost like dedicated hardware.
> 
> Victor

That is definitely an improvement over windows last time I used it. 
However, using the Ingo Molnar low latency kernel patch on 2.6.12, I am 
able to run simple csound orchestras with sr=48000 ksmps=1 in real time 
at buffer settings of -b1 -B1 with no break up! ( Delta 66 card, alsa 
0.9 or so )

csound -+rtaudio=alsa -odac -m0 -d --expression-opt --sched -b1 -B0 
monosynth5.orc monosynth5.sco

"audio buffered in 1 sample-frame blocks
writing 4-byte blks of shorts to dac"

  I have not done a recent shoot out because I don't have a windows 
install on this machine anymore, but when I did a comparison a long time 
ago, the improvement was dramatic in terms of latency, ability to use 
other gui apps at the same time ( using --sched ) and even cpu use for 
the same orchestra. Of course this is a very simple orchestra ( 8 vco's 
plus 2 moogvcf's, hits 25% cpu at ksmps=1 ), but it would be interesting 
to have the comparison for windows too. I am on an AMD 3000+ if anyone 
wants to try to see what the lowest -b -B's they can get are. Attached 
are the files.

Iain

Steven Yi wrote:

> I found it to be the case that for non-realtime renders, it was slower
> for me on the same computer when using Windows than on Linux.

Actually, non-realtime rendering should be slightly faster on Windows,
particularly if a dynamic Csound library is used, assuming that the code
is compiled with the same compiler and optimization settings. This is
because shared libraries on Linux are compiled with the -fPIC option
which makes the code less efficient.

Iain Duncan wrote:

> That is definitely an improvement over windows last time I used it. 
> However, using the Ingo Molnar low latency kernel patch on 2.6.12, I am 
> able to run simple csound orchestras with sr=48000 ksmps=1 in real time 
> at buffer settings of -b1 -B1 with no break up! ( Delta 66 card, alsa 
> 0.9 or so )

If you are using -+rtaudio=alsa, note that the -B1 is replaced
with -B64, and the -b1 is also overridden so that no less than 16
sample frames are sent to the sound device at once (of course,
you can easily remove these limits by editing InOut/rtalsa.c,
but even then, Csound will replace the -b1 -B1 with -b1 -B2).

>> That is definitely an improvement over windows last time I used it. 
>> However, using the Ingo Molnar low latency kernel patch on 2.6.12, I 
>> am able to run simple csound orchestras with sr=48000 ksmps=1 in real 
>> time at buffer settings of -b1 -B1 with no break up! ( Delta 66 card, 
>> alsa 0.9 or so )
> 
> If you are using -+rtaudio=alsa, note that the -B1 is replaced
> with -B64, and the -b1 is also overridden so that no less than 16
> sample frames are sent to the sound device at once (of course,
> you can easily remove these limits by editing InOut/rtalsa.c,
> but even then, Csound will replace the -b1 -B1 with -b1 -B2).

Thanks Istvan. I think that should be fixed, IMHO that is a problem 
considering that

a) I have no probelems running at that rate
b) the print output from Csound is misleading.

Why is it that way? Is it easy for you to change? Their are applications 
  ( real time full duplex fx for instance ) where the lowest possible 
roundtrip latency is essential. Can you change that? I would try but I 
have zero experience with CVS and do not want to break anything.

Thanks
Iain

Iain Duncan wrote:

> Thanks Istvan. I think that should be fixed, IMHO that is a problem 
> considering that
> 
> a) I have no probelems running at that rate

But you did not run with those buffer sizes, but rather
-b 16 -B 64 instead. So you do not know if -b1 -B1 would
really work.

> b) the print output from Csound is misleading.

Not really, if you read all messages:

audio buffered in 1 sample-frame blocks
ALSA output: total buffer size: 64, period size: 16

The ALSA plugin does print the actual buffer sizes (although it
is possible that not on all message levels).

> 
> Why is it that way? Is it easy for you to change? Their are applications 
>  ( real time full duplex fx for instance ) where the lowest possible 
> roundtrip latency is essential. Can you change that?

I can reduce the limits (is -b 8 -B 16 OK ?), but do not like the
idea of removing all buffer size checks, as it is a common newbie
mistake to set incorrect buffer size combinations and then complain
about audio problems.

>> Thanks Istvan. I think that should be fixed, IMHO that is a problem 
>> considering that
>>
>> a) I have no probelems running at that rate
> 
> But you did not run with those buffer sizes, but rather
> -b 16 -B 64 instead. So you do not know if -b1 -B1 would
> really work.

That's what I meant, no problem running at -b16 -B64, so clearly I can 
go lower. But how much lower, I have no idea.

>> b) the print output from Csound is misleading.
> 
> 
> Not really, if you read all messages:

"audio buffered in 1 sample-frame blocks
writing 4-byte blks of shorts to dac"

The above is cut directly from output, so that is definitely misleading. 
If csounds output says two conflicting things, that too is misleading. 
At any rate, it is definitely *not* clear at a glance that my settings 
are being overridden!

>> Why is it that way? Is it easy for you to change? Their are 
>> applications  ( real time full duplex fx for instance ) where the 
>> lowest possible roundtrip latency is essential. Can you change that?

> I can reduce the limits (is -b 8 -B 16 OK ?), but do not like the
> idea of removing all buffer size checks, as it is a common newbie
> mistake to set incorrect buffer size combinations and then complain
> about audio problems.

The above is unavoidable, and should not be justification for imposing 
limits, IMHO. If the new user types in no values for -b -B they get safe 
defaults. If they are typing values at all, they are looking something 
up or are experimenting. I really don't think there should be any checks 
in there at all, I should be allowed to fail at the lowest setting I 
can.  I would like them gone for now at any rate, as I can't say whether 
-b 8 -B16 is ok until I can test below the current settings.

Thanks
Iain

Iain Duncan wrote:

> "audio buffered in 1 sample-frame blocks
> writing 4-byte blks of shorts to dac"

Well, Csound really writes 1 sample frame at once to the ALSA plugin,
it just happens that the sound card buffer settings are different and
that is reported.

>> "audio buffered in 1 sample-frame blocks
>> writing 4-byte blks of shorts to dac"
> 
> 
> Well, Csound really writes 1 sample frame at once to the ALSA plugin,
> it just happens that the sound card buffer settings are different and
> that is reported.

So how do we know what the lowest setting possible is for a given 
soundcard then?

Thanks
Iain