Hi,

I was experimenting with the new opcodes using the pvs TRACKS format and 
I found that I get lots of xruns in jack.

This is the csd file I'm using:




sr=44100
ksmps=1
nchnls=2

gid ftgen 1, 0, 1024, 10, 1

    instr 1    ;untitled
ain inch 1                  ; input signal
fs1,fsi2 pvsifd ain,2048,512,1 ; pvsifd analysis
fst  partials fs1,fsi2,.003,1,3,500  ; partial tracking
      aout  resyn fst, 1, 1.5, 500, 1 ; resynthesis (up a 5th)
out aout, aout
    endin





i1 0 3600
e





and the command line: csound -M0 -+msg_color=false --expression-opt 
-+rtaudio=jack -odac:alsa_pcm:playback_ -iadc -b128 -B1024

Connecting very simple sound sources I get some crackling but with 
complex sounds it gets completely interrupted and the cpu usage goes to 
100%. Is it appropriate to expect these opcodes to work in realtime? The 
other PVS opcodes (non TRACKS) work perfectly and using very little cpu 
power. My system is a P4 HT 2.8 GHz and I'm using Csound 5.01 and a 
2.6.15 Linux kernel with realtime preemption patches.

thanks!


Hector.

TRACKS format with ksmps=1 ???

This new format is very high quality but also CPU intensive. I view it 
as true to Csound's historical form: the most state of the art 
technology at the expense of being limited almost exclusively to 
non-realtime.

You can of course try all the standard tricks like --sched or renice to 
alter the CPU processing priority, but in my experience, TRACKS format 
works the best in an offline situation - and even then takes a LONG 
time to render (but sounds amazing!)


-David

On Mar 22, 2006, at 2:53 PM, Hector Centeno-Garcia wrote:

> Hi,
>
> I was experimenting with the new opcodes using the pvs TRACKS format 
> and I found that I get lots of xruns in jack.
>
> This is the csd file I'm using:
>
> 
>
> 
> sr=44100
> ksmps=1
> nchnls=2
>
> gid ftgen 1, 0, 1024, 10, 1
>
>    instr 1    ;untitled
> ain inch 1                  ; input signal
> fs1,fsi2 pvsifd ain,2048,512,1 ; pvsifd analysis
> fst  partials fs1,fsi2,.003,1,3,500  ; partial tracking
>      aout  resyn fst, 1, 1.5, 500, 1 ; resynthesis (up a 5th)
> out aout, aout
>    endin
>
> 
>
> 
>
> i1 0 3600
> e
>
> 
>
> 
>
> and the command line: csound -M0 -+msg_color=false --expression-opt 
> -+rtaudio=jack -odac:alsa_pcm:playback_ -iadc -b128 -B1024
>
> Connecting very simple sound sources I get some crackling but with 
> complex sounds it gets completely interrupted and the cpu usage goes 
> to 100%. Is it appropriate to expect these opcodes to work in 
> realtime? The other PVS opcodes (non TRACKS) work perfectly and using 
> very little cpu power. My system is a P4 HT 2.8 GHz and I'm using 
> Csound 5.01 and a 2.6.15 Linux kernel with realtime preemption 
> patches.

Hector Centeno-Garcia wrote:

>
> 
>
> 
> sr=44100
> ksmps=1
> nchnls=2
>
ksmps=8 and no 1. sorry.

Hector.

Sorry for the mistake, as I corrected later it was ksmps=8. Because the 
example in the manual (I took that code from there) uses the inch 
opcode, I thought it was intended to be used in realtime. But after 
reading your impressions then I think I should I'll give it a try 
non-realtime!

Thank you,


Hector

David Akbari wrote:

> TRACKS format with ksmps=1 ???
>
> This new format is very high quality but also CPU intensive. I view it 
> as true to Csound's historical form: the most state of the art 
> technology at the expense of being limited almost exclusively to 
> non-realtime.
>
> You can of course try all the standard tricks like --sched or renice 
> to alter the CPU processing priority, but in my experience, TRACKS 
> format works the best in an offline situation - and even then takes a 
> LONG time to render (but sounds amazing!)
>
>
> -David
>
> On Mar 22, 2006, at 2:53 PM, Hector Centeno-Garcia wrote:
>
>> Hi,
>>
>> I was experimenting with the new opcodes using the pvs TRACKS format 
>> and I found that I get lots of xruns in jack.
>>
>> This is the csd file I'm using:
>>
>> 
>>
>> 
>> sr=44100
>> ksmps=1
>> nchnls=2
>>
>> gid ftgen 1, 0, 1024, 10, 1
>>
>>    instr 1    ;untitled
>> ain inch 1                  ; input signal
>> fs1,fsi2 pvsifd ain,2048,512,1 ; pvsifd analysis
>> fst  partials fs1,fsi2,.003,1,3,500  ; partial tracking
>>      aout  resyn fst, 1, 1.5, 500, 1 ; resynthesis (up a 5th)
>> out aout, aout
>>    endin
>>
>> 
>>
>> 
>>
>> i1 0 3600
>> e
>>
>> 
>>
>> 
>>
>> and the command line: csound -M0 -+msg_color=false --expression-opt 
>> -+rtaudio=jack -odac:alsa_pcm:playback_ -iadc -b128 -B1024
>>
>> Connecting very simple sound sources I get some crackling but with 
>> complex sounds it gets completely interrupted and the cpu usage goes 
>> to 100%. Is it appropriate to expect these opcodes to work in 
>> realtime? The other PVS opcodes (non TRACKS) work perfectly and using 
>> very little cpu power. My system is a P4 HT 2.8 GHz and I'm using 
>> Csound 5.01 and a 2.6.15 Linux kernel with realtime preemption patches.
>
>

It's very processor intensive. However I can run much of it in my 2.8 GHz PC in
realtime. You can always limit the tracks for resynthesis, or change the
analysis threshold, which will help reduce the number of tracks and
allow for realtime.

Victor

At 19:59 22/03/2006, you wrote:
>TRACKS format with ksmps=1 ???
>
>This new format is very high quality but also CPU intensive. I view it as 
>true to Csound's historical form: the most state of the art technology at 
>the expense of being limited almost exclusively to non-realtime.
>
>You can of course try all the standard tricks like --sched or renice to 
>alter the CPU processing priority, but in my experience, TRACKS format 
>works the best in an offline situation - and even then takes a LONG time 
>to render (but sounds amazing!)
>
>
>-David
>
>On Mar 22, 2006, at 2:53 PM, Hector Centeno-Garcia wrote:
>
>>Hi,
>>
>>I was experimenting with the new opcodes using the pvs TRACKS format and 
>>I found that I get lots of xruns in jack.
>>
>>This is the csd file I'm using:
>>
>>
>>
>>
>>sr=44100
>>ksmps=1
>>nchnls=2
>>
>>gid ftgen 1, 0, 1024, 10, 1
>>
>>    instr 1    ;untitled
>>ain inch 1                  ; input signal
>>fs1,fsi2 pvsifd ain,2048,512,1 ; pvsifd analysis
>>fst  partials fs1,fsi2,.003,1,3,500  ; partial tracking
>>      aout  resyn fst, 1, 1.5, 500, 1 ; resynthesis (up a 5th)
>>out aout, aout
>>    endin
>>
>>
>>
>>
>>
>>i1 0 3600
>>e
>>
>>
>>
>>
>>
>>and the command line: csound -M0 -+msg_color=false --expression-opt 
>>-+rtaudio=jack -odac:alsa_pcm:playback_ -iadc -b128 -B1024
>>
>>Connecting very simple sound sources I get some crackling but with 
>>complex sounds it gets completely interrupted and the cpu usage goes to 
>>100%. Is it appropriate to expect these opcodes to work in realtime? The 
>>other PVS opcodes (non TRACKS) work perfectly and using very little cpu 
>>power. My system is a P4 HT 2.8 GHz and I'm using Csound 5.01 and a 
>>2.6.15 Linux kernel with realtime preemption patches.
>
>--
>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