Re: [LAD] hard realtime performance synth

[Jens M Andreasen]

On Tue, 2010-01-26 at 15:15 -0500, David McClanahan wrote:

> ... Roland, Korg, Yamaha put out turnkey products on what I suspect is
> simpler hardware and my question is there any reason why similar
> turnkey systems could not be developed on a Linux system ...
> 

There is a difference between 'any Linux system' and 'a Linux System
built for audio'

A Roland/Yamaha styled HW synth will at least have one dedicated DSP -
or even custom built logic - directly connected to its ADC/DAC to do the
single innermost loop that is the RT-application.  Everything else is
for display, blinken-lights and monitoring state of knobs and buttons.

A $150 Beagle Board has the nescessary HW and connectivity to work like
that. Your Dell laptop does not.


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] random curiosity

[Jörn Nettingsmeier]

On 01/25/2010 11:59 PM, Gabriel M. Beddingfield wrote:

>  From 'man 3 random_placebo':
>
>   If rand(), random(), and random_r() aren't random
>   enough for you, random_placebo() is generates
>   more randomer numbers by algorthmically generating
>   more entropies on your system.  The return is
>   guaranteed be the most random number you could
>   imagine.

42?
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] random curiosity

[cal]

Jens M Andreasen wrote:
> [ ... ]
> I am surprised that nobody so far has suggested using the key and
> velocity as a "salt" to differentiate a single stream of randomness?

If you don't mind, how would one go about "salting" it?

cheers.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] MusE 1.0.1

[alex stone]

On Wed, Jan 27, 2010 at 2:22 AM, Tim E. Real  wrote:
> On January 26, 2010 08:33:48 am Robert Jonsson wrote:
>> Hi Alex,
>>
>> 2010/1/26 alex stone :
>> > Robert, as a note of interest here, is there a reason why Muse only
>> > has 32 midi ports available? Is it possible to increase this at user
>> > level? (I have 65 and counting)
>>
>> 65!  Thats, thats... alot :)
>>
>> Actually the default was recently upped from 16 to 32, thinking that
>> we should cover most uses, apparently we were wrong :-)
>> It's a define so it is possible to change but a recompile is needed,
>> though I recall there were some issues last time...
>> I have forwarded to the devel list if Tim wants to chime in.
> This might be a problem. It's not just the define that sets the number
>  of ports. The ports are used in certain places via an unsigned 32-bit int.
> Each bit corresponds to one port (used, not used etc.)
> So we were lucky to be able to increase from 16 to 32, but
>  beyond that I will have to look at redesigning parts of the ports system.
> Maybe not as tough as it sounds, but not as easy as changing a define...
> I will have a look.
> Tim.
> ___
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-dev
>

Tim, i wonder, given you might need to rummage around in the code a
bit, if this the time to consider implementing jackmidi in trunk, and
do this once, instead of twice.
I'm no coder, but maybe there's an opportunity in this to take another
big step forward, and not have to go through the same process twice,
given the work already done in the separate branch to provide a
jackmidi framework.

imho.

Alex.

-- 
www.openoctave.org

midi-subscr...@openoctave.org
development-subscr...@openoctave.org
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] random curiosity

[Jörn Nettingsmeier]

On 01/27/2010 12:31 PM, cal wrote:
> Jens M Andreasen wrote:
>> [ ... ]
>> I am surprised that nobody so far has suggested using the key and
>> velocity as a "salt" to differentiate a single stream of randomness?
>
> If you don't mind, how would one go about "salting" it?

http://en.wikipedia.org/wiki/Salting_%28cryptography%29
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] random curiosity

[Gabriel M. Beddingfield]

On Wed, 27 Jan 2010, cal wrote:

> Jens M Andreasen wrote:
>> [ ... ]
>> I am surprised that nobody so far has suggested using the key and
>> velocity as a "salt" to differentiate a single stream of randomness?
>
> If you don't mind, how would one go about "salting" it?

One way that comes to mind:

 unsigned short int note, velocity;
 // ...

 unsigned int salt = ((velocity & 0x7F)<<7) | (note & 0x7F);
 struct random_data seed;

 srandom_r(salt, &seed);

Thus, if you repeat the note with identical velocity... 
you'll always get the same random-number sequence.

-gabriel
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] random curiosity

[cal]

Jörn Nettingsmeier wrote:
> On 01/27/2010 12:31 PM, cal wrote:
>> Jens M Andreasen wrote:
>>> [ ... ]
>>> I am surprised that nobody so far has suggested using the key and
>>> velocity as a "salt" to differentiate a single stream of randomness?
>> If you don't mind, how would one go about "salting" it?
> 
> http://en.wikipedia.org/wiki/Salting_%28cryptography%29

Cool, thanks!
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] random curiosity

[cal]

Gabriel M. Beddingfield wrote:
> [ ... ]
> srandom_r(salt, &seed);
> 
> Thus, if you repeat the note with identical velocity... you'll always 
> get the same random-number sequence.

or do you just get a segfault :-) ?
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] random curiosity

[Gabriel M. Beddingfield]

On Thu, 28 Jan 2010, cal wrote:


Gabriel M. Beddingfield wrote:

[ ... ]
srandom_r(salt, &seed);

Thus, if you repeat the note with identical velocity... you'll always
get the same random-number sequence.


or do you just get a segfault :-) ?


Wow.  random_r() is /really/ poorly documented. 
Non-segfaulting example attached.


-gabriel
#include 
#include 

using namespace std;

int main(void)
{
unsigned short int note, velocity;
int32_t salt;
struct random_data seed;
char rand_state[256];

note = 63;
velocity = 120;

salt = ((velocity & 0x7F) << 7) | (note & 0x7F);

// See http://lists.debian.org/debian-glibc/2006/01/msg00037.html
seed.state = (int32_t*)rand_state;
initstate_r(salt, rand_state, sizeof(rand_state), &seed);

int32_t res;
for(int k=0 ; k<20 ; ++k) {
	random_r(&seed, &res);
	cout << res << endl;
}

return 0;
}
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] random curiosity

[Folderol]

On Wed, 27 Jan 2010 06:54:00 -0600 (CST)
"Gabriel M. Beddingfield"  wrote:

> 
> 
> On Wed, 27 Jan 2010, cal wrote:
> 
> > Jens M Andreasen wrote:
> >> [ ... ]
> >> I am surprised that nobody so far has suggested using the key and
> >> velocity as a "salt" to differentiate a single stream of randomness?
> >
> > If you don't mind, how would one go about "salting" it?
> 
> One way that comes to mind:
> 
>  unsigned short int note, velocity;
>  // ...
> 
>  unsigned int salt = ((velocity & 0x7F)<<7) | (note & 0x7F);
>  struct random_data seed;
> 
>  srandom_r(salt, &seed);
> 
> Thus, if you repeat the note with identical velocity... 
> you'll always get the same random-number sequence.
> 
> -gabriel


Hmmm,
Getting identical note and velocity is going to be quite common on
sequencer generated stuff, so I would have thought this was rather
undesirable. While there have been odd occasions when I've wished I
could reliably re-create a pseudo random sequence, in general I would
not want repeated identically created notes to sound exactly the same.

-- 
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] random curiosity

[Gabriel M. Beddingfield]

On Wed, 27 Jan 2010, Folderol wrote:

> Hmmm,
> Getting identical note and velocity is going to be quite common on
> sequencer generated stuff, so I would have thought this was rather
> undesirable. While there have been odd occasions when I've wished I
> could reliably re-create a pseudo random sequence, in general I would
> not want repeated identically created notes to sound exactly the same.

Agreed... but apparently cal /does/ want that. :-)

Related example:  THX's "Deep Note" was composed using a 
PRNG.  Every performance was different.  The "favorite" 
performance is the one you hear in theaters (with the 
descending overtones at the end).  At one point, the 
recording was lost -- and there was no way to recreate 
it.[1] If they had saved the seeds to the PRNG's, they could 
have recreated the performance (even with rand()).

-gabriel

[1] http://en.wikipedia.org/wiki/Deep_Note
 Sorry, can't find a reference ATM for the story about
 losing the master recording.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] random curiosity

[cal]

Gabriel M. Beddingfield wrote:
> 
> 
> On Thu, 28 Jan 2010, cal wrote:
> 
>> Gabriel M. Beddingfield wrote:
>>> [ ... ]
>>> srandom_r(salt, &seed);
>>>
>>> Thus, if you repeat the note with identical velocity... you'll always
>>> get the same random-number sequence.
>>
>> or do you just get a segfault :-) ?
> 
> Wow.  random_r() is /really/ poorly documented. Non-segfaulting example 
> attached.

Yeah, I too wandered innocently into the parallel universe alluded to here
(and no doubt elsewhere) .
I thought wow, that was 2006! Surely it's been sorted by now. Apparently not.

Cheers.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] random curiosity

[cal]

Gabriel M. Beddingfield wrote:
> 
> On Wed, 27 Jan 2010, Folderol wrote:
> 
>> Hmmm,
>> Getting identical note and velocity is going to be quite common on
>> sequencer generated stuff, so I would have thought this was rather
>> undesirable. While there have been odd occasions when I've wished I
>> could reliably re-create a pseudo random sequence, in general I would
>> not want repeated identically created notes to sound exactly the same.
> 
> Agreed... but apparently cal /does/ want that. :-)

Not quite. Over the last 12 months I've learned that I don't know enough
about how zyn does its maths magic to try to change how it does it too
radically. All I wanted was the same behavior as original zyn, but
simpler code. One day I might get more adventurous, but I'm not there yet.

Cheers.

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] tschack ... early version of smp enabled jack1

[torbenh]

On Tue, Jan 26, 2010 at 12:38:53PM +, Chris Cannam wrote:
> On Sun, Jan 24, 2010 at 9:05 PM, torbenh  wrote:
> > since i dont want to let jack1 codebase die in a feature freeze,
> > i added some features.
> >
> > - smp aware
> > - clickless connections
> 
> Is there any reason why a user would prefer this over jack2?

i am not sure, but there a several users which report xruns with jack2,
where jack1 still works.
though i am not sure if they tested jack 1.9.4 which seem ok in sync mode
at least. 

tschack still has most properties of jack1

> 
> 
> Chris

-- 
torben Hohn
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] tschack ... early version of smp enabled jack1

[torbenh]

On Tue, Jan 26, 2010 at 07:38:38AM -0800, James Warden wrote:
> 
> 
> --- On Tue, 1/26/10, Chris Cannam  wrote:
> 
> > From: Chris Cannam 
> > Subject: Re: [LAD] tschack ... early version of smp enabled jack1
> > To: "torbenh" 
> > Cc: linux-audio-dev@lists.linuxaudio.org
> > Date: Tuesday, January 26, 2010, 7:38 AM
> > On Sun, Jan 24, 2010 at 9:05 PM,
> > torbenh 
> > wrote:
> > > since i dont want to let jack1 codebase die in a
> > feature freeze,
> > > i added some features.
> > >
> > > - smp aware
> > > - clickless connections
> > 
> > Is there any reason why a user would prefer this over
> > jack2?
> > 
> 
> and would I assume correctly that one of the reasons to not let the jack1 
> codebase "die" (or freeze)  is that it is written in C as opposed to jack2 ?

no. i actually prefer C++
but not that much that i would deal with CamelCase and a class hierarchy
i find confusing. but thats just my taste. 


-- 
torben Hohn
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] tschack ... early version of smp enabled jack1

[Stéphane Letz]

Le 27 janv. 2010 à 19:41, torbenh a écrit :

> On Tue, Jan 26, 2010 at 12:38:53PM +, Chris Cannam wrote:
>> On Sun, Jan 24, 2010 at 9:05 PM, torbenh  wrote:
>>> since i dont want to let jack1 codebase die in a feature freeze,
>>> i added some features.
>>> 
>>> - smp aware
>>> - clickless connections
>> 
>> Is there any reason why a user would prefer this over jack2?
> 
> i am not sure, but there a several users which report xruns with jack2,
> where jack1 still works.
> though i am not sure if they tested jack 1.9.4 which seem ok in sync mode
> at least. 

JACK2 code base can be instrumented (using the  "--profile  Build with engine 
profiling" option ) to give more precise understanding of the source of 
possible Xruns.

See : http://www.grame.fr/Ressources/pub/JACK2_lac2009.pdf

We cannot fix possible issues if they are not reported with some precise infos 
on what happens.

Stéphane
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] tschack ... early version of smp enabled jack1

[alex stone]

Torben, after the flurry of initial testing, and substantial updates,
i've got a better view of tschack with a full day's testing, today.

tschack, with the exception of the 3 updates you did, has been running
solid all day. No xruns reports, or sudden spikes. I've been using it
in real use case, with a large linuxsampler  samplelib set, oom,
a2jmidid, calf verb, jp1 patchbay, non-daw for some modest recording
tryouts, and a lot of midi and audio ports (i mean hundreds) as if i
were running a normal day. There's been  a lot of starts and stops, as
i edit midi, and kick large orchestral midi files into life, and kill
em again. in this real use case (mine), i guess real numbers are as
appropriate as they are going to get in this, the early stages.

It's been a good day, and i've enjoyed the stability. I used jack1
before, because it gave me fewer challenges, xruns and occasional pops
and spits, than jack2, which i ended up having to ease out to
48000/512/3, to reach near the same performance. (i'm on 48000/256/3
with jack1) Doing lots of midi editing, and starting large sample sets
for orchestral work can be quickly problematic, and today i was able
to sit on 48000/256/3 all day with trouble free performance.

Subjective stuff i know, but it's been enjoyable and productive, and
that's a criteria for me.

I'll keep testing, and i'm somewhat rueful about jconvolver, but that
aside, (and i hope i can use it again in the near future), the rest of
the setup has been cruising along, and not getting in the way of me
writing, with problems, or glitches.

All in all, a good day, and looking forward to the next stage in the
progress of tschack, and what else you might consider adding to this
experimental version. As we're free of political constraints, and
mainstream requirements, i have a "modest' list of suggestions you
might want (or not) to have a look over. :)

More to come...

Alex.


-- 
www.openoctave.org

midi-subscr...@openoctave.org
development-subscr...@openoctave.org
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] tschack ... early version of smp enabled jack1

[Jörn Nettingsmeier]

On 01/27/2010 08:39 PM, alex stone wrote:

> It's been a good day, and i've enjoyed the stability. I used jack1
> before, because it gave me fewer challenges, xruns and occasional pops
> and spits, than jack2, which i ended up having to ease out to
> 48000/512/3, to reach near the same performance. (i'm on 48000/256/3
> with jack1)

for some more anecdotal evidence, this is about what i was seeing during 
my jack1/2 comparison tests. jack2 generally required one buffer size 
step more to achieve the same xrun robustness as jack1. but i'm 
generally able to use much lower latencies down to 64 (or 128 in the 
jack2 case), unless i use jconvolver, which forces me to go to at least 
1024 so as not to max out the cpu.

i didn't think too much about jack2's apparent overhead, since it has 
the benefit of scaling to smp, which usually affects the 
single-processor case (my box is a single-core amd64).
it would be interesting to see if torben's approach is able to deliver 
the same latencies as jack1, while adding smp support.

regards,

jörn

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] tschack ... early version of smp enabled jack1

[Stéphane Letz]

Le 27 janv. 2010 à 21:02, Jörn Nettingsmeier a écrit :

> On 01/27/2010 08:39 PM, alex stone wrote:
> 
>> It's been a good day, and i've enjoyed the stability. I used jack1
>> before, because it gave me fewer challenges, xruns and occasional pops
>> and spits, than jack2, which i ended up having to ease out to
>> 48000/512/3, to reach near the same performance. (i'm on 48000/256/3
>> with jack1)
> 
> for some more anecdotal evidence, this is about what i was seeing during 
> my jack1/2 comparison tests. jack2 generally required one buffer size 
> step more to achieve the same xrun robustness as jack1. but i'm 
> generally able to use much lower latencies down to 64 (or 128 in the 
> jack2 case), unless i use jconvolver, which forces me to go to at least 
> 1024 so as not to max out the cpu.
> 
> i didn't think too much about jack2's apparent overhead, since it has 
> the benefit of scaling to smp, which usually affects the 
> single-processor case (my box is a single-core amd64).
> it would be interesting to see if torben's approach is able to deliver 
> the same latencies as jack1, while adding smp support.
> 
> regards,
> 
> jörn

Well "jack2's apparent overhead," is something new for me, and would require 
some deeper test/feedback to understand better. Moreover without more precise 
description of xruns occurrence (at what DSP CPU does it start to happen.. 
etc..) , what kind of setup (jack2 version, jack configuration, applications 
used), it is again hard to understand/correct things.

Stéphane

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] tschack ... early version of smp enabled jack1

[Jörn Nettingsmeier]

On 01/27/2010 09:11 PM, Stéphane Letz wrote:
>
> Le 27 janv. 2010 à 21:02, Jörn Nettingsmeier a écrit :
>
>> On 01/27/2010 08:39 PM, alex stone wrote:
>>
>>> It's been a good day, and i've enjoyed the stability. I used jack1
>>> before, because it gave me fewer challenges, xruns and occasional pops
>>> and spits, than jack2, which i ended up having to ease out to
>>> 48000/512/3, to reach near the same performance. (i'm on 48000/256/3
>>> with jack1)
>>
>> for some more anecdotal evidence, this is about what i was seeing during
>> my jack1/2 comparison tests. jack2 generally required one buffer size
>> step more to achieve the same xrun robustness as jack1. but i'm
>> generally able to use much lower latencies down to 64 (or 128 in the
>> jack2 case), unless i use jconvolver, which forces me to go to at least
>> 1024 so as not to max out the cpu.
>>
>> i didn't think too much about jack2's apparent overhead, since it has
>> the benefit of scaling to smp, which usually affects the
>> single-processor case (my box is a single-core amd64).
>> it would be interesting to see if torben's approach is able to deliver
>> the same latencies as jack1, while adding smp support.
>>
>> regards,
>>
>> jörn
>
> Well "jack2's apparent overhead," is something new for me, and would require 
> some deeper test/feedback to understand better. Moreover without more precise 
> description of xruns occurrence (at what DSP CPU does it start to happen.. 
> etc..) , what kind of setup (jack2 version, jack configuration, applications 
> used), it is again hard to understand/correct things.
>
> Stéphane
>

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] tschack ... early version of smp enabled jack1

[Jörn Nettingsmeier]

sorry about the previous bogus message, i fat-fingered the rewrap 
button... :(

On 01/27/2010 09:11 PM, Stéphane Letz wrote:
>
> Le 27 janv. 2010 à 21:02, Jörn Nettingsmeier a écrit :

>> i didn't think too much about jack2's apparent overhead, since it
>> has the benefit of scaling to smp, which usually affects the
>> single-processor case (my box is a single-core amd64). it would be
>> interesting to see if torben's approach is able to deliver the same
>> latencies as jack1, while adding smp support.

> Well "jack2's apparent overhead," is something new for me, and would
> require some deeper test/feedback to understand better. Moreover
> without more precise description of xruns occurrence (at what DSP CPU
> does it start to happen.. etc..) , what kind of setup (jack2 version,
> jack configuration, applications used), it is again hard to
> understand/correct things.

well, as i said, it was nothing really conclusive (i'm not going to 
waste much time to go from 128/2 to 64/2, diminishing returns...), and 
my box is generally under-powered for what i do with it.

in short, i figured it's not significant really. i merely added this 
here in case there's a general picture emerging... it wasn't even 
intended as criticism.

and even if it turned out jack2 would be one step worse than jack1, 
that's not at all a big price to pay for smp imho. same with the kernel: 
an smp build does degrade performance on an up box, but who cares, 
really? you can't even buy up workstations any more, and nature dictates 
that single-core performance has hit its limit...

luck has it that my mobo just got fried, so chances are i'll be 
contributing some nice quad-core data in the near future - if only my 
customers paid their bills on time...


best,

jörn

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] tschack ... early version of smp enabled jack1

[alex stone]

2010/1/27 Stéphane Letz :
>
> Le 27 janv. 2010 à 21:02, Jörn Nettingsmeier a écrit :
>
>> On 01/27/2010 08:39 PM, alex stone wrote:
>>
>>> It's been a good day, and i've enjoyed the stability. I used jack1
>>> before, because it gave me fewer challenges, xruns and occasional pops
>>> and spits, than jack2, which i ended up having to ease out to
>>> 48000/512/3, to reach near the same performance. (i'm on 48000/256/3
>>> with jack1)
>>
>> for some more anecdotal evidence, this is about what i was seeing during
>> my jack1/2 comparison tests. jack2 generally required one buffer size
>> step more to achieve the same xrun robustness as jack1. but i'm
>> generally able to use much lower latencies down to 64 (or 128 in the
>> jack2 case), unless i use jconvolver, which forces me to go to at least
>> 1024 so as not to max out the cpu.
>>
>> i didn't think too much about jack2's apparent overhead, since it has
>> the benefit of scaling to smp, which usually affects the
>> single-processor case (my box is a single-core amd64).
>> it would be interesting to see if torben's approach is able to deliver
>> the same latencies as jack1, while adding smp support.
>>
>> regards,
>>
>> jörn
>
> Well "jack2's apparent overhead," is something new for me, and would require 
> some deeper test/feedback to understand better. Moreover without more precise 
> description of xruns occurrence (at what DSP CPU does it start to happen.. 
> etc..) , what kind of setup (jack2 version, jack configuration, applications 
> used), it is again hard to understand/correct things.
>
> Stéphane
>
> ___
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-dev
>

Stephane, you make a fair point, but i will say again here, tschack is
an experimental version of Jack1, and as Torben has already indicated,
it's not going to be mainstream.
On the brighter side for all the community, there's an opportunity
here, with the above in mind, to experiment with other features and
components that might prove useful for consideration in both the
malnstream versions in the future.

I for one, and i only speak for myself, think it's of potential
benefit to the community to try new features in a non public, more
controlled environment, and aid Torben in this experiment however i
can.

I shall continue to do so.

Alex.

-- 
www.openoctave.org

midi-subscr...@openoctave.org
development-subscr...@openoctave.org
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] tschack ... early version of smp enabled jack1

[fons]

On Wed, Jan 27, 2010 at 09:02:39PM +0100, Jörn Nettingsmeier wrote:

> for some more anecdotal evidence, this is about what i was seeing during 
> my jack1/2 comparison tests. jack2 generally required one buffer size 
> step more to achieve the same xrun robustness as jack1. but i'm 
> generally able to use much lower latencies down to 64 (or 128 in the 
> jack2 case), unless i use jconvolver, which forces me to go to at least 
> 1024 so as not to max out the cpu.

That doesn't make much sense. You can instruct jconvolver
to use a minimum period size that is larger than the one
Jack* is running.

-- 
FA

O tu, che porte, correndo si ?
E guerra e morte !
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] tschack ... early version of smp enabled jack1

[Stéphane Letz]

>> s.
> 
> well, as i said, it was nothing really conclusive (i'm not going to waste 
> much time to go from 128/2 to 64/2, diminishing returns...), and my box is 
> generally under-powered for what i do with it.
> 
> in short, i figured it's not significant really. i merely added this here in 
> case there's a general picture emerging... it wasn't even intended as 
> criticism.
> 
> and even if it turned out jack2 would be one step worse than jack1, that's 
> not at all a big price to pay for smp imho. same with the kernel: an smp 
> build does degrade performance on an up box, but who cares, really? you can't 
> even buy up workstations any more, and nature dictates that single-core 
> performance has hit its limit...
> 
> luck has it that my mobo just got fried, so chances are i'll be contributing 
> some nice quad-core data in the near future - if only my customers paid their 
> bills on time...
> 
> 
> best,
> 
> jörn
> 


The point is not "criticism" or not ((-: , but if i can get any useful info to 
see if a real problem still exist or if any kind of regression between 2 
versions has happened somewhere..

Stéphane
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] tschack ... early version of smp enabled jack1

[Jörn Nettingsmeier]

On 01/27/2010 09:28 PM, f...@kokkinizita.net wrote:
> On Wed, Jan 27, 2010 at 09:02:39PM +0100, Jörn Nettingsmeier wrote:
>
>> but i'm
>> generally able to use much lower latencies down to 64 (or 128 in the
>> jack2 case), unless i use jconvolver, which forces me to go to at least
>> 1024 so as not to max out the cpu.
>
> That doesn't make much sense. You can instruct jconvolver
> to use a minimum period size that is larger than the one
> Jack* is running.

yes, i know, but this (from README.CONFIG) made me think twice:

> /convolver/new 
>
> This command is always required and must be first one. All parameters
> are in decimal. The 'partition size' is the minumum partition size that
> will be used, and should be between 1 and 16 times the Jack period size.
> It will be adjusted (with a warning) otherwise. Processing delay will
> be zero if this is set to the Jack period size.

i read this as "otherwise processing delay will be variable, depending 
on the jack period size". please correct me if i'm wrong.

the problem is that the initial delay of any reverb effect affects 
mixing decisions a great deal, and i want to make sure it's not a 
function of the jack period size

best,

jörn


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] tschack ... early version of smp enabled jack1

[Chris Cannam]

On Wed, Jan 27, 2010 at 6:41 PM, torbenh  wrote:
> i am not sure, but there a several users which report xruns with jack2,
> where jack1 still works.

Interesting.  At Fervent back in the day we switched from jack to
jackdmp (i.e. jack2) as the default server in our long-defunct Studio
to Go distro some three or four years ago, and at the time our tests
suggested its performance was pretty similar to jack1.  Since jackdmp
of course already had the features you're talking about (SMP
capability and clickless connection), it seemed like an obvious thing
to do.  I used to wonder why anyone still used jack1.

Of course now I use a stock distro with stock packages, and I
generally use jack1 myself because it's what's packaged.  I excuse
myself by arguing that it's wise to test with what other users have
got...


Chris
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

[LAD] [OT] jack2 on solaris, was Re: tschack ... early version of smp enabled jack1

[Chris Cannam]

Stéphane -- sorry to veer so wildly off-topic... but jackdmp is
expected to work on Solaris, right?  Is it actively tested?  Is it
expected to build with Sun compilers, or only with gcc?

I switched a machine from Linux to OpenSolaris a few months back and
at the time failed to get jackdmp working on it, but I didn't give it
much time because it wasn't all that important then.  I'd like to
revisit it though, and wondered what I should reasonably expect.


Chris
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

[LAD] LAC2010: Paper deadline coming closer

[Frank Neumann]

Dear all,

the deadline for submission of papers for the Linux Audio Conference 2010(*)
is coming closer (February 14th, 2010), and (like last year) the amount of
submissions so far is..quite small. However, without papers and presentations
this kind of conference cannot exist.

I believe that most of the prospective paper submitters out there will probably
wait until the very last minute (I recall in one case there was even a bit of
a debate about "what exact time, and what time zone please?" :-), but it would
be helpful to get an idea of the upcoming submissions.

For this reason I am asking that if you plan to submit a paper, to give us/me
a short notice (title, topic) of your planned paper (direct reply, no need to
send that information to any of the addressed lists). This would help us in
planning the next necessary steps.
By the way, we are not considering to extend the paper deadline this year.

Please feel free to forward this mail to whatever people/mailing lists are
suitable.

Regards,
Frank Neumann, on behalf of the LAC2010 organization team

(*) See http://lac.linuxaudio.org/2010
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [OT] jack2 on solaris, was Re: tschack ... early version of smp enabled jack1

[Stéphane Letz]

Le 27 janv. 2010 à 21:59, Chris Cannam a écrit :

> Stéphane -- sorry to veer so wildly off-topic... but jackdmp is
> expected to work on Solaris, right?  Is it actively tested?  Is it
> expected to build with Sun compilers, or only with gcc?

Right now with gcc yes. At some point I succeeded with sun compiler hacking 
"waf" build tool (that was not well supported at that time).

I still check SVN from time to time and it is supposed to work correctly yes.

> 
> I switched a machine from Linux to OpenSolaris a few months back and
> at the time failed to get jackdmp working on it, but I didn't give it
> much time because it wasn't all that important then.  I'd like to
> revisit it though, and wondered what I should reasonably expect.
> 

Should work.

Backends are currently 2 and using the OSS 4 API:

- jack_oss.o one ( so "jack -S -R -d oss blab blah...) a one thread driver, 
initially developed for RTL and tested on a MADI card

- later on I switched to a more general (and probably more exact) 2 threads 
model. It got called "boomer' (Boomer is the SUN derived from OSS  audio 
API..). So "jack -S -R -d boomer blab blah

Both should work on OpenSolaris with 4 Front OSS.  I never tried with Boomer 
since my internal card was not supported at that time

Stephane
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [OT] jack2 on solaris, was Re: tschack ... early version of smp enabled jack1

[Chris Cannam]

On Wed, Jan 27, 2010 at 9:10 PM, Stéphane Letz  wrote:
> - jack_oss.o one ( so "jack -S -R -d oss blab blah...) a one thread driver, 
> initially developed for RTL and tested on a MADI card
>
> - later on I switched to a more general (and probably more exact) 2 threads 
> model. It got called "boomer' (Boomer is the SUN derived from OSS  audio 
> API..). So "jack -S -R -d boomer blab blah
>
> Both should work on OpenSolaris with 4 Front OSS.  I never tried with Boomer 
> since my internal card was not supported at that time

OK.  I do have Boomer (using OpenSolaris dev repositories, currently
build snv_131)... but do I gather from the above that I don't
necessarily have to use the Boomer back-end?  so if I have trouble
with it, I ought to be able to get away with the old-fashioned OSS
one?

(Sound generally does work on the machine, including OSS4 software mixing.)


Chris
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] tschack ... early version of smp enabled jack1

[Patrick Shirkey]

>
> sorry about the previous bogus message, i fat-fingered the rewrap
> button... :(
>
> On 01/27/2010 09:11 PM, Stéphane Letz wrote:
>
>> Le 27 janv. 2010 à 21:02, Jörn Nettingsmeier a écrit :
>>  
>
>>> i didn't think too much about jack2's apparent overhead, since it
>>> has the benefit of scaling to smp, which usually affects the
>>> single-processor case (my box is a single-core amd64). it would be
>>> interesting to see if torben's approach is able to deliver the same
>>> latencies as jack1, while adding smp support.
>>>
>
>> Well "jack2's apparent overhead," is something new for me, and would
>> require some deeper test/feedback to understand better. Moreover
>> without more precise description of xruns occurrence (at what DSP CPU
>> does it start to happen.. etc..) , what kind of setup (jack2 version,
>> jack configuration, applications used), it is again hard to
>> understand/correct things.
>>  
> well, as i said, it was nothing really conclusive (i'm not going to
> waste much time to go from 128/2 to 64/2, diminishing returns...), and
> my box is generally under-powered for what i do with it.
>
> in short, i figured it's not significant really. i merely added this
> here in case there's a general picture emerging... it wasn't even
> intended as criticism.
>
> and even if it turned out jack2 would be one step worse than jack1,
> that's not at all a big price to pay for smp imho. same with the kernel:
> an smp build does degrade performance on an up box, but who cares,
> really? you can't even buy up workstations any more, and nature dictates
> that single-core performance has hit its limit...
>
>


As a point of reference I just recorded 10 hours of data this past 
weekend on my quad core and was having several issues with jackeq + 
jack1 prior to starting that were solved by moving to jack2. However I 
didn't test with latest svn of jack1 so it may just be the Fedora 12 
package of jack1 that was causing me headaches.





Patrick Shirkey
Boost Hardware Ltd



> luck has it that my mobo just got fried, so chances are i'll be
> contributing some nice quad-core data in the near future - if only my
> customers paid their bills on time...
>
>
> best,
>
> jörn
>
> ___
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-dev
>
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [Jack-Devel] tschack ... early version of smp enabled jack1

[Gabriel M. Beddingfield]

On Wed, 27 Jan 2010, Stéphane Letz wrote:

JACK2 code base can be instrumented (using the "--profile 
Build with engine profiling" option ) to give more precise 
understanding of the source of possible Xruns.


See : http://www.grame.fr/Ressources/pub/JACK2_lac2009.pdf

We cannot fix possible issues if they are not reported 
with some precise infos on what happens.


I started playing with this -- and this is pretty cool. 
Great work!


I had been avoid this because I figured it comes with a 
performance overhead (like -gprof does).  Or, perhaps it 
only has overhead when you use it (like Sun's strace). 
What overhead does compiling with --profile introduce?  Why 
not have it enabled by default?


Suggestion/Issue:  I have PDF issues with the 
TimingN.plot (gnuplot) files that it outputs.  They always 
issue the command 'set terminal pdf' and try to output a PDF 
file.  These create an error on my system and I have to 
manually delete them or change them to something like SVG 
or EPS.


Apparently, there's a license issue with libpdflite (which 
gnuplot uses to generate PDFs)... so some distro's won't 
have it installed.


Thanks,
Gabriel___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [OT] jack2 on solaris, was Re: tschack ... early version of smp enabled jack1

[Stéphane Letz]

Le 27 janv. 2010 à 22:14, Chris Cannam a écrit :

> On Wed, Jan 27, 2010 at 9:10 PM, Stéphane Letz  wrote:
>> - jack_oss.o one ( so "jack -S -R -d oss blab blah...) a one thread driver, 
>> initially developed for RTL and tested on a MADI card
>> 
>> - later on I switched to a more general (and probably more exact) 2 threads 
>> model. It got called "boomer' (Boomer is the SUN derived from OSS  audio 
>> API..). So "jack -S -R -d boomer blab blah
>> 
>> Both should work on OpenSolaris with 4 Front OSS.  I never tried with Boomer 
>> since my internal card was not supported at that time
> 
> OK.  I do have Boomer (using OpenSolaris dev repositories, currently
> build snv_131)... but do I gather from the above that I don't
> necessarily have to use the Boomer back-end?  so if I have trouble
> with it, I ought to be able to get away with the old-fashioned OSS
> one?
> 
> (Sound generally does work on the machine, including OSS4 software mixing.)
> 
> 
> Chris


Boomer and OSS are actually quite similar. Both "oss" and "boomer" jack2 
backend have been tested on an OSS installation only, never on Boomer. So real 
test are needed.

Stéphane

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [Jack-Devel] tschack ... early version of smp enabled jack1

[Stéphane Letz]

Le 28 janv. 2010 à 05:39, Gabriel M. Beddingfield a écrit :

> 
> 
> On Wed, 27 Jan 2010, Stéphane Letz wrote:
> 
>> JACK2 code base can be instrumented (using the "--profile Build with engine 
>> profiling" option ) to give more precise understanding of the source of 
>> possible Xruns.
>> 
>> See : http://www.grame.fr/Ressources/pub/JACK2_lac2009.pdf
>> 
>> We cannot fix possible issues if they are not reported with some precise 
>> infos on what happens.
> 
> I started playing with this -- and this is pretty cool. Great work!
> 
> I had been avoid this because I figured it comes with a performance overhead 
> (like -gprof does).  Or, perhaps it only has overhead when you use it (like 
> Sun's strace). What overhead does compiling with --profile introduce?  Why 
> not have it enabled by default?

It mainly consume additional memory (a big array that is progressively filled 
with timing measures...), this is why it is off by default.

> 
> Suggestion/Issue:  I have PDF issues with the TimingN.plot (gnuplot) files 
> that it outputs.  They always issue the command 'set terminal pdf' and try to 
> output a PDF file.  These create an error on my system and I have to manually 
> delete them or change them to something like SVG or EPS.

Yep, any suggestion to improve the .plot files? like kind of conditional 
generation of PDF?
> 
> Apparently, there's a license issue with libpdflite (which gnuplot uses to 
> generate PDFs)... so some distro's won't have it installed.
> 
> Thanks,
> Gabriel


Stéphane
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev