Running Csound through different hosts - performance issues

[Bernt Isak Wærstad]

This mail follows up the discussion I had with jpff and Victor in Hannover at the Csound conference concerning using different buffer sizes at the same time. Since this goes out to all I should briefly explain the backdrop.

In my live setup I use Ableton Live as a host combining different processing from VSTs, Max, Lives internal effects and Csound where Hadron is a key piece of the setup. The problem is that with Hadron I really can't have a low buffer size without the sound starting to crack up. At first I thought this was natural since it's quite CPU intensive indeed, but then I realized that it only uses about 14-15% for one instance and with VSTs, internal effects and some of the other Csound effects I could go as high as 70% before the audio started to break. Since Hadron sort of introduces a minimum latency because of the granular synthesis and the fact that I'm mostly using it as a  time based "send effect", I didn't mind having high buffer size with lots of latency, but the problem is combining Hadron with serial/insert effects (like a phaser for instance) in the same setup.

So that's why I asked John and Victor if it was possible to have different buffer sizes at the same time (high latency and low latency tracks). Working with Csound through a host disables -b and -B if I understood correctly, so setting a ksmps higher than host buffer size is the only way to force Csound to have higher buffer size than the host. That is ksmps=Csound buffer size if ksmps>host buffer size. I've tested this and it seems correct (with host buffer size=64 and ksmps=256, more latency was introduced on the track with audio straight through Csound than on a clean track with audio straight through), but the problem is that it doesn't help. While investigating this, I discovered that routing the audio through Jack or Max for Live in edit mode (with preview on of course) does help! 

I haven't tested this on Hadron, but on a simple pvsblur example (attached) which produced the same errors. Here's a list of my test results:

Csound in Max for Live or CsoundPlugin in Live: Live buffer size=64, ksmps=32 : NOT OK

Csound in Max for Live or CsoundPlugin in Live: Live buffer size=64, ksmps=64 : NOT OK

Csound in Max for Live or CsoundPlugin in Live: Live buffer size=64, ksmps=128 : NOT OK

Csound in Max for Live or CsoundPlugin in Live: Live buffer size=128, ksmps=32 : OK with blur time up to ~0.6

Csound in Max for Live or CsoundPlugin in Live: Live buffer size=256, ksmps=32 : OK

Csound in Max for Live in Live - in preview mode (patch open for editing): buffer size=64, ksmps=32 : OK

Reaper with Sigurds Csound VST Plugin:

On a playback track in Reaper: Reaper buffer size=64, ksmps=32 : OK

On a input track (record enable and monitoring) in Reaper: Reaper buffer size=64, ksmps=32 : NOT OK

On a input track (record enable and monitoring) in Reaper: Reaper buffer size=64, ksmps=64 : NOT OK

On a input track (record enable and monitoring) in Reaper: Reaper buffer size=64, ksmps=128 : NOT OK

On a input track (record enable and monitoring) in Reaper: Reaper buffer size=128, ksmps=32 : OK with blur time up to ~0.6

On a input track (record enable and monitoring) in Reaper: Reaper buffer size=256, ksmps=32 : OK

Connecting Csound and Live through Jack: Jack buffer size=64, ksmps=32 : OK

Csound standalone: -b32, -B64, ksmps=16 : NOT OK, but fewer crackle artifacts than with Reaper or Live 

Csound standalone: -b32, -B64, ksmps=32 : NOT OK, but fewer crackle artifacts than with Reaper or Live 

Csound standalone: -b64, -B128, ksmps=32 : NOT OK, but almost 

Csound standalone: -b128, -B256, ksmps=64 : OK

Csound standalone through Jack: Jack buffer size=64, ksmps=32 : OK

-- 

Mvh.

Bernt Isak Wærstad

[Michael Gogins-2]

It might be that some hosts access the raw Csound buffers, i.e. the
spin and spout buffers, directly. They contain one kperiod worth of
audio. It might be that other hosts do not do this, but rely on the
intermediate buffers, whose size is controlled by -b. These two
methods might possibly behave differently.

I recommend that programmers putting Csound into hosts use spin and
spout directly. This affords the lowest latency. However this is the
"lower half" of the audio driver. The host's own send and receive
buffers would be the "upper half" of the audio driver and might have a
very different size/latency. This is not a problem for feeding audio,
the receive and send loops for copying data into and out of spin and
spout would have one set of indices for spin and spout, and another
set of indices for the host output and input buffers (see
CsoundVST.cpp for an example).

If the plugin uses -b then it is possible that Csound's buffers and
the host buffers need to be aligned in size. Or not. It depends on how
the plugin is programmed.

Hope this helps,
Mike

On Mon, Feb 20, 2012 at 10:53 AM, Bernt Isak Wærstad
<[hidden email]> wrote:

> This mail follows up the discussion I had with jpff and Victor in Hannover
> at the Csound conference concerning using different buffer sizes at the same
> time. Since this goes out to all I should briefly explain the backdrop.
>
> In my live setup I use Ableton Live as a host combining different processing
> from VSTs, Max, Lives internal effects and Csound where Hadron is a key
> piece of the setup. The problem is that with Hadron I really can't have a
> low buffer size without the sound starting to crack up. At first I thought
> this was natural since it's quite CPU intensive indeed, but then
> I realized that it only uses about 14-15% for one instance and with VSTs,
> internal effects and some of the other Csound effects I could go as high as
> 70% before the audio started to break. Since Hadron sort of introduces a
> minimum latency because of the granular synthesis and the fact that I'm
> mostly using it as a  time based "send effect", I didn't mind having high
> buffer size with lots of latency, but the problem is combining Hadron with
> serial/insert effects (like a phaser for instance) in the same setup.
>
> So that's why I asked John and Victor if it was possible to have different
> buffer sizes at the same time (high latency and low latency tracks). Working
> with Csound through a host disables -b and -B if I understood correctly, so
> setting a ksmps higher than host buffer size is the only way to force Csound
> to have higher buffer size than the host. That is ksmps=Csound buffer size
> if ksmps>host buffer size. I've tested this and it seems correct (with host
> buffer size=64 and ksmps=256, more latency was introduced on the track with
> audio straight through Csound than on a clean track with audio straight
> through), but the problem is that it doesn't help. While investigating this,
> I discovered that routing the audio through Jack or Max for Live in edit
> mode (with preview on of course) does help!
>
> I haven't tested this on Hadron, but on a simple pvsblur example (attached)
> which produced the same errors. Here's a list of my test results:
>
> Csound in Max for Live or CsoundPlugin in Live: Live buffer size=64,
> ksmps=32 : NOT OK
> Csound in Max for Live or CsoundPlugin in Live: Live buffer size=64,
> ksmps=64 : NOT OK
> Csound in Max for Live or CsoundPlugin in Live: Live buffer size=64,
> ksmps=128 : NOT OK
> Csound in Max for Live or CsoundPlugin in Live: Live buffer size=128,
> ksmps=32 : OK with blur time up to ~0.6
> Csound in Max for Live or CsoundPlugin in Live: Live buffer size=256,
> ksmps=32 : OK
>
> Csound in Max for Live in Live - in preview mode (patch open for editing):
> buffer size=64, ksmps=32 : OK
>
> Reaper with Sigurds Csound VST Plugin:
> On a playback track in Reaper: Reaper buffer size=64, ksmps=32 : OK
> On a input track (record enable and monitoring) in Reaper: Reaper buffer
> size=64, ksmps=32 : NOT OK
> On a input track (record enable and monitoring) in Reaper: Reaper buffer
> size=64, ksmps=64 : NOT OK
> On a input track (record enable and monitoring) in Reaper: Reaper buffer
> size=64, ksmps=128 : NOT OK
> On a input track (record enable and monitoring) in Reaper: Reaper buffer
> size=128, ksmps=32 : OK with blur time up to ~0.6
> On a input track (record enable and monitoring) in Reaper: Reaper buffer
> size=256, ksmps=32 : OK
>
> Connecting Csound and Live through Jack: Jack buffer size=64, ksmps=32 : OK
>
> Csound standalone: -b32, -B64, ksmps=16 : NOT OK, but fewer crackle
> artifacts than with Reaper or Live
> Csound standalone: -b32, -B64, ksmps=32 : NOT OK, but fewer crackle
> artifacts than with Reaper or Live
> Csound standalone: -b64, -B128, ksmps=32 : NOT OK, but almost
> Csound standalone: -b128, -B256, ksmps=64 : OK
>
> Csound standalone through Jack: Jack buffer size=64, ksmps=32 : OK
>
> --
> Mvh.
>
> Bernt Isak Wærstad
>
>
>

--
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com


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 [hidden email] with body "unsubscribe csound"

[Victor Lazzarini]

csoundapi~  uses spin/spout and csoundPerformKsmps. I expect csound~ to do the same.

Victor
On 20 Feb 2012, at 17:26, Michael Gogins wrote:

> It might be that some hosts access the raw Csound buffers, i.e. the
> spin and spout buffers, directly. They contain one kperiod worth of
> audio. It might be that other hosts do not do this, but rely on the
> intermediate buffers, whose size is controlled by -b. These two
> methods might possibly behave differently.
>
> I recommend that programmers putting Csound into hosts use spin and
> spout directly. This affords the lowest latency. However this is the
> "lower half" of the audio driver. The host's own send and receive
> buffers would be the "upper half" of the audio driver and might have a
> very different size/latency. This is not a problem for feeding audio,
> the receive and send loops for copying data into and out of spin and
> spout would have one set of indices for spin and spout, and another
> set of indices for the host output and input buffers (see
> CsoundVST.cpp for an example).
>
> If the plugin uses -b then it is possible that Csound's buffers and
> the host buffers need to be aligned in size. Or not. It depends on how
> the plugin is programmed.
>
> Hope this helps,
> Mike
>
> On Mon, Feb 20, 2012 at 10:53 AM, Bernt Isak Wærstad
> <[hidden email]> wrote:
>> This mail follows up the discussion I had with jpff and Victor in Hannover
>> at the Csound conference concerning using different buffer sizes at the same
>> time. Since this goes out to all I should briefly explain the backdrop.
>>
>> In my live setup I use Ableton Live as a host combining different processing
>> from VSTs, Max, Lives internal effects and Csound where Hadron is a key
>> piece of the setup. The problem is that with Hadron I really can't have a
>> low buffer size without the sound starting to crack up. At first I thought
>> this was natural since it's quite CPU intensive indeed, but then
>> I realized that it only uses about 14-15% for one instance and with VSTs,
>> internal effects and some of the other Csound effects I could go as high as
>> 70% before the audio started to break. Since Hadron sort of introduces a
>> minimum latency because of the granular synthesis and the fact that I'm
>> mostly using it as a  time based "send effect", I didn't mind having high
>> buffer size with lots of latency, but the problem is combining Hadron with
>> serial/insert effects (like a phaser for instance) in the same setup.
>>
>> So that's why I asked John and Victor if it was possible to have different
>> buffer sizes at the same time (high latency and low latency tracks). Working
>> with Csound through a host disables -b and -B if I understood correctly, so
>> setting a ksmps higher than host buffer size is the only way to force Csound
>> to have higher buffer size than the host. That is ksmps=Csound buffer size
>> if ksmps>host buffer size. I've tested this and it seems correct (with host
>> buffer size=64 and ksmps=256, more latency was introduced on the track with
>> audio straight through Csound than on a clean track with audio straight
>> through), but the problem is that it doesn't help. While investigating this,
>> I discovered that routing the audio through Jack or Max for Live in edit
>> mode (with preview on of course) does help!
>>
>> I haven't tested this on Hadron, but on a simple pvsblur example (attached)
>> which produced the same errors. Here's a list of my test results:
>>
>> Csound in Max for Live or CsoundPlugin in Live: Live buffer size=64,
>> ksmps=32 : NOT OK
>> Csound in Max for Live or CsoundPlugin in Live: Live buffer size=64,
>> ksmps=64 : NOT OK
>> Csound in Max for Live or CsoundPlugin in Live: Live buffer size=64,
>> ksmps=128 : NOT OK
>> Csound in Max for Live or CsoundPlugin in Live: Live buffer size=128,
>> ksmps=32 : OK with blur time up to ~0.6
>> Csound in Max for Live or CsoundPlugin in Live: Live buffer size=256,
>> ksmps=32 : OK
>>
>> Csound in Max for Live in Live - in preview mode (patch open for editing):
>> buffer size=64, ksmps=32 : OK
>>
>> Reaper with Sigurds Csound VST Plugin:
>> On a playback track in Reaper: Reaper buffer size=64, ksmps=32 : OK
>> On a input track (record enable and monitoring) in Reaper: Reaper buffer
>> size=64, ksmps=32 : NOT OK
>> On a input track (record enable and monitoring) in Reaper: Reaper buffer
>> size=64, ksmps=64 : NOT OK
>> On a input track (record enable and monitoring) in Reaper: Reaper buffer
>> size=64, ksmps=128 : NOT OK
>> On a input track (record enable and monitoring) in Reaper: Reaper buffer
>> size=128, ksmps=32 : OK with blur time up to ~0.6
>> On a input track (record enable and monitoring) in Reaper: Reaper buffer
>> size=256, ksmps=32 : OK
>>
>> Connecting Csound and Live through Jack: Jack buffer size=64, ksmps=32 : OK
>>
>> Csound standalone: -b32, -B64, ksmps=16 : NOT OK, but fewer crackle
>> artifacts than with Reaper or Live
>> Csound standalone: -b32, -B64, ksmps=32 : NOT OK, but fewer crackle
>> artifacts than with Reaper or Live
>> Csound standalone: -b64, -B128, ksmps=32 : NOT OK, but almost
>> Csound standalone: -b128, -B256, ksmps=64 : OK
>>
>> Csound standalone through Jack: Jack buffer size=64, ksmps=32 : OK
>>
>> --
>> Mvh.
>>
>> Bernt Isak Wærstad
>>
>>
>>
>
>
>
> --
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
>
> 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 [hidden email] with body "unsubscribe csound"
>

Dr Victor Lazzarini
Senior Lecturer
Dept. of Music
NUI Maynooth Ireland
tel.: [phone]
Victor dot Lazzarini AT nuim dot ie





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 [hidden email] with body "unsubscribe csound"

[rory walsh]

Cabbage does the same.

On 20 February 2012 17:39, Victor Lazzarini <[hidden email]> wrote:

> csoundapi~  uses spin/spout and csoundPerformKsmps. I expect csound~ to do the same.
>
> Victor
> On 20 Feb 2012, at 17:26, Michael Gogins wrote:
>
>> It might be that some hosts access the raw Csound buffers, i.e. the
>> spin and spout buffers, directly. They contain one kperiod worth of
>> audio. It might be that other hosts do not do this, but rely on the
>> intermediate buffers, whose size is controlled by -b. These two
>> methods might possibly behave differently.
>>
>> I recommend that programmers putting Csound into hosts use spin and
>> spout directly. This affords the lowest latency. However this is the
>> "lower half" of the audio driver. The host's own send and receive
>> buffers would be the "upper half" of the audio driver and might have a
>> very different size/latency. This is not a problem for feeding audio,
>> the receive and send loops for copying data into and out of spin and
>> spout would have one set of indices for spin and spout, and another
>> set of indices for the host output and input buffers (see
>> CsoundVST.cpp for an example).
>>
>> If the plugin uses -b then it is possible that Csound's buffers and
>> the host buffers need to be aligned in size. Or not. It depends on how
>> the plugin is programmed.
>>
>> Hope this helps,
>> Mike
>>
>> On Mon, Feb 20, 2012 at 10:53 AM, Bernt Isak Wærstad
>> <[hidden email]> wrote:
>>> This mail follows up the discussion I had with jpff and Victor in Hannover
>>> at the Csound conference concerning using different buffer sizes at the same
>>> time. Since this goes out to all I should briefly explain the backdrop.
>>>
>>> In my live setup I use Ableton Live as a host combining different processing
>>> from VSTs, Max, Lives internal effects and Csound where Hadron is a key
>>> piece of the setup. The problem is that with Hadron I really can't have a
>>> low buffer size without the sound starting to crack up. At first I thought
>>> this was natural since it's quite CPU intensive indeed, but then
>>> I realized that it only uses about 14-15% for one instance and with VSTs,
>>> internal effects and some of the other Csound effects I could go as high as
>>> 70% before the audio started to break. Since Hadron sort of introduces a
>>> minimum latency because of the granular synthesis and the fact that I'm
>>> mostly using it as a  time based "send effect", I didn't mind having high
>>> buffer size with lots of latency, but the problem is combining Hadron with
>>> serial/insert effects (like a phaser for instance) in the same setup.
>>>
>>> So that's why I asked John and Victor if it was possible to have different
>>> buffer sizes at the same time (high latency and low latency tracks). Working
>>> with Csound through a host disables -b and -B if I understood correctly, so
>>> setting a ksmps higher than host buffer size is the only way to force Csound
>>> to have higher buffer size than the host. That is ksmps=Csound buffer size
>>> if ksmps>host buffer size. I've tested this and it seems correct (with host
>>> buffer size=64 and ksmps=256, more latency was introduced on the track with
>>> audio straight through Csound than on a clean track with audio straight
>>> through), but the problem is that it doesn't help. While investigating this,
>>> I discovered that routing the audio through Jack or Max for Live in edit
>>> mode (with preview on of course) does help!
>>>
>>> I haven't tested this on Hadron, but on a simple pvsblur example (attached)
>>> which produced the same errors. Here's a list of my test results:
>>>
>>> Csound in Max for Live or CsoundPlugin in Live: Live buffer size=64,
>>> ksmps=32 : NOT OK
>>> Csound in Max for Live or CsoundPlugin in Live: Live buffer size=64,
>>> ksmps=64 : NOT OK
>>> Csound in Max for Live or CsoundPlugin in Live: Live buffer size=64,
>>> ksmps=128 : NOT OK
>>> Csound in Max for Live or CsoundPlugin in Live: Live buffer size=128,
>>> ksmps=32 : OK with blur time up to ~0.6
>>> Csound in Max for Live or CsoundPlugin in Live: Live buffer size=256,
>>> ksmps=32 : OK
>>>
>>> Csound in Max for Live in Live - in preview mode (patch open for editing):
>>> buffer size=64, ksmps=32 : OK
>>>
>>> Reaper with Sigurds Csound VST Plugin:
>>> On a playback track in Reaper: Reaper buffer size=64, ksmps=32 : OK
>>> On a input track (record enable and monitoring) in Reaper: Reaper buffer
>>> size=64, ksmps=32 : NOT OK
>>> On a input track (record enable and monitoring) in Reaper: Reaper buffer
>>> size=64, ksmps=64 : NOT OK
>>> On a input track (record enable and monitoring) in Reaper: Reaper buffer
>>> size=64, ksmps=128 : NOT OK
>>> On a input track (record enable and monitoring) in Reaper: Reaper buffer
>>> size=128, ksmps=32 : OK with blur time up to ~0.6
>>> On a input track (record enable and monitoring) in Reaper: Reaper buffer
>>> size=256, ksmps=32 : OK
>>>
>>> Connecting Csound and Live through Jack: Jack buffer size=64, ksmps=32 : OK
>>>
>>> Csound standalone: -b32, -B64, ksmps=16 : NOT OK, but fewer crackle
>>> artifacts than with Reaper or Live
>>> Csound standalone: -b32, -B64, ksmps=32 : NOT OK, but fewer crackle
>>> artifacts than with Reaper or Live
>>> Csound standalone: -b64, -B128, ksmps=32 : NOT OK, but almost
>>> Csound standalone: -b128, -B256, ksmps=64 : OK
>>>
>>> Csound standalone through Jack: Jack buffer size=64, ksmps=32 : OK
>>>
>>> --
>>> Mvh.
>>>
>>> Bernt Isak Wærstad
>>>
>>>
>>>
>>
>>
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>>
>> 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 [hidden email] with body "unsubscribe csound"
>>
>
> Dr Victor Lazzarini
> Senior Lecturer
> Dept. of Music
> NUI Maynooth Ireland
> tel.: [phone]
> Victor dot Lazzarini AT nuim dot ie
>
>
>
>
>
> 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 [hidden email] 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 [hidden email] with body "unsubscribe csound"

[Sigurd Saue-2]

And so does the CSoundPlugin. I suspect some have been looking at the same code for inspiration ...

Sigurd

-----Original Message-----
From: Rory Walsh [mailto:[hidden email]]
Sent: Monday, February 20, 2012 6:41 PM
To: [hidden email]
Subject: Re: [Csnd] Running Csound through different hosts - performance issues

Cabbage does the same.

On 20 February 2012 17:39, Victor Lazzarini <[hidden email]> wrote:

> csoundapi~  uses spin/spout and csoundPerformKsmps. I expect csound~ to do the same.
>
> Victor
> On 20 Feb 2012, at 17:26, Michael Gogins wrote:
>
>> It might be that some hosts access the raw Csound buffers, i.e. the
>> spin and spout buffers, directly. They contain one kperiod worth of
>> audio. It might be that other hosts do not do this, but rely on the
>> intermediate buffers, whose size is controlled by -b. These two
>> methods might possibly behave differently.
>>
>> I recommend that programmers putting Csound into hosts use spin and
>> spout directly. This affords the lowest latency. However this is the
>> "lower half" of the audio driver. The host's own send and receive
>> buffers would be the "upper half" of the audio driver and might have
>> a very different size/latency. This is not a problem for feeding
>> audio, the receive and send loops for copying data into and out of
>> spin and spout would have one set of indices for spin and spout, and
>> another set of indices for the host output and input buffers (see
>> CsoundVST.cpp for an example).
>>
>> If the plugin uses -b then it is possible that Csound's buffers and
>> the host buffers need to be aligned in size. Or not. It depends on
>> how the plugin is programmed.
>>
>> Hope this helps,
>> Mike
>>
>> On Mon, Feb 20, 2012 at 10:53 AM, Bernt Isak Wærstad
>> <[hidden email]> wrote:
>>> This mail follows up the discussion I had with jpff and Victor in
>>> Hannover at the Csound conference concerning using different buffer
>>> sizes at the same time. Since this goes out to all I should briefly explain the backdrop.
>>>
>>> In my live setup I use Ableton Live as a host combining different
>>> processing from VSTs, Max, Lives internal effects and Csound where
>>> Hadron is a key piece of the setup. The problem is that with Hadron
>>> I really can't have a low buffer size without the sound starting to
>>> crack up. At first I thought this was natural since it's quite CPU
>>> intensive indeed, but then I realized that it only uses about 14-15%
>>> for one instance and with VSTs, internal effects and some of the
>>> other Csound effects I could go as high as 70% before the audio
>>> started to break. Since Hadron sort of introduces a minimum latency
>>> because of the granular synthesis and the fact that I'm mostly using
>>> it as a  time based "send effect", I didn't mind having high buffer
>>> size with lots of latency, but the problem is combining Hadron with serial/insert effects (like a phaser for instance) in the same setup.
>>>
>>> So that's why I asked John and Victor if it was possible to have
>>> different buffer sizes at the same time (high latency and low
>>> latency tracks). Working with Csound through a host disables -b and
>>> -B if I understood correctly, so setting a ksmps higher than host
>>> buffer size is the only way to force Csound to have higher buffer
>>> size than the host. That is ksmps=Csound buffer size if ksmps>host
>>> buffer size. I've tested this and it seems correct (with host buffer
>>> size=64 and ksmps=256, more latency was introduced on the track with
>>> audio straight through Csound than on a clean track with audio
>>> straight through), but the problem is that it doesn't help. While
>>> investigating this, I discovered that routing the audio through Jack or Max for Live in edit mode (with preview on of course) does help!
>>>
>>> I haven't tested this on Hadron, but on a simple pvsblur example
>>> (attached) which produced the same errors. Here's a list of my test results:
>>>
>>> Csound in Max for Live or CsoundPlugin in Live: Live buffer size=64,
>>> ksmps=32 : NOT OK
>>> Csound in Max for Live or CsoundPlugin in Live: Live buffer size=64,
>>> ksmps=64 : NOT OK
>>> Csound in Max for Live or CsoundPlugin in Live: Live buffer size=64,
>>> ksmps=128 : NOT OK
>>> Csound in Max for Live or CsoundPlugin in Live: Live buffer
>>> size=128,
>>> ksmps=32 : OK with blur time up to ~0.6 Csound in Max for Live or
>>> CsoundPlugin in Live: Live buffer size=256,
>>> ksmps=32 : OK
>>>
>>> Csound in Max for Live in Live - in preview mode (patch open for editing):
>>> buffer size=64, ksmps=32 : OK
>>>
>>> Reaper with Sigurds Csound VST Plugin:
>>> On a playback track in Reaper: Reaper buffer size=64, ksmps=32 : OK
>>> On a input track (record enable and monitoring) in Reaper: Reaper
>>> buffer size=64, ksmps=32 : NOT OK On a input track (record enable
>>> and monitoring) in Reaper: Reaper buffer size=64, ksmps=64 : NOT OK
>>> On a input track (record enable and monitoring) in Reaper: Reaper
>>> buffer size=64, ksmps=128 : NOT OK On a input track (record enable
>>> and monitoring) in Reaper: Reaper buffer size=128, ksmps=32 : OK
>>> with blur time up to ~0.6 On a input track (record enable and
>>> monitoring) in Reaper: Reaper buffer size=256, ksmps=32 : OK
>>>
>>> Connecting Csound and Live through Jack: Jack buffer size=64,
>>> ksmps=32 : OK
>>>
>>> Csound standalone: -b32, -B64, ksmps=16 : NOT OK, but fewer crackle
>>> artifacts than with Reaper or Live Csound standalone: -b32, -B64,
>>> ksmps=32 : NOT OK, but fewer crackle artifacts than with Reaper or
>>> Live Csound standalone: -b64, -B128, ksmps=32 : NOT OK, but almost
>>> Csound standalone: -b128, -B256, ksmps=64 : OK
>>>
>>> Csound standalone through Jack: Jack buffer size=64, ksmps=32 : OK
>>>
>>> --
>>> Mvh.
>>>
>>> Bernt Isak Wærstad
>>>
>>>
>>>
>>
>>
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>>
>> 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 [hidden email] with body "unsubscribe csound"
>>
>
> Dr Victor Lazzarini
> Senior Lecturer
> Dept. of Music
> NUI Maynooth Ireland
> tel.: [phone]
> Victor dot Lazzarini AT nuim dot ie
>
>
>
>
>
> 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 [hidden email] 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 [hidden email] 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 [hidden email] with body "unsubscribe csound"

[rory walsh]

Guilty as charged! I lifeted a fair chunk from csLADSPA!


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 [hidden email] with body "unsubscribe csound"

[Victor Lazzarini]

It's not for no reason that the code is LGPL.
On 21 Feb 2012, at 11:26, Rory Walsh wrote:

> Guilty as charged! I lifeted a fair chunk from csLADSPA!
>
>
> 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 [hidden email] with body "unsubscribe csound"
>

Dr Victor Lazzarini
Senior Lecturer
Dept. of Music
NUI Maynooth Ireland
tel.: [phone]
Victor dot Lazzarini AT nuim dot ie





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 [hidden email] with body "unsubscribe csound"

[Sigurd Saue-2]

Let's just hope the original piece of code was reasonably good, since it's now multiplying all over the place ...

Sigurd

-----Original Message-----
From: Victor Lazzarini [mailto:[hidden email]]
Sent: Tuesday, February 21, 2012 12:51 PM
To: [hidden email]
Subject: Re: [Csnd] Running Csound through different hosts - performance

It's not for no reason that the code is LGPL.
On 21 Feb 2012, at 11:26, Rory Walsh wrote:

> Guilty as charged! I lifeted a fair chunk from csLADSPA!
>
>
> 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 [hidden email] with body "unsubscribe csound"
>

Dr Victor Lazzarini
Senior Lecturer
Dept. of Music
NUI Maynooth Ireland
tel.: [phone]
Victor dot Lazzarini AT nuim dot ie





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 [hidden email] 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 [hidden email] with body "unsubscribe csound"

[rory walsh]

I know Victor and I had teh csLADSPA stuff working very well so it was
as good a place to start as any. The Csound development chain is only
as strong as its weakest code!



On 21 February 2012 03:58, Sigurd Saue <[hidden email]> wrote:

> Let's just hope the original piece of code was reasonably good, since it's now multiplying all over the place ...
>
> Sigurd
>
> -----Original Message-----
> From: Victor Lazzarini [mailto:[hidden email]]
> Sent: Tuesday, February 21, 2012 12:51 PM
> To: [hidden email]
> Subject: Re: [Csnd] Running Csound through different hosts - performance
>
> It's not for no reason that the code is LGPL.
> On 21 Feb 2012, at 11:26, Rory Walsh wrote:
>
>> Guilty as charged! I lifeted a fair chunk from csLADSPA!
>>
>>
>> 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 [hidden email] with body "unsubscribe csound"
>>
>
> Dr Victor Lazzarini
> Senior Lecturer
> Dept. of Music
> NUI Maynooth Ireland
> tel.: [phone]
> Victor dot Lazzarini AT nuim dot ie
>
>
>
>
>
> 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 [hidden email] 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 [hidden email] 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 [hidden email] with body "unsubscribe csound"

[Bernt Isak Wærstad]

But even though spin/spout vs. using -b might explain how Jack works differently, it does not explain why the audio doesn't crack up when a MFL device with csound~ is in edit mode, but does when i "run mode", does it? Maybe I'm missing something from your explanation there Mike.

And you'll have to excuse my ignorance, but I really don't understand why the pvsblur example makes the audio break up with buffer sizes all the way up to 200+ and a CPU utilization below 10%? Since increasing the ksmps increase the latency through Csound, but doesn't help on the break up it might be that this problem isn't just related to buffer sizes?

On Tue, Feb 21, 2012 at 1:01 PM, Rory Walsh <[hidden email]> wrote:

I know Victor and I had teh csLADSPA stuff working very well so it was
as good a place to start as any. The Csound development chain is only
as strong as its weakest code!

On 21 February 2012 03:58, Sigurd Saue <[hidden email]> wrote:
> Let's just hope the original piece of code was reasonably good, since it's now multiplying all over the place ...
>
> Sigurd
>
> -----Original Message-----
> From: Victor Lazzarini [mailto:[hidden email]]
> Sent: Tuesday, February 21, 2012 12:51 PM
> To: [hidden email]
> Subject: Re: [Csnd] Running Csound through different hosts - performance
>
> It's not for no reason that the code is LGPL.
> On 21 Feb 2012, at 11:26, Rory Walsh wrote:
>
>> Guilty as charged! I lifeted a fair chunk from csLADSPA!
>>
>>
>> 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 [hidden email] with body "unsubscribe csound"
>>
>
> Dr Victor Lazzarini
> Senior Lecturer
> Dept. of Music
> NUI Maynooth Ireland
> tel.: <a href="tel:%2B353%201%20708%203545" value="[phone]">[phone]
> Victor dot Lazzarini AT nuim dot ie
>
>
>
>
>
> 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 [hidden email] 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 [hidden email] 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 [hidden email] with body "unsubscribe csound"

--
Mvh.

Bernt Isak Wærstad

[Michael Gogins-2]

What is an MFL device?

Regards,
Mike

On Tue, Feb 21, 2012 at 11:17 AM, Bernt Isak Wærstad
<[hidden email]> wrote:

> But even though spin/spout vs. using -b might explain how Jack works
> differently, it does not explain why the audio doesn't crack up when a MFL
> device with csound~ is in edit mode, but does when i "run mode", does it?
> Maybe I'm missing something from your explanation there Mike.
>
> And you'll have to excuse my ignorance, but I really don't understand why
> the pvsblur example makes the audio break up with buffer sizes all the way
> up to 200+ and a CPU utilization below 10%? Since increasing the ksmps
> increase the latency through Csound, but doesn't help on the break up it
> might be that this problem isn't just related to buffer sizes?
>
> On Tue, Feb 21, 2012 at 1:01 PM, Rory Walsh <[hidden email]> wrote:
>>
>> I know Victor and I had teh csLADSPA stuff working very well so it was
>> as good a place to start as any. The Csound development chain is only
>> as strong as its weakest code!
>>
>>
>>
>> On 21 February 2012 03:58, Sigurd Saue <[hidden email]> wrote:
>> > Let's just hope the original piece of code was reasonably good, since
>> > it's now multiplying all over the place ...
>> >
>> > Sigurd
>> >
>> > -----Original Message-----
>> > From: Victor Lazzarini [mailto:[hidden email]]
>> > Sent: Tuesday, February 21, 2012 12:51 PM
>> > To: [hidden email]
>> > Subject: Re: [Csnd] Running Csound through different hosts - performance
>> >
>> > It's not for no reason that the code is LGPL.
>> > On 21 Feb 2012, at 11:26, Rory Walsh wrote:
>> >
>> >> Guilty as charged! I lifeted a fair chunk from csLADSPA!
>> >>
>> >>
>> >> 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 [hidden email] with body "unsubscribe csound"
>> >>
>> >
>> > Dr Victor Lazzarini
>> > Senior Lecturer
>> > Dept. of Music
>> > NUI Maynooth Ireland
>> > tel.: [phone]
>> > Victor dot Lazzarini AT nuim dot ie
>> >
>> >
>> >
>> >
>> >
>> > 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 [hidden email] 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 [hidden email] 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 [hidden email] with body "unsubscribe
>> csound"
>>
>
>
>
> --
> Mvh.
>
> Bernt Isak Wærstad
>
>
>

--
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com


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 [hidden email] with body "unsubscribe csound"

[Bernt Isak Wærstad]

Sorry, just to used to abbreviation. MFL = Max for Live. They call them devices instead of patches (like with normal Max/MSP). When you're in editing mode, a new copy of the device is created and if preview mode is on, you're listening to the one you're editing with audio, midi etc being sent between Live and Max.

http://www.cycling74.com/docs/max5/vignettes/core/live_preview.html

On Tue, Feb 21, 2012 at 5:29 PM, Michael Gogins <[hidden email]> wrote:

What is an MFL device?

Regards,
Mike

On Tue, Feb 21, 2012 at 11:17 AM, Bernt Isak Wærstad
<[hidden email]> wrote:
> But even though spin/spout vs. using -b might explain how Jack works
> differently, it does not explain why the audio doesn't crack up when a MFL
> device with csound~ is in edit mode, but does when i "run mode", does it?
> Maybe I'm missing something from your explanation there Mike.
>
> And you'll have to excuse my ignorance, but I really don't understand why
> the pvsblur example makes the audio break up with buffer sizes all the way
> up to 200+ and a CPU utilization below 10%? Since increasing the ksmps
> increase the latency through Csound, but doesn't help on the break up it
> might be that this problem isn't just related to buffer sizes?
>
> On Tue, Feb 21, 2012 at 1:01 PM, Rory Walsh <[hidden email]> wrote:
>>
>> I know Victor and I had teh csLADSPA stuff working very well so it was
>> as good a place to start as any. The Csound development chain is only
>> as strong as its weakest code!
>>
>>
>>
>> On 21 February 2012 03:58, Sigurd Saue <[hidden email]> wrote:
>> > Let's just hope the original piece of code was reasonably good, since
>> > it's now multiplying all over the place ...
>> >
>> > Sigurd
>> >
>> > -----Original Message-----
>> > From: Victor Lazzarini [mailto:[hidden email]]
>> > Sent: Tuesday, February 21, 2012 12:51 PM
>> > To: [hidden email]
>> > Subject: Re: [Csnd] Running Csound through different hosts - performance
>> >
>> > It's not for no reason that the code is LGPL.
>> > On 21 Feb 2012, at 11:26, Rory Walsh wrote:
>> >
>> >> Guilty as charged! I lifeted a fair chunk from csLADSPA!
>> >>
>> >>
>> >> 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 [hidden email] with body "unsubscribe csound"
>> >>
>> >
>> > Dr Victor Lazzarini
>> > Senior Lecturer
>> > Dept. of Music
>> > NUI Maynooth Ireland
>> > tel.: <a href="tel:%2B353%201%20708%203545" value="[phone]">[phone]
>> > Victor dot Lazzarini AT nuim dot ie
>> >
>> >
>> >
>> >
>> >
>> > 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 [hidden email] 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 [hidden email] 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 [hidden email] with body "unsubscribe
>> csound"
>>
>
>
>
> --
> Mvh.
>
> Bernt Isak Wærstad
>
>
>

--
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

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 [hidden email] with body "unsubscribe csound"

--
Mvh.

Bernt Isak Wærstad