It really blew my mind when Andre Pang <[EMAIL PROTECTED]> said:
> Are you going to allow the JACK library to be statically linked if
> it's LGPLed? You can use an LGPLed library in your own program if
> it's dynamically linked, but you're not allowed to statically link
> it since it's considere
here's some inportant information on soundcard syncing and budget
recording studio. i use linux because i don't like paying hundreds and
thousands for windows software that runs like crap together (my roommate
has done this, and has to fdisk about once a month because one programs
screws up anoth
Paul Davis wrote:
> OK folks, JACK CVS is now online:
The first change should be making the link to the project page actually
point to the project page of jackit, not ardour ;)
-a
On Sun, Nov 11, 2001 at 01:40:54PM -0500, Paul Davis wrote:
> Thus, the JACK server will be GPL, along with the ALSA
> driver module. But the "library" will be LGPL. this way,
> non-free programs can use the library, but the server and
> driver(s) cannot be co-opted in the same way.
Are you goin
OK folks, JACK CVS is now online:
for anonymous access:
% cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/jackit login
% cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvsroot/jackit co jack
if you want write access, ask and you'll probably get it. then:
export CVS_RSH=ssh
cvs -z3 -d:ext:[EMAIL
* Paul Davis ([EMAIL PROTECTED]) wrote:
> you should be counting programmer time as worth at least US$30/hr even
> if you don't actually pay them.
[and]
> 3 months after i had been paid to put in about 20 hours on these
> workarounds at the going device driver/kernel/application consultant
> ra
greetings,
As the not-so-proud owner of an SBLive card, I thought I'd chime in.
Your project sounds really cool, and I'm all in favor of highly
unorthodox ideas. I'd be very interested in hearing the result, and if
you do write some code, I'd love to see it. But please, do your
>it is he himself, but he is *keen* to waste this time and
>explore the issues of multiple soundcard sync.
understood. i really wasn't intending to be harsh, just trying to
point out some issues that i personally consider really
important. good luck. i suspect that tomorrow you'll get some
friend
hi,
i'm looking for a powerful time stretching and compression
tool for Linux, something on the level of the ProTools plugin.
what i will need is something that will allow time
stretching and compression based on calculations of number
of samples, or compression to a specific length, in
divisions
I personally prefer the LGPL for libraries and JACK seems to be one.
But it's your code isn't it? Itsn't it up to you to choose then?
Sebastien
- Original Message -
From: "Paul Davis" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, November 11, 2001 5:43 PM
Subject: [linux-aud
On Sun, 11 Nov 2001, Paul Davis wrote:
> and its done. the following hack satisfies this quite easily (given
> what we know about the kernel's mapping of tasks):
>
> static char *top_end_of_unmapped_memory = (char *) (1048576 * 1536); /* 1.5GB */
> static char *low_end_of_unmapped_memory = (char
>No, sorry. Indeed it does - it is even specified to do so. From SUS on
>mmap:
[ very helpful stuff elided ]
>> work in the particular way that it does. this is a technique i've used
>> in the past on Interactive Unix, on Mach, on Ultrix and on Solaris.
>
>You happen to be lucky then :) The s
friends - there is an important question to be made about the
licensing for JACK. i suspect the answer will be simple for most of
us, but it needs to be asked.
right now, the JACK source code is released under the GPL. this would
prohibit non-free programs from using JACK. it therefore seems more
On Sun, 11 Nov 2001, Paul Davis wrote:
> >> if you call shmat(2) or mmap(2) with a specific address, the kernel
> >> assumes that you know what you're doing and unmaps anything thats
> >> already mapped there.
> >
> >No it doesnt.
>
> did you even bother to run my test program?
No, sorry. Indee
>> if you call shmat(2) or mmap(2) with a specific address, the kernel
>> assumes that you know what you're doing and unmaps anything thats
>> already mapped there.
>
>No it doesnt.
did you even bother to run my test program? look at the message from
reynald where he posted his results, then go r
On Sat, 10 Nov 2001, Paul Davis wrote:
> i figured out what was wrong.
>
> if you call shmat(2) or mmap(2) with a specific address, the kernel
> assumes that you know what you're doing and unmaps anything thats
> already mapped there.
No it doesnt.
> i was trying to force the same address for
16 matches
Mail list logo
