It's not necessary to use intermediate buffers to get Csound to work as Jack 
is designed to work.

Csound's Jack driver can be modified to work as the CsoundVST::process 
function already works (VST hosts call back for audio as Jack does). It's 
identical to your proposed design, except that the Csound output buffer 
(spout) and the Jack callback buffer may be different sizes. The Jack driver 
needs two buffer indexes that persist across Jack callbacks, that's all. 
Every time the Csound spout buffer index gets to the end of the spout 
buffer, the Jack driver calls csoundPerformKsmps and resets the spout buffer 
index to 0. Every time the Jack buffer index gets to the end of the Jack 
buffer, the Jack callback resets the Jack buffer index to 0 and returns. 
Otherwise, the Jack callback just increments both indexes and copies the 
respective frames from spout to the Jack buffer in a loop.

Regards,
Mike

----- Original Message ----- 
From: "Fons Adriaensen" 
To: 
Sent: Thursday, August 20, 2009 5:40 PM
Subject: Re: [Cs-dev] Csound rtaudio choice


On Thu, Aug 20, 2009 at 12:24:16AM +0100, Richard Dobson wrote:

> if it "works" thinking
> of jack as a soundcard even though it's not, is that OK?

For some value of 'works'. Csound is not a good Jack client,
and it will never be as long as it tries to abstract this
by using some intermediate layer.

The reason for this is quite simple.

When using most audio interfaces, an application that has
any pretences of being real-time and low-latency will
create a real-time thread that will execute the following
loop:

while (running)
{
    1. wait for some trigger
    2, get N input frames from device
    3. process N frames
    4. write N output frames to device
}

When using Jack, things are different. Jack will create
the thread and set its priority, create the loop, and
determine the block size N. You should provide a function
that executes steps 2,3,4. That function will be called
by jack whenever necessary. It must be real-time safe.

If course you can 'transorm' that to the firt model by using
intermediate buffers. That means you are throwing away all
the advantages that a system as Jack can offer.

The correct approach is to structure the application on
the callback model, and build the first model on to of
it when not using a callback based interface such as Jack.
Which just means creating the thread and the loop. SC gets
this right, why not Csound ?

> ... if the user has, as you say, already configured alsa

'Configuring alsa' does not include deciding which device
an application should use. That is part of configuring *the
application*.  There is a configured 'default' alsa device,
and that's the one an application should use if nothing else
is specified. But in most cases it wouldn't be the right one
for Csound.

My system has four alsa devices: the on-board soundcard which
is also configured to be the 'default' (low-fi, used by Firefox,
media players, skype, etc.), the modem (not used), an external
multichannel audio interface (normally used by Jack), and a high
quality stereo one. When using Csound directly with alsa I would
expect to be able to select either 1,3, or 4.

BTW I wouldn't mind at all if Csound on Linux uses *only* Jack,
and just drops alsa and everything else, *provided* the jack
interface is implemented correctly.

Ciao,

-- 
FA

Io lo dico sempre: l'Italia è troppo stretta e lunga.


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus 
on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

What Victor says is true. You'd need a new program, or change the whole driver model.

Mkg

On Aug 20, 2009 10:28 PM, <Victor.Lazzarini@nuim.ie> wrote:

yes, but then we cannot have a jack IO module as is,
because the interface for that does not allow it. We could
of course very easily have a special 'csound-jack' program
that would work exactly as you describe. This would be
very easy to implement.

I think Fons might be confusing the command 'csound'
with the Csound Library. When you say Csound does not
get it right, it's mostly to do with how the frontend is written
(to use the IO module). 

Nothing stops anyone writing a small lightweight app that
works as Michael describes. Then we just not load an IO
module and pump the spout into Jack etc.

When Fons says that SC gets it right, you have to remember
that its Linux version was built to work with Jack and
nothing else. Csound was given an IO module interface
to deal with a generic problem in a model that was
inherently blocking-IO based, which since ca. 1993
has been the RT IO way of doing things in Csound.
So the IO module interface might not suit the
callback model, but it's very easy to ditch it and do the
IO some other way, giving that Csound is a library.
You do whatever you want, in fact if you don't like
it, use csound in PD through Jack, for instance.

Btw, I never noticed myself any real problems with Csound
running in RT with alsa or Jack. In fact I have gone down to
32 samples, which for me is pretty good and more than
necessary. But if there is a need, I'd be more than happy
to write a Jack-specific client to work in the way Fons
described. It won't take that many lines of code.

Regards

Victor



----- Original Message -----
From: michael.gogins@gmail.com
Date: Thursday, August 20, 2009 8:50 pm
Subject: Re: [Cs-dev] Csound rtaudio choice
To: Developer discussions <csound-devel@lists.sourceforge.net>

> It's not necessary to use intermediate buffers to get Csound to
> work as Jack
> is designed to work.
>
> Csound's Jack driver can be modified to work as the
> CsoundVST::process
> function already works (VST hosts call back for audio as Jack
> does). It's
> identical to your proposed design, except that the Csound output
> buffer
> (spout) and the Jack callback buffer may be different sizes. The
> Jack driver
> needs two buffer indexes that persist across Jack callbacks,
> that's all.
> Every time the Csound spout buffer index gets to the end of the
> spout
> buffer, the Jack driver calls csoundPerformKsmps and resets the
> spout buffer
> index to 0. Every time the Jack buffer index gets to the end of
> the Jack
> buffer, the Jack callback resets the Jack buffer index to 0 and
> returns.
> Otherwise, the Jack callback just increments both indexes and
> copies the
> respective frames from spout to the Jack buffer in a loop.
>
> Regards,
> Mike
>
> ----- Original Message -----
> From: "Fons Adriaensen" <fons@kokkinizita.net>
> To: <csound-devel@lists.sourceforge.net>
> Sent: Thursday, August 20, 2009 5:40 PM
> Subject: Re: [Cs-dev] Csound rtaudio choice
>
>
> On Thu, Aug 20, 2009 at 12:24:16AM +0100, Richard Dobson wrote:
>
> > if it "works" thinking
> > of jack as a soundcard even though it's not, is that OK?
>
> For some value of 'works'. Csound is not a good Jack client,
> and it will never be as long as it tries to abstract this
> by using some intermediate layer.
>
> The reason for this is quite simple.
>
> When using most audio interfaces, an application that has
> any pretences of being real-time and low-latency will
> create a real-time thread that will execute the following
> loop:
>
> while (running)
> {
>     1. wait for some trigger
>     2, get N input frames from device
>     3. process N frames
>     4. write N output frames to device
> }
>
> When using Jack, things are different. Jack will create
> the thread and set its priority, create the loop, and
> determine the block size N. You should provide a function
> that executes steps 2,3,4. That function will be called
> by jack whenever necessary. It must be real-time safe.
>
> If course you can 'transorm' that to the firt model by using
> intermediate buffers. That means you are throwing away all
> the advantages that a system as Jack can offer.
>
> The correct approach is to structure the application on
> the callback model, and build the first model on to of
> it when not using a callback based interface such as Jack.
> Which just means creating the thread and the loop. SC gets
> this right, why not Csound ?
>
> > ... if the user has, as you say, already configured alsa
>
> 'Configuring alsa' does not include deciding which device
> an application should use. That is part of configuring *the
> application*.  There is a configured 'default' alsa device,
> and that's the one an application should use if nothing else
> is specified. But in most cases it wouldn't be the right one
> for Csound.
>
> My system has four alsa devices: the on-board soundcard which
> is also configured to be the 'default' (low-fi, used by Firefox,
> media players, skype, etc.), the modem (not used), an external
> multichannel audio interface (normally used by Jack), and a high
> quality stereo one. When using Csound directly with alsa I would
> expect to be able to select either 1,3, or 4.
>
> BTW I wouldn't mind at all if Csound on Linux uses *only* Jack,
> and just drops alsa and everything else, *provided* the jack
> interface is implemented correctly.
>
> Ciao,
>
> --
> FA
>
> Io lo dico sempre: l'Italia è troppo stretta e lunga.
>
>
> -----------------------------------------------------------------
> -------------
> Let Crystal Reports handle the reporting - Free Crystal Reports
> 2008 30-Day
> trial. Simplify your report design, integration and deployment -
> and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
> -----------------------------------------------------------------
> -------------
> Let Crystal Reports handle the reporting - Free Crystal Reports
> 2008 30-Day
> trial. Simplify your report design, integration and deployment -
> and focus on
> what you do best, core application coding. Discover what's new
> with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

Dr Victor Lazzarini, Senior Lecturer, Dept. of Music,
National University of Ireland, Maynooth

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel

Thanks for your thoughts.

You are correct that any well-written Csound program will not depend
on a particular value of ksmps, so it can simply be set congruent with
Jack. Of course, this assumes that the Csound user will know about
this optimization and do this work.

In fact, if we write a csoundjack program that uses the API as Victor
suggests, then that program can interrogate Jack for the buffer size
and override ksmps to that value or something suitable.

Regards,
Mike




On 8/21/09, Fons Adriaensen  wrote:
> On Thu, Aug 20, 2009 at 07:49:03PM -0400, michael.gogins@gmail.com wrote:
>
>> It's not necessary to use intermediate buffers to get Csound to work as
>> Jack
>> is designed to work.
>>
>> Csound's Jack driver can be modified to work as the CsoundVST::process
>> function already works (VST hosts call back for audio as Jack does). It's
>> identical to your proposed design, except that the Csound output buffer
>> (spout) and the Jack callback buffer may be different sizes. The Jack
>> driver
>> needs two buffer indexes that persist across Jack callbacks, that's all.
>> Every time the Csound spout buffer index gets to the end of the spout
>> buffer, the Jack driver calls csoundPerformKsmps and resets the spout
>> buffer
>> index to 0. Every time the Jack buffer index gets to the end of the Jack
>> buffer, the Jack callback resets the Jack buffer index to 0 and returns.
>> Otherwise, the Jack callback just increments both indexes and copies the
>> respective frames from spout to the Jack buffer in a loop.
>
> It is exactly that which can make Csound into a badly behaved
> Jack app. How bad it gets depends on the ratio of Jack's period
> size (P) and the one which is used by Csound (K, probably K ==
> ksmps).
>
> 1. K == P, no problem and no buffering needed.
>
> 2. K > P. This is one of the bad cases. The ratio could
> be integer or not, it doesn't matter much. As an example
> assume K = 4 * P. Csound's process function will be called
> every fourth Jack callback. Assume the average load by
> Csound is 20%, so if Csound would process P samples on
> each callback it would consume 20% of each period, and
> leave 80% to other audio apps. If Csound runs only every
> forth period it takes 80% of that period, leaving just
> 20% to other clients. That is leaves 100% to others during
> the three skipped periods doesn't help - the other app have
> to complete their work during the current period, so they
> can't take more the 20%.
>
> Of course this works if you consider only Csound and
> disregard all the rest (*). But that is not how a well-
> behaved Jack app is supposed to work.
>
> For possible solutions to this see below.
>
> 3. K < P. In this case all depends on the ratio r = P/K.
> If this is an integer there is no problem, you just call
> Csound's process that number of times in each callback.
> If it is not integer, let n = floor(r). This situation
> will require either n or n+1 calls in each period, and
> a relatively small amount of extra buffering. If n is
> large enough (say n >= 5) the load imbalance is tolerable,
> and this should just work. For small n, we get a situation
> similar to (2) but less extreme.
>
>
> Possible solutions to (2).
>
> The same problem occurs in apps that have to perform
> e.g. large FFT's or any other algorithm that requires
> large block sizes for efficiency.
> One example of these is Jconv (convolution engine using
> mixed partition sizes). It performs a small part of the
> work at Jack's period size P, and the rest using period
> sizes 2^k * P; there can be up to five such levels.
>
> The rules to make this work, and to allow multiple apps
> doing the same to be scheduled fairly, are simple:
>
> A. The processing done for period size 2^k * P is done
>    in a thread that has priority -k w.r.t. to Jack's
>    thread. In other words the priority is decreased by
>    one for each doubling of the period size.
>
> B. The callback does never wait for work done at lower
>    priotiry to be ready. If it isn't ready when the next
>    period of that size is started, then the expected
>    output is replaced by silence, and skipped when it
>    arrives later. If this happens too many times in a
>    row it means the system is overloaded, and in that
>    case the app should quit rather than freeze the
>    machine.
>
> So, to be a well-behaved Jack client Csound should
> either
>
> - Limit the allowed values of ksmps to Jack's period
>   or an integer divider of it, and exclude larger
>   values.
>   As far as I can tell any well-written Csound program
>   should not depend on any exact value of ksmps (it will
>   be a power of 2 anyway), and should still be working
>   correctly if ksmps is decreased.
>
> - Or implement the kind of multi-threaded, multi-priority
>   scheme pointed out above.
>
> - Or change its internal design so it can use a period
>   size that is different from ksmps without generating
>   large irregular CPU loads. Csound will of course always
>   have a load that fluctuates depending on the number of
>   active notes, grains, etc., but that is no excuse to
>   make it even worse.
>
> (*) A tendency do to that is one aspect of seeing Jack
> as just 'a soundcard'.
>
> --
> FA
>
> Io lo dico sempre: l'Italia è troppo stretta e lunga.
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>


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

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

As you surmise the Csound loop is not real-time safe. It reads files,
writes files, allocates memory, and so on.

Note that this is somewhat inherent in the nature of the system.
Csound does all kinds of things that require reading and writing
files, waiting for things, allocating memory dynamically, and so on.

Memory management is something that could be addressed -- perhaps it
already is, I haven't really looked at the code -- by preallocating a
large block of memory and using that as a heap from which memory is
never freed until the end of performance, or by using a third party
heap library that starts with a preallocated block.

The reading and writing stuff is harder, and either we leave it alone
or we set up a whole nest of threads, queues, and whatnot.  There are
tradeoffs here. Academic correctness is not necessarily practical
correctness. I would tend to leave this stuff alone.

Regards,
Mike



On 8/21/09, Fons Adriaensen  wrote:
> On Thu, Aug 20, 2009 at 11:27:44PM -0300, Victor.Lazzarini@nuim.ie wrote:
>
> (your post appear here as one big rectangular blob
> without any formatting. There are no linefeeds, not
> even in the quoted parts).
>
>> I think Fons might be confusing the command 'csound'
>> with the Csound Library. When you say Csound does
>> not get it right, it's mostly to do with how the
>> frontend is written (to use the IO module). Nothing
>> stops anyone writing a small lightweight app that
>> works as Michael describes.
>
> I'm not confusing the lib and the app. I'm just asking
> myself why, if the lib is available and can be called
> as Michael describes, Csound keeps that ugly frontend
> and not just creates a small ad-hoc one for each
> platform.
>
> And yes, maybe this could work, *iff* the process
> function provided by the lib is real-time safe.
> Which means it must not use any system calls that
> can block, never wait for anything, and communicate
> with the non-real time parts in a safe way. Is that
> that case ?
>
>> When Fons says that SC gets it right, you have to
>> rememberthat its Linux version was built to work
>> with Jack and nothing else.
>
> It would be *very* simple to add an Alsa interface.
> AFAICS there's no demand for it, but I could probably
> write it in a hour or two.
>
> It is 'easier' for SC not because it limits itself
> to Jack, but because:
>
> 1. It uses separate audio interface code for each
>    platform. It's just an object file that gets
>    linked in or not. It could be made a plugin as
>    well.
>
> 2. The interface between such an audio interface and
>    the main code is very thin, and it is callback
>    based. It's very easy to build a 'blocking' one
>    on top of that - you just need to add the main
>    loop and the thread that runs it. The opposite
>    is not that easy.
>
> Ciao,
>
> --
> FA
>
> Io lo dico sempre: l'Italia è troppo stretta e lunga.
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>


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

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Michael Gogins wrote:
> Thanks for your thoughts.
> 
> You are correct that any well-written Csound program will not depend
> on a particular value of ksmps, 

except of course ksmps = 1 (which would need to be tested for and 
protected), and a few special cases such as the pvs opcodes, which have 
a limit on ksmsps set by the FFT overlap size (e.g typ. 128). Hopefully 
Jack would never demand a size that large though.

Richard Dobson


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net