16 Feb
2005
16 Feb
'05
6:14 p.m.
I have put online the beginngs of a concept paper for an audio program I
have been wanting to write for quite a while now. I wondered whether you
could give me some feedback on it and share some of your experiences
with me. A while ago I decided to call this *mux* where the name stands
for nothing in particular. I have tested a couple of similiar audio apps
for linux recently, and then toyed around with libraries I found on the
net. I might be reinventing the wheel once more, but that's up for
discussion.. The paper is work in progress, I'm hoping to add to it
tomorrow night.
Looking forward to hear back from you and thanks for any input..
mimo
PS.: the paper is here http://mimo.gn.apc.org/mux/
17 Feb
17 Feb
6:22 a.m.
hi mimo,
are you thinking of something like buzz (or maybe max/msp) where audio
can be routed in a free-form network from sources (generators) to sink
(master output)? i'm a big fan of this idea.
the Preprocessor Level that lazily generates a set
optimised list of instructions for the audio io level
can you go into more detail on this point?
are you planning to use ladspa/dssi plugins as the machines?
i think it's a good idea to make something that can be relied on in a live gig.
7:43 a.m.
Hi James,
James McDermott wrote:
The idea goes like this. Usually what you do in this type of programme
is build some sort of tree representation of the generators and effects.
So you need some sort of algorithm to find the processing order of the
different machines.
Most of the actual running time the processing order doesnt change. Only
if the user adds or removes connections between machines the processing
order has to be recalculated. Changes like the volume level between two
machines or a control input into a machine (like sending a different
note) do not have any impact on the processing order.
A lot of time is spent on finding the processing order. But this only
needs to be done once in a while. The rest of the time it needs to run
just a list of simple instructions, like mix buffer a and b to buffer c,
run a machine on buffer c, etc.
'Lazily' means that the recalculation should be done 'in the
background', while the output still comes from the 'old' processing
order. Only when the new processing order is finished will it activated.
hi mimo,
are you thinking of something like buzz (or maybe max/msp) where audio
can be routed in a free-form network from sources (generators) to sink
(master output)? i'm a big fan of this idea.
You got me! I am a long term buzz user, used it for live gigs, and wrote
a keyboard based mixer for it. I have seen other people using max/msp --
impressive. But there are also some downsides which I want to overcome.
The principal idea and the simplicity of buzz I think are unique.
the Preprocessor Level that lazily generates a set
optimised list of instructions for the audio io level
can you go into more detail on this point?
are you planning to use ladspa/dssi plugins as the machines?
Ladspa is limited. I'd rather use a super class of Ladspa that allows
using Ladspa, etc.
i think it's a good idea to make something that can be relied on in a live gig.
Thanks.
mimo
--
Please note that this account is being filtered using anti UCE systems.
If you send email to this account make sure that it could not be
mistaken as UCE.
8:13 a.m.
On Thu, Feb 17, 2005 at 11:43:44 +0000, mimo wrote:
Such as DSSI? http://dssi.sf.net
- Steve
are you
planning to use ladspa/dssi plugins as the machines?
Ladspa is limited. I'd rather use a super class of Ladspa that allows
using Ladspa, etc.
9:16 a.m.
You got me! I am a long term buzz user, used it for
live gigs, and wrote
a keyboard based mixer for it.
oh - you wrote miXo - of course. (i wrote a peer machine or two.) go buzz devs!
i think everyone who's ever used buzz for more than a couple of hours
wants a new, stable, cross-platform version. (and there are *loads* of
re-implementation projects, including at least one linux one.) i even
have some semi-formed plans myself...
A lot of time is spent on finding the processing
order. But this only
needs to be done once in a while.
i'd be very surprised by that (i haven't looked at any code though).
surely it's a very light task, computationally? i'm thinking that if
the machine network is represented by a tree, just a depth-first
search through the tree gets you the right processing order?
9:31 a.m.
on the subject of beast (and maybe some other programs), i'd agree
that it's cpu-intensive. the great thing about buzz (sorry for going
on about it) is that it's fast: songs using 50+ plugins are possible
on old machines, like my 566 MHz celeron laptop.
9:43 a.m.
James McDermott wrote:
hmm..., maybe you
right. I had something working about 2 years ago --
then called muzz :) -- and that spent most of it's time doing that tree
thingy. But it was probably a bad way of doing it in general.. there is
alos this thing about inputs and outputs or more general connectors and
how to handle the logics behind them..
mimo
--
Please note that this account is being filtered using anti UCE systems.
If you send email to this account make sure that it could not be
mistaken as UCE.
oh - you wrote miXo - of course. (i wrote a peer
machine or two.) go buzz devs!
i think everyone who's ever used buzz for more than a couple of hours
wants a new, stable, cross-platform version. (and there are *loads* of
re-implementation projects, including at least one linux one.) i even
have some semi-formed plans myself...
..want to go into more detail?
A lot of time is spent on finding the processing
order. But this only
needs to be done once in a while.
i'd be very surprised by that (i haven't looked at any code though).
surely it's a very light task, computationally? i'm thinking that if
the machine network is represented by a tree, just a depth-first
search through the tree gets you the right processing order? 
8:40 p.m.
I've touched on the concept. I started out with the same paper and desires,
and ended up with pkaudio.
PKAudio - simple, practical API, powerful, takes care of asynchronous
communication.
http://pkaudio.sf.net/
On Thursday 17 February 2005 03:22 am, James McDermott wrote:
hi mimo,
are you thinking of something like buzz (or maybe max/msp) where audio
can be routed in a free-form network from sources (generators) to sink
(master output)? i'm a big fan of this idea.
the Preprocessor Level that lazily generates a
set optimised list of
instructions for the audio io level
can you go into more detail on this point?
are you planning to use ladspa/dssi plugins as the machines?
i think it's a good idea to make something that can be relied on in a live
gig. 
8:33 a.m.
Hi Mimo,
I have put online the beginngs of a concept paper for
an audio program I
have been wanting to write for quite a while now. I wondered whether you
could give me some feedback on it and share some of your experiences
with me. A while ago I decided to call this *mux* where the name stands
for nothing in particular. I have tested a couple of similiar audio apps
for linux recently, and then toyed around with libraries I found on the
net. I might be reinventing the wheel once more, but that's up for
discussion.. The paper is work in progress, I'm hoping to add to it
tomorrow night.
Looking forward to hear back from you and thanks for any input..
PS.: the paper is here http://mimo.gn.apc.org/mux/
First of all: nice initiative. But...
...why create a new modular audio framework, if you could
improve, harden and extend an existing one? Think of all that hairy GUI
code that you don't have to write and debug...
Another thing: I don't agree with the assessment in your paper that jack
is heavy-weight - and I think jack is much more natural fit to your
application as jackd has xrun detection, already provides means to set a
lower samplerate and increase period size if your system can't put up
with the load. IMHO jack is the way to go if your target platform is
only Linux (or OSX & BSD), otherwise the cross-platform PortAudio may be
more appropriate.
Just my two euro cents ;-)
Cheers,
Walco
9:08 a.m.
Walco wrote:
Hi Mimo,
Well and yes. I agree and principle and looked at existing ones but
seriously didnt like them. beast was mentioned, it's gtk and I cant get
my head around gtk. Also, it's very heavy on the machines I have tried.
The other thing is, you look at existing code, often undocumented one.
So you end up spending more time trying to find out what someone else
was thinking while he did this... and from my experience, often when you
finish a program, it's best to sit down and rewrite it from scratch.
But I'm open for suggestions, so if anyone knows of an active project
that I might contribute to let me know
PS.: the paper is here
http://mimo.gn.apc.org/mux/
First of all: nice initiative. But...
...why create a new modular audio framework, if you could
improve, harden and extend an existing one? Think of all that hairy GUI
code that you don't have to write and debug...
Another thing: I don't agree with the assessment in your paper that jack
is heavy-weight - and I think jack is much more natural fit to your
application as jackd has xrun detection, already provides means to set a
lower samplerate and increase period size if your system can't put up
with the load. IMHO jack is the way to go if your target platform is
only Linux (or OSX & BSD), otherwise the cross-platform PortAudio may be
more appropriate.
I know it was a bit provocative to write that. Also, jack is under
development and I should probably wait for an official release before
complaining. But my experiences with jack are negative. First time I
started looking at it I had huge expectations after all that I had read.
First problems, after a couple of second of running without any
actual processing going on, strange noise artefacts kind of getting
worse. I had a look at source code and realise that it bases its time
calculation on cpu MHz in /proc/cpuinfo. I dont know about your machine,
but on my machine(s) a) this is a float and b) it's slightly different
every time I boot the machine.
The other thing I dont understand about jack is the whole graph
business. E.g. I look at the artsd in kde and plugin an effect and this
is seamless, no stopping of audio. In jack, it says "recalculating
graph" and get a cup of coffee :)
Ok, enough ranting... sorry didnt want to discuss jack really.
Cheers,
Walco
mimo
--
Please note that this account is being filtered using anti UCE systems.
If you send email to this account make sure that it could not be
mistaken as UCE.
9:40 a.m.
I know it was a bit provocative to write that. Also,
jack is under
development and I should probably wait for an official release before
this is not really true. there have been no API changes to the core of
JACK for at least a year.
complaining. But my experiences with jack are negative.
First time I
started looking at it I had huge expectations after all that I had read.
First problems, after a couple of second of running without any
actual processing going on, strange noise artefacts kind of getting
worse. I had a look at source code and realise that it bases its time
calculation on cpu MHz in /proc/cpuinfo. I dont know about your machine,
but on my machine(s) a) this is a float and b) it's slightly different
every time I boot the machine.
this has nothing to do with your noise. JACK uses CPU Hz to provide a
UST value. i am puzzled by the fact you are the 2nd person to think
that JACK's timing is somehow based on system timers and so
forth. JACK (in regular mode, using one of the normal backends) is
driven 100% by the interrupt from your audio interface. whether or not
the CPU Hz value is correct has (effectively) zero impact on audio
generation and timing.
The other thing I dont understand about jack is the
whole graph
business. E.g. I look at the artsd in kde and plugin an effect and this
is seamless, no stopping of audio. In jack, it says "recalculating
graph" and get a cup of coffee :)
good grief. that's a ludicrous comment. it takes fractions of a
millisecond to recompute the graph.
and yes, artsd doesn't break the audio chain because it isn't built
around low latency - stefan has acknowledged that. there is a new
implementation of jack for osx that also doesn't break audio
processing during graph reorders - it uses lock free techniques. but
guess what - it has one process-cycle worth of extra latency as a
result.
so, as they say in the UK: you pays your money and you makes your
choice. you can have absolute minimal latency, but that requires
locking the graph against use when it is reordered.
Ok, enough ranting... sorry didnt want to discuss jack
really.
well, you can't go around making ill-informed comments about someone
else's software and not expect a discussion.
that being said, JACK is *not* appropriate as a replacement for the
engine in something like Buzz. JACK does not scale well much beyond,
well, it depends on your machine, but in general terms, on the order
of 5-10 clients. This isn't a defect - its a reflection of what it
designed to do.
but IMHO, you should be looking at Beast or gAlan or ALSA Modular
Synth, or SSM or ... not starting from scratch.
--p
10 a.m.
Paul Davis wrote:
Just out of interest, if it is dependent on the audio hardware, why do I
get the same problems with different sounds cards on the same machine,
and a colleague gets them with completely different hardware all the
same. Any ideas what might be the reason? Anyone else with the same
experiences?
Sure, point taken.
complaining. But my experiences with jack are
negative. First time I
started looking at it I had huge expectations after all that I had read.
First problems, after a couple of second of running without any
actual processing going on, strange noise artefacts kind of getting
worse. I had a look at source code and realise that it bases its time
calculation on cpu MHz in /proc/cpuinfo. I dont know about your machine,
but on my machine(s) a) this is a float and b) it's slightly different
every time I boot the machine.
this has nothing to do with your noise. JACK uses CPU Hz to provide a
UST value. i am puzzled by the fact you are the 2nd person to think
that JACK's timing is somehow based on system timers and so
forth. JACK (in regular mode, using one of the normal backends) is
driven 100% by the interrupt from your audio interface. whether or not
the CPU Hz value is correct has (effectively) zero impact on audio
generation and timing.
The other thing I dont understand about jack is
the whole graph
business. E.g. I look at the artsd in kde and plugin an effect and this
is seamless, no stopping of audio. In jack, it says "recalculating
graph" and get a cup of coffee :)
good grief. that's a ludicrous comment. it takes fractions of a
millisecond to recompute the graph.
and yes, artsd doesn't break the audio chain because it isn't built
around low latency - stefan has acknowledged that. there is a new
implementation of jack for osx that also doesn't break audio
processing during graph reorders - it uses lock free techniques. but
guess what - it has one process-cycle worth of extra latency as a
result.
so, as they say in the UK: you pays your money and you makes your
choice. you can have absolute minimal latency, but that requires
locking the graph against use when it is reordered.
Ok, enough ranting... sorry didnt want to discuss
jack really.
well, you can't go around making ill-informed comments about someone
else's software and not expect a discussion.
that being said, JACK is *not* appropriate as a replacement for the
engine in something like Buzz. JACK does not scale well much beyond,
well, it depends on your machine, but in general terms, on the order
of 5-10 clients. This isn't a defect - its a reflection of what it
designed to do.
Good to know, so I misread the jack spec in the first place because I
was expecting it to do what I wanted to do -- the many machines processor.
but IMHO, you should be looking at Beast or gAlan or ALSA Modular
Synth, or SSM or ... not starting from scratch.
One thing, I dont want to start completely from scratch. At least I'm
going to nick some lines of code from someone elses project :)
mimo
--
Please note that this account is being filtered using anti UCE systems.
If you send email to this account make sure that it could not be
mistaken as UCE.
10:29 a.m.
On Thu, Feb 17, 2005 at 02:00:24 +0000, mimo wrote:
Paul Davis wrote:
Just out of interest, if it is dependent on the audio hardware, why do I
get the same problems with different sounds cards on the same machine,
and a colleague gets them with completely different hardware all the
same. Any ideas what might be the reason? Anyone else with the same
experiences?
Are you running it in realtime mode? If not, and jackd misses realtime
deadlines you will often get noises in the output.
- Steve
complaining. But my experiences with jack are
negative. First time I
started looking at it I had huge expectations after all that I had read.
First problems, after a couple of second of running without any
actual processing going on, strange noise artefacts kind of getting
worse. I had a look at source code and realise that it bases its time
calculation on cpu MHz in /proc/cpuinfo. I dont know about your machine,
but on my machine(s) a) this is a float and b) it's slightly different
every time I boot the machine.
this has nothing to do with your noise. JACK uses CPU Hz to provide a
UST value. i am puzzled by the fact you are the 2nd person to think
that JACK's timing is somehow based on system timers and so
forth. JACK (in regular mode, using one of the normal backends) is
driven 100% by the interrupt from your audio interface. whether or not
the CPU Hz value is correct has (effectively) zero impact on audio
generation and timing.
10:45 a.m.
Steve Harris wrote:
On Thu, Feb 17, 2005 at 02:00:24 +0000, mimo wrote:
Yes, and root, tried evryting I could think of. And again, this happens
without any load.
mimo
Paul Davis wrote:
Just out of interest, if it is dependent on the audio hardware, why do I
get the same problems with different sounds cards on the same machine,
and a colleague gets them with completely different hardware all the
same. Any ideas what might be the reason? Anyone else with the same
experiences?
Are you running it in realtime mode? If not, and jackd misses realtime
deadlines you will often get noises in the output.
complaining. But my experiences with jack are negative. First time I
started looking at it I had huge expectations after all that I had read.
First problems, after a couple of second of running without any
actual processing going on, strange noise artefacts kind of getting
worse. I had a look at source code and realise that it bases its time
calculation on cpu MHz in /proc/cpuinfo. I dont know about your machine,
but on my machine(s) a) this is a float and b) it's slightly different
every time I boot the machine.
this has nothing to do with your noise. JACK uses CPU Hz to provide a
UST value. i am puzzled by the fact you are the 2nd person to think
that JACK's timing is somehow based on system timers and so
forth. JACK (in regular mode, using one of the normal backends) is
driven 100% by the interrupt from your audio interface. whether or not
the CPU Hz value is correct has (effectively) zero impact on audio
generation and timing.
- Steve
--
Please note that this account is being filtered using anti UCE systems.
If you send email to this account make sure that it could not be
mistaken as UCE.
12:31 p.m.
On Thu, Feb 17, 2005 at 02:45:22 +0000, mimo wrote:
Is the card a soundblaster live derivative? I beive there was a problem
with these at some point.
- Steve
Are you running
it in realtime mode? If not, and jackd misses realtime
deadlines you will often get noises in the output.
Yes, and root, tried evryting I could think of. And again, this happens
without any load.
10:39 a.m.
Just out of interest, if it is dependent on the audio
hardware, why do I
get the same problems with different sounds cards on the same machine,
and a colleague gets them with completely different hardware all the
same. Any ideas what might be the reason? Anyone else with the same
experiences?
I don't know. I don't recall anyone ever having reported this kind of
noise, certainly not within the last year or two of JACK's
history. You are talking about a system that is just running jackd, no
clients, correct? What audio h/w are we talking about?
Good to know, so I misread the jack spec in the first
place because I
was expecting it to do what I wanted to do -- the many machines processor.
it *is* intended to connect multiple audio applications together, but
the design goals weren't based on each of those applications being on
the scale of a buzz machine, or a LADSPA/DSSI plugin. the idea was
that applications would host the ".dll level plugins", and JACK would
"host" the applications. and it does so rather well, from what we
hear.
--p
12:10 p.m.
On Thu, 2005-02-17 at 09:39 -0500, Paul Davis wrote:
The only time I have heard of this happening is when people do something
stupid like trying to run JACK with an emu10k1 at 44100KHz.
Lee
Just out of
interest, if it is dependent on the audio hardware, why do I
get the same problems with different sounds cards on the same machine,
and a colleague gets them with completely different hardware all the
same. Any ideas what might be the reason? Anyone else with the same
experiences?
I don't know. I don't recall anyone ever having reported this kind of
noise, certainly not within the last year or two of JACK's
history. You are talking about a system that is just running jackd, no
clients, correct? What audio h/w are we talking about?
12:44 p.m.
Lee Revell wrote:
On Thu, 2005-02-17 at 09:39 -0500, Paul Davis wrote:
The only time I have heard of this happening is when people do something
stupid like trying to run JACK with an emu10k1 at 44100KHz.
No, happened with rme96 at 44.1kHz -- will try to reproduce tonight and
send you details.
mimo
Just out
of interest, if it is dependent on the audio hardware, why do I
get the same problems with different sounds cards on the same machine,
and a colleague gets them with completely different hardware all the
same. Any ideas what might be the reason? Anyone else with the same
experiences?
I don't know. I don't recall anyone ever having reported this kind of
noise, certainly not within the last year or two of JACK's
history. You are talking about a system that is just running jackd, no
clients, correct? What audio h/w are we talking about?
Lee
--
Please note that this account is being filtered using anti UCE systems.
If you send email to this account make sure that it could not be
mistaken as UCE.
10:26 a.m.
On Thu, Feb 17, 2005 at 08:40:01AM -0500, Paul Davis wrote:
you can have absolute minimal latency, but that
requires
locking the graph against use when it is reordered.
AFAICS, that is not the real reason. If it were, the simple
solution would be to let the engine continue using a copy
of the current graph while the new one is being computed and
the required resources created.
Probably if look you into it deep enough you'll find that the
necessity to stop processing while new clients are created
or when the port connection change can be traced back to the
combined effect of:
1. only having one JACK-controlled thread in each client,
2. the synchronous nature of the API calls that modify
the graph.
--
FA
10:43 a.m.
you can have
absolute minimal latency, but that requires
locking the graph against use when it is reordered.
AFAICS, that is not the real reason. If it were, the simple
solution would be to let the engine continue using a copy
of the current graph while the new one is being computed and
the required resources created.
Probably if look you into it deep enough you'll find that the
necessity to stop processing while new clients are created
or when the port connection change can be traced back to the
combined effect of:
1. only having one JACK-controlled thread in each client,
2. the synchronous nature of the API calls that modify
the graph. 
11:04 a.m.
Le 17 févr. 05, à 15:43, Paul Davis a écrit :
stephane's new OSX implementation (jackdmp) avoids both of these, and
ends up with an extra process-cycle worth of latency. he does exactly
what you suggest above. is it avoidable? i don't know. stephane didn't
seem to think so when we talked about it briefly on IRC. maybe it can
be.
--p
Just one word about the "one extra process-cycle worth of latency":
this is not exactly related to the fact that the graph is updated
without stopping the audio thread : one could perfectly keep the
current model (where the server waits for the client graph execution
end to write the output buffer ) *and* have the "don't stop audio
thread" property most of the time.
The "one extra process-cycle worth of latency" is a consequence of
another idea to implement a more "robust" system, where robust mean a
system where *some* audio clients may fail during one cycle without
stopping the entire graph.
Stephane
you can have absolute minimal latency, but that
requires
locking the graph against use when it is reordered.
AFAICS, that is not the real reason. If it were, the simple
solution would be to let the engine continue using a copy
of the current graph while the new one is being computed and
the required resources created.
Probably if look you into it deep enough you'll find that the
necessity to stop processing while new clients are created
or when the port connection change can be traced back to the
combined effect of:
1. only having one JACK-controlled thread in each client,
2. the synchronous nature of the API calls that modify
the graph.
11:16 a.m.
On Thu, Feb 17, 2005 at 09:43:16AM -0500, Paul Davis wrote:
stephane's new OSX implementation (jackdmp) avoids
both of these, and
ends up with an extra process-cycle worth of latency. he does exactly
what you suggest above. is it avoidable? i don't know. stephane didn't
seem to think so when we talked about it briefly on IRC. maybe it can
be.
Strange. The only way you could have an extra cycle of latency is by
explicitly programming for it, either inserting a buffer somewhere,
or by changing the sequence
backend wakeup -> read inputs - call graph - write outputs
to
backend wakeup -> write outputs - read inputs - call graph
which amounts to the same thing. How would this help in allowing
processing to continue during graph changes ?
I'm convinced it should be possible. The price to pay should not
not be increased audio latency, but an asynchronous interface
to the client creation / port creation and connection functions.
In other words, you will have to request something and the result
will be known not when your call returns, but by some asynchronous
event. This makes sense anyway for things that can be modified from
any number of places at the same time.
--
FA
11:41 a.m.
Le 17 févr. 05, à 16:16, Alfons Adriaensen a écrit :
On Thu, Feb 17, 2005 at 09:43:16AM -0500, Paul Davis
wrote:
Yes, this is currently done like that in jackdmp
stephane's new OSX implementation (jackdmp)
avoids both of these, and
ends up with an extra process-cycle worth of latency. he does exactly
what you suggest above. is it avoidable? i don't know. stephane didn't
seem to think so when we talked about it briefly on IRC. maybe it can
be.
Strange. The only way you could have an extra cycle of latency is by
explicitly programming for it, either inserting a buffer somewhere,
or by changing the sequence
backend wakeup -> read inputs - call graph - write outputs
to
backend wakeup -> write outputs - read inputs - call graph
which amounts to the same thing. How would this help in allowing
processing to continue during graph changes ?
I'm convinced it should be possible. The price to pay should not
not be increased audio latency,
I think it depends of what is important: a "more" robust system with
one extra buffer latency or the current model.
I will make both options available in jackdmp.
but an asynchronous interface
to the client creation / port creation and connection functions.
In other words, you will have to request something and the result
will be known not when your call returns, but by some asynchronous
event. This makes sense anyway for things that can be modified from
any number of places at the same time.
Hum.... I'm not sure asynchronous interface is needed. In my
implementation graph state changes are "seen" by the audio thread the
next cycle, but since all calls that change the graph state are
serialized by the server, clients always see a coherent state.
Stephane
10:54 a.m.
Le 17 févr. 05, à 15:26, Alfons Adriaensen a écrit :
On Thu, Feb 17, 2005 at 08:40:01AM -0500, Paul Davis
wrote:
These kind of problems are addressed in "jackdmp", (jackd for
multi-processors) where new clients, ports and connections can be
done/changed without stopping the audio stream.
Look at http://www.grame.fr/~letz/jackdmp.zip for the OSX version
which contains a technical paper explaining the new implementation.
Stephane Letz
you can have absolute minimal latency, but that
requires
locking the graph against use when it is reordered.
AFAICS, that is not the real reason. If it were, the simple
solution would be to let the engine continue using a copy
of the current graph while the new one is being computed and
the required resources created.
Probably if look you into it deep enough you'll find that the
necessity to stop processing while new clients are created
or when the port connection change can be traced back to the
combined effect of:
1. only having one JACK-controlled thread in each client,
2. the synchronous nature of the API calls that modify
the graph.
--
FA
12:20 p.m.
On Thu, 2005-02-17 at 08:40 -0500, Paul Davis wrote:
Besides, I wrote a patch to eliminate the /proc/cpuinfo hack, it's low
prio but should be in JACK eventually. But like Paul says this has
absolutely nothing to do with the sound.
Lee
complaining.
But my experiences with jack are negative. First time I
started looking at it I had huge expectations after all that I had read.
First problems, after a couple of second of running without any
actual processing going on, strange noise artefacts kind of getting
worse. I had a look at source code and realise that it bases its time
calculation on cpu MHz in /proc/cpuinfo. I dont know about your machine,
but on my machine(s) a) this is a float and b) it's slightly different
every time I boot the machine.
this has nothing to do with your noise. JACK uses CPU Hz to provide a
UST value. i am puzzled by the fact you are the 2nd person to think
that JACK's timing is somehow based on system timers and so
forth. JACK (in regular mode, using one of the normal backends) is
driven 100% by the interrupt from your audio interface. whether or not
the CPU Hz value is correct has (effectively) zero impact on audio
generation and timing.
12:33 p.m.
On Thu, Feb 17, 2005 at 11:20:06 -0500, Lee Revell wrote:
Actually it can be on laptops with CPU scaling. JACK gets sufficiently
confused on mine that it tells ALSA to restart the card constantly,
causing all kinds of noise.
I have to lock the CPU to the maximum frequency to stop it happening.
- Steve
this has
nothing to do with your noise. JACK uses CPU Hz to provide a
UST value. i am puzzled by the fact you are the 2nd person to think
that JACK's timing is somehow based on system timers and so
forth. JACK (in regular mode, using one of the normal backends) is
driven 100% by the interrupt from your audio interface. whether or not
the CPU Hz value is correct has (effectively) zero impact on audio
generation and timing.
Besides, I wrote a patch to eliminate the /proc/cpuinfo hack, it's low
prio but should be in JACK eventually. But like Paul says this has
absolutely nothing to do with the sound.
1:11 p.m.
On Thu, 2005-02-17 at 16:33 +0000, Steve Harris wrote:
That thread kind of petered out on jackit-devel without a resolution. I
have some more information on the problem.
As many of you know the issue is that some CPU's frequency scaling
implementations causes the TSC (which JACK and many other apps use
because it's by far the cheapest high res timer on x86) to change speed,
confusing JACK severely. According to the "experts" on LKML
(specifically George Anzinger from MontaVista) these systems are BROKEN
- IOW this behavior violates some spec. Newer machines (P4 and later)
are guaranteed not to have the problem.
The normal means for dealing with broken hardware, when you don't want
to make everyone take a performance hit due to a few buggy systems, is
to use a blacklist.
Anyway this is an issue for jackit-devel. The short answer is to
disable frequency scaling when you're doing audio work. Which is common
sense anyway.
Lee
Besides, I
wrote a patch to eliminate the /proc/cpuinfo hack, it's low
prio but should be in JACK eventually. But like Paul says this has
absolutely nothing to do with the sound.
Actually it can be on laptops with CPU scaling. JACK gets sufficiently
confused on mine that it tells ALSA to restart the card constantly,
causing all kinds of noise.
I have to lock the CPU to the maximum frequency to stop it happening. 
18 Feb
18 Feb
3:35 p.m.
Hallo,
Paul Davis hat gesagt: // Paul Davis wrote:
but IMHO, you should be looking at Beast or gAlan or
ALSA Modular
Synth, or SSM or ... not starting from scratch.
And Pd, which is the oldest and probably most capable and stable of
all the available graphical softsynths running on Linux. It also has a
dsp graph inside, which is quite clever, but indeed it can lead to
dropouts if you create a lot of objects at the same time, as the dsp
graph needs to reorder itself. However live patching is possible in Pd
and it is done by a lot of users.
Regarding the live capabilities of Pd, let me tell you a recent story:
Last weekend we did an improvisation gig in my town, where ten laptop
artists, most of them running Pd on Linux (seven, and one running
Max/MSP on OS-X, two running Supercollider on OS-X) were playing
together for a really long time (about an hour, but some participiants
just couldn't stop... ;)
All machines were synchronized through OSC messages coming from my
machine sent to broadcast addresses, one main machine with Pd on Linux
was receiving all the other machines' audio data through its RME card
and then doing spatialization with them in Pd which fed 16 speakers
with sounds running over 8 independent paths (which were in turn
controllable by everyone involved through OSC again). This was quite
an impressive setup, and Pd did not fail on a single box through the
whole performance.
Oh, and some people were also doing video art with their Pd/Linux
boxes.
Can Buzz do all this?
Ciao
--
Frank Barknecht _ ______footils.org__
_ __latest track: fqdn _ http://footils.org/cms/show/38
19 Feb
19 Feb
12:49 p.m.
but IMHO, you
should be looking at Beast or gAlan or ALSA Modular
Synth, or SSM or ... not starting from scratch.
And Pd, which is the oldest and probably most capable and stable of
all the available graphical softsynths running on Linux. 
17 Feb
17 Feb
10:25 p.m.
On Thu, 2005-17-02 at 13:07 +0000, mimo wrote:
Walco wrote:
I'm working on a (currently) LADSPA-using modular synth called Om that's
a seperate engine controlled by OSC (like supercollider).
It already does all the process-order-in-the-background stuff you
mentioned (ie there is a distinction between realtime and non-realtime
events and they don't interfere with each other) and allows you to do
everything in realtime. Two clients can even use it at once over the
network and see the changes to the patch mirror on each other's screens.
It's polyphonic, has subpatching, multiple "toplevel" patches (ie
completely dynamic jack port creation), MIDI binding, blah blah etc.
etc.
I don't know if what you're planning on doing is a modular synth or
something different/more, but if it's a modular synth you want to make..
help me, I'm many months ahead of you. :)
The UI is gtk, but there's nothing stopping you from writing your own,
the OSC commands are quite simple.
I'm more than open to ideas that take things beyond "just a modular
synth" (already experimenting with OSC-driven algorithmic stuff) and the
engine is quite simple to extend in any resonable way. Feel free to
drop me a line.
-DR-
Hi Mimo,
Well and yes. I agree and principle and looked at existing ones but
seriously didnt like them. beast was mentioned, it's gtk and I cant get
my head around gtk. Also, it's very heavy on the machines I have tried.
The other thing is, you look at existing code, often undocumented one.
So you end up spending more time trying to find out what someone else
was thinking while he did this... and from my experience, often when you
finish a program, it's best to sit down and rewrite it from scratch.
But I'm open for suggestions, so if anyone knows of an active project
that I might contribute to let me know PS.: the paper is here
http://mimo.gn.apc.org/mux/
First of all: nice initiative. But...
...why create a new modular audio framework, if you could
improve, harden and extend an existing one? Think of all that hairy GUI
code that you don't have to write and debug... 
9:24 a.m.
Walco wrote:
Hi Mimo,
I'll chime in here. I've been testing Csound5 quite a lot lately, it
supports PortAudio (as well as ALSA and JACK) and PortMIDI. Frankly, I'm
not impressed with default realtime performance under PortAudio. I can
improve performance with some judicious buffer tweaks, but the native
ALSA driver is much better.
I also agree with Walco re: JACK weight.
Nevertheless, it's Linux, innit ? So you can do what you like... :)
Btw, mimo: Have you tried using Buzz under Linux ? I've had it working
quite nicely, it's a very impressive program, lots of fun. A native Buzz
would be most welcome.
Best,
dp
I have put online the beginngs of a concept paper
for an audio
program I have been wanting to write for quite a while now. I
wondered whether you could give me some feedback on it and share some
of your experiences with me. A while ago I decided to call this *mux*
where the name stands for nothing in particular. I have tested a
couple of similiar audio apps for linux recently, and then toyed
around with libraries I found on the net. I might be reinventing the
wheel once more, but that's up for discussion.. The paper is work in
progress, I'm hoping to add to it tomorrow night.
Looking forward to hear back from you and thanks for any input..
PS.: the paper is here http://mimo.gn.apc.org/mux/
[snip]
Another thing: I don't agree with the assessment in your paper that jack
is heavy-weight - and I think jack is much more natural fit to your
application as jackd has xrun detection, already provides means to set a
lower samplerate and increase period size if your system can't put up
with the load. IMHO jack is the way to go if your target platform is
only Linux (or OSX & BSD), otherwise the cross-platform PortAudio may be
more appropriate.
9:46 a.m.
Dave Phillips wrote:
--
Please note that this account is being filtered using anti UCE systems.
If you send email to this account make sure that it could not be
mistaken as UCE.
Btw, mimo: Have you tried using Buzz under Linux ?
I've had it working
quite nicely, it's a very impressive program, lots of fun. A native Buzz
would be most welcome.
I guess you mean under wine. I have but wasnt impressed with performance
(maybe I really should get a better machine after all.. hmm.. but buzz
used to run fine on a 230Mhz machine.. no it must be feasible ;) )
Yes, native buzz this should be with some minor improvements.
Best,
dp
mimo
4:51 p.m.
On Thu, 2005-02-17 at 05:40, Dave Phillips wrote:
Walco wrote:
Just curious, what backend were you using with PortAudio? Alsa?
-- Fernando
Hi Mimo,
I'll chime in here. I've been testing Csound5 quite a lot lately, it
supports PortAudio (as well as ALSA and JACK) and PortMIDI. Frankly, I'm
not impressed with default realtime performance under PortAudio. I can
improve performance with some judicious buffer tweaks, but the native
ALSA driver is much better. I have put online the beginngs of a concept paper
for an audio
program I have been wanting to write for quite a while now. I
wondered whether you could give me some feedback on it and share some
of your experiences with me. A while ago I decided to call this *mux*
where the name stands for nothing in particular. I have tested a
couple of similiar audio apps for linux recently, and then toyed
around with libraries I found on the net. I might be reinventing the
wheel once more, but that's up for discussion.. The paper is work in
progress, I'm hoping to add to it tomorrow night.
Looking forward to hear back from you and thanks for any input..
PS.: the paper is here http://mimo.gn.apc.org/mux/
[snip]
Another thing: I don't agree with the assessment in your paper that jack
is heavy-weight - and I think jack is much more natural fit to your
application as jackd has xrun detection, already provides means to set a
lower samplerate and increase period size if your system can't put up
with the load. IMHO jack is the way to go if your target platform is
only Linux (or OSX & BSD), otherwise the cross-platform PortAudio may be
more appropriate.
5:01 p.m.
Hi Fernando:
I built PortAudio (v19 I believe) with ALSA and JACK support but I
haven't used it with JACK at all. When building Cs5 Scons will assume
your PortAudio has been built with JACK, you need to specify if it isn't.
Best,
dp
On Thu, 2005-02-17 at 05:40, Dave Phillips wrote:
Walco wrote:
Just curious, what backend were you using with PortAudio? Alsa?
-- Fernando
Hi Mimo,
I'll chime in here. I've been testing Csound5 quite a lot lately, it
supports PortAudio (as well as ALSA and JACK) and PortMIDI. Frankly, I'm
not impressed with default realtime performance under PortAudio. I can
improve performance with some judicious buffer tweaks, but the native
ALSA driver is much better.
I have put online the beginngs of a concept paper
for an audio
program I have been wanting to write for quite a while now. I
wondered whether you could give me some feedback on it and share some
of your experiences with me. A while ago I decided to call this *mux*
where the name stands for nothing in particular. I have tested a
couple of similiar audio apps for linux recently, and then toyed
around with libraries I found on the net. I might be reinventing the
wheel once more, but that's up for discussion.. The paper is work in
progress, I'm hoping to add to it tomorrow night.
Looking forward to hear back from you and thanks for any input..
PS.: the paper is here http://mimo.gn.apc.org/mux/
[snip]
Another thing: I don't agree with the assessment in your paper that jack
is heavy-weight - and I think jack is much more natural fit to your
application as jackd has xrun detection, already provides means to set a
lower samplerate and increase period size if your system can't put up
with the load. IMHO jack is the way to go if your target platform is
only Linux (or OSX & BSD), otherwise the cross-platform PortAudio may be
more appropriate.
7010
days inactive
7013
days old
linux-audio-dev@lists.linuxaudio.org
35 comments
13 participants
participants (13)
-
Alfons Adriaensen -
Dave Phillips -
Dave Robillard -
Fernando Lopez-Lezcano -
Frank Barknecht -
James McDermott -
Lee Revell -
mimo -
Patrick Stinson -
Paul Davis -
Steve Harris -
Stéphane Letz -
Walco