Howdy,

So I've been teaching myself CSound over the past week or so, and I'm
fairly convinced I'm Doin' It Wrong, mostly because it seems like my
latency is far too high. Comparing CSound's MIDI listening with my
custom synth application, which uses ALSA for MIDI and SDL for audio,
CSound seems to suffer from a bit of audio latency and a *lot* of MIDI
latency, to the point where controller changes (pitch bends) are
stair-stepping and stuttering, and any fast passage results in noteons
getting completely dropped. CPU usage isn't very high, though, so I
don't think that it's a problem with my computer being too old. And
it's not old at all; it's a fairly shiny Core i3 dual-core with a few
GB of RAM.

For example, these two instruments both lag the same amount.

instr i1
    kpitch cpsmidib 2
    kmodwheel ctrl7 1, 1, 0, 1

    ; LFO. Triangle, 5Hz, FM from pitch and mod wheel.
    ; Should modulate from the mod wheel as well.
    klfopitchmod = kpitch / 300
    ; should fm from pitch
    klfo lfo 1, klfopitchmod, 1

    ; Oscillators. One saw, one pulse.
    kpitch = kpitch + (klfo * cent(4))
    asaw vco2 10000, kpitch * octave(-1), 0 ; BLIT-style saw
    apulse vco2 10000, kpitch * octave(-1), 2, 0.67 ; PWM, 67%

    ; Filters. Resonant low-pass.
    ; Might not be right resonance values.
    asawfilter rezzy asaw, 140, 70
    apulsefilter rezzy apulse, 2500, 10

    kadsr mxadsr 0.01, 0.02, 0.7, 0.1

    acore = (asawfilter + apulsefilter) * kadsr

    ; Barberpole phaser.
    areal, aimag hilbert acore
    asin oscil 1, 0.42, 1
    acos oscil 1, 0.42, 1, .25
    amod1 = areal * acos
    amod2 = aimag * asin
    aup = (amod1 + amod2) * 0.7
    adown = (amod1 - amod2) * 0.7
    aphased = acore * 2 + aup + adown

    abalanced balance aphased, acore
    aout clip aphased, 1, 30000
    out aout
endin

instr uranium
    iamp veloc 1, 16000
    ivib veloc 1, 10

    knote cpsmidib 2
    kcutoff ctrl7 1, 1, 1200, 2000 ; From the mod wheel.

    asaw vco 10000, knote, 1

    kadsr mxadsr 0.01, 0.02, 0.7, 0.1

    ires = 88

    aout rezzy asaw * kadsr, kcutoff, ires

    out aout
endin

Any hints? I'm looking forward to leveraging CSound, but this isn't
going to work out well for live performances as-is.

~ C.

Can you post the full csd with the command line option?

Maybe your kr is very low?

P

On 18 Aug 2010, at 15:26, Corbin Simpson wrote:

> Howdy,
> 
> So I've been teaching myself CSound over the past week or so, and I'm
> fairly convinced I'm Doin' It Wrong, mostly because it seems like my
> latency is far too high. Comparing CSound's MIDI listening with my
> custom synth application, which uses ALSA for MIDI and SDL for audio,
> CSound seems to suffer from a bit of audio latency and a *lot* of MIDI
> latency, to the point where controller changes (pitch bends) are
> stair-stepping and stuttering, and any fast passage results in noteons
> getting completely dropped. CPU usage isn't very high, though, so I
> don't think that it's a problem with my computer being too old. And
> it's not old at all; it's a fairly shiny Core i3 dual-core with a few
> GB of RAM.
> 
> For example, these two instruments both lag the same amount.
> 
> instr i1
>    kpitch cpsmidib 2
>    kmodwheel ctrl7 1, 1, 0, 1
> 
>    ; LFO. Triangle, 5Hz, FM from pitch and mod wheel.
>    ; Should modulate from the mod wheel as well.
>    klfopitchmod = kpitch / 300
>    ; should fm from pitch
>    klfo lfo 1, klfopitchmod, 1
> 
>    ; Oscillators. One saw, one pulse.
>    kpitch = kpitch + (klfo * cent(4))
>    asaw vco2 10000, kpitch * octave(-1), 0 ; BLIT-style saw
>    apulse vco2 10000, kpitch * octave(-1), 2, 0.67 ; PWM, 67%
> 
>    ; Filters. Resonant low-pass.
>    ; Might not be right resonance values.
>    asawfilter rezzy asaw, 140, 70
>    apulsefilter rezzy apulse, 2500, 10
> 
>    kadsr mxadsr 0.01, 0.02, 0.7, 0.1
> 
>    acore = (asawfilter + apulsefilter) * kadsr
> 
>    ; Barberpole phaser.
>    areal, aimag hilbert acore
>    asin oscil 1, 0.42, 1
>    acos oscil 1, 0.42, 1, .25
>    amod1 = areal * acos
>    amod2 = aimag * asin
>    aup = (amod1 + amod2) * 0.7
>    adown = (amod1 - amod2) * 0.7
>    aphased = acore * 2 + aup + adown
> 
>    abalanced balance aphased, acore
>    aout clip aphased, 1, 30000
>    out aout
> endin
> 
> instr uranium
>    iamp veloc 1, 16000
>    ivib veloc 1, 10
> 
>    knote cpsmidib 2
>    kcutoff ctrl7 1, 1, 1200, 2000 ; From the mod wheel.
> 
>    asaw vco 10000, knote, 1
> 
>    kadsr mxadsr 0.01, 0.02, 0.7, 0.1
> 
>    ires = 88
> 
>    aout rezzy asaw * kadsr, kcutoff, ires
> 
>    out aout
> endin
> 
> Any hints? I'm looking forward to leveraging CSound, but this isn't
> going to work out well for live performances as-is.
> 
> ~ C.
> 
> -- 
> When the facts change, I change my mind. What do you do, sir? ~ Keynes
> 
> Corbin Simpson
> 
> 
> 
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
> 



Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

On Wed, Aug 18, 2010 at 7:48 AM, Peiman Khosravi
 wrote:
> Can you post the full csd with the command line option?
>
> Maybe your kr is very low?

I'm using split .orc and .sco files. My command line is very boring; I
just use -odac -+rtmidi=alsa to get live output and ALSA's MIDI
routing going. My .sco is pretty boring, too; it's this:

f 0 120
; Plain sine wave, from GEN10.
f 1 0 8192 10 1

My kr is 44100/10:

sr = 44100
kr = 4410
nchnls = 1

This *should* be more than fast enough, right?

~ C.

On Wed, Aug 18, 2010 at 8:25 AM, Victor Lazzarini
 wrote:
> From the manual:
> Realtime I/O on Linux
>
> Under Linux, the default PortAudio/PortMidi settings will result in higher
> latency than that which can be achieved using ALSA and/or JACK. The
> PortMusic plugins are audio and MIDI servers, which provide an interface to
> the ALSA drivers, in a manner which is in some respects similar but
> fundamentally different from that provided by JACK. For a more detailed
> comparison please refer to:
>
> http://jackaudio.org/faq
>
> Using ALSA
>
> The highest level of control and the lowest possible level of latency are to
> be achieved using the ALSA plugins in combination with the --sched flag.
> Using --sched requires that Csound be run as the root user, which may be
> impossible or undesirable in some circumstances.
>
> The ALSA plugins require the "name" of a "card" and a "device". Unless you
> have named your "cards" in ~/.asoundrc (or /etc/asound.conf), the "names"
> will actually be numbers. In order to obtain a list of the possible
> configurations, use the command line utilities "aplay", "arecord" and
> "amidi". These utilities are included with most Linux distros, or can be
> downloaded and built from source here:
>
> ftp://ftp.alsa-project.org/pub/utils/
>
> Audio Output
>
> Running the following command:
>
>           aplay -l
>
> will give you a list of the audio playback devices available on your system.
> Typically this list will look something like:
>
> [....]
> **** List of PLAYBACK Hardware Devices ****
> card 0: A5451 [ALI 5451], device 0: ALI 5451 [ALI 5451]
> [....]
>
> If you have more than one card on your system, or if there is more than one
> device on your card, the list will of course be more complicated, however in
> all cases the information that is pertinent is the number/name of the
> card/device. In order to use the above soundcard for audio output, the
> following flag would be added to the Csound command line, ~/.csoundrc, or
> the section of a CSD:
>
>           -+rtaudio=alsa -o dac
>
> [...]
> Scheduling
>
> If you are able to run Csound as the root user, using the "--sched" flag
> will dramatically improve realtime performance, when using ALSA, however you
> may hang your system if you do something stupid. DO NOT use "--sched" if you
> are using JACK for audio output. JACK controls scheduling for the audio
> applications connected to it, and also tries to run at the highest possible
> priority. If the "--sched" flag is used, Csound and JACK will be competing
> rather than cooperating, resulting in extremely poor performance.
>
> [...]
> Using JACK
>
> The simplest way to use the JACK plugin enabling input and output is as
> follows:
>
>           -+rtaudio=jack -i adc -o dac
>
> Additionally, there are some command line options specific to JACK:
>
> JACK Command-line Flags
>
> -+jack_client=[client_name]
>
> The client name used by Csound, defaults to 'csound5'. If multiple instances
> of Csound connect to the JACK server, different client names need to be used
> to avoid name conflicts.
>
> -+jack_inportname=[input port name prefix], -+jack_outportname=[output port
> name prefix]
>
> Name prefix of Csound JACK input/output ports; the default is 'input' and
> 'output'. The actual port name is the channel number appended to the name
> prefix. Example: with the above default settings, a stereo orchestra will
> create these ports in full duplex operation:
>
> csound5:input1              (record left)
>
> csound5:input2              (record right)
>
> csound5:output1             (playback left)
>
> csound5:output2             (playback right)
>
> -+jack_sleep_time=[sleep time in microseconds]
>
> As of Csound version 5.01, this option is deprecated and ignored.
>
> Connecting Csound to other JACK clients
>
> By default, no connections are made (you need to use jack_connect, qjackctl,
> or a similar utility); however, the plugin can connect to ports specified as
> '-iadc:portname_prefix' or '-odac:portname_prefix', where portname_prefix is
> the full name of a port without a channel number, such as
> 'alsa_pcm:capture_' (for -i adc), or 'alsa_pcm:playback_' (for -o dac).
>
> Notes on buffer sizes
>
> Audio data is received from and sent to the JACK server by Csound using a
> ring buffer that is controlled by the -b and -B flags. -B is the total size
> of the buffer, while -b is the size of a single period. These values are
> rounded so that the total size is an integer multiple of, and greater than
> the period size. The difference of the Csound buffer and period size must be
> greater than or equal to the JACK period size.
>
> If both -iadc and -odac are used at the same time, the -b option should be
> set to an integer multiple of ksmps.
>
> An example of buffer settings for low latency on a fast system:
>
>           jackd -d alsa -P -r 48000 -p 64 -n 4 -zt &
>
>           csound -+rtaudio=jack -b 64 -B 256 [...]
>
> with real time scheduling (as root):
>
>           jackd -R -P 90 -d alsa -P -r 48000 -p 64 -n 2 -zt &
>
>           csound --sched=80,90,10 -d -+rtaudio=jack -b 64 -B 192 [...]
>
> To improve performance, use ksmps values like 32 and 64.
>
> The sample rate of the orchestra must be the same as that of the JACK
> server.
>
> =======
>
> HtH

Hm. -b and -B didn't help before, and neither did nuking PA and
letting ALSA handle the card directly. I can give it another whirl, I
guess.

-- 
When the facts change, I change my mind. What do you do, sir? ~ Keynes

Corbin Simpson



Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Try adding  -+rtaudio=alsa  to use alsa directly instead of portaudio.  
If you have an RT kernel and permissions, you can use  the --sched  
option (or --sched=N, where N is 0-99 priority). Most of all, reduce  
the buffer sizes, -b and -B.

I would suggest starting with -b128 -B256 and then try to reduce until  
you start getting xruns. In my old laptop (5 years old. 1.6GHz i686),  
I could go down to -b32  -B64.

Victor
On 18 Aug 2010, at 16:22, Corbin Simpson wrote:

> On Wed, Aug 18, 2010 at 7:48 AM, Peiman Khosravi
>  wrote:
>> Can you post the full csd with the command line option?
>>
>> Maybe your kr is very low?
>
> I'm using split .orc and .sco files. My command line is very boring; I
> just use -odac -+rtmidi=alsa to get live output and ALSA's MIDI
> routing going. My .sco is pretty boring, too; it's this:
>
> f 0 120
> ; Plain sine wave, from GEN10.
> f 1 0 8192 10 1
>
> My kr is 44100/10:
>
> sr = 44100
> kr = 4410
> nchnls = 1
>
> This *should* be more than fast enough, right?
>
> ~ C.
>
> -- 
> When the facts change, I change my mind. What do you do, sir? ~ Keynes
>
> Corbin Simpson
> 
>
>
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"
>



Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Oh, you have pulseaudio, do you? Pulseaudio is high latency, I'm  
afraid. For low-latency, either use alsa directly or use Jack.

Victor
On 18 Aug 2010, at 16:25, Corbin Simpson wrote:

> Hm. -b and -B didn't help before, and neither did nuking PA and
> letting ALSA handle the card directly. I can give it another whirl, I
> guess.



Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"