17 Apr
2010
17 Apr
'10
8:10 a.m.
At Grame, we started working on JACK (jack1 at that time) in 2003 and our first commitment
was to port the C code base on OSX. Even if the result was working, we rapidly felt that
the C code base was not flexible enough to evolve in the direction we wanted to explore:
multi-platforms support, SMP and glitch-free connections (among other ideas we had...) .
Around 2004-2005 we had a new C++ based code base that was first developed on OSX, later
ported in Linux (2005), on Windows (summer 2006) and Solaris (summer 2008 as a result of
funding coming from RTL french radio). In 2004 we also found the way to better
"integrate" JACK in the CoreAudio architecture on OSX (the JackRouter
JACK/CoreAudio bridge) that allowed any CoreAudio application to become a JACK client,
thus participating in the success we had on OSX with the JackOSX package.
I think the "about 3 years ago, the JACK mini-summit in Berlin" Paul told about,
was actually during LAC 2008 in Kohn. It was my impression that most of the JACK community
was interested to see jackdmp (renamed jack2 at that moment) become the future of JACK,
and late 2008 and 2009 was an intense period of work to reach this goal. Nedko (mostly but
some other) did a huge job of improving the build system, implement the so-called
"JACK Control API" (or at least the server side of it) and helped in other
areas. The D-Bus based server control code (Nedko) was also integrated at that time.
In spring 2009 started this "D-Bus war" and after endless discussion with people
with strong opinions (Fons, Nedko...) it appeared that no agreement could be found. The
best that we could achieve (in my view) was to clearly define the "JACK Control
API" as the "frontier" between the external world that wants to control the
JACK server, and the server code itself, and report all more sophisticated control
mechanism outside. At about the same time, some developers (Torben, Paul ...) started to
rebirth the jack1 codebase, and it appeared more and more clear that the "jack2
become the official code base" idea start to become a vanishing goal.
I must say that I still don't have a clear understanding of why this happened. I still
don't understand the sentence "Like Torben, there are some design decisions there
that I have questions about." and I think explaining it in more details would really
help. The fact that jack1 and jack2 are almost indistinguishable in everyday use is quite
satisfactory, but at the same time the subtle difference that stay continue to cause some
endless comments from users about the "real" advantages of each of the two
implementations. I still see reports from "more xruns" here or a "bit less
CPU use" there, but with no real data and clear "step by step way to reproduce
issues" that would help to fix remaining bugs in jack2 codebase (for example jack2
still probably has issue with multi-cards support compared to jack1, but AFAICS this is in
ALSA backend, and I cannot progress on that without the help of people with multi-cards
and knowledge in ALSA backend code).
Concerning session management added in JACK codebase, I did not followed the discussion in
details. I said to Paul in a private mail that I though it was not a good idea (but maybe
I am completely wrong...) but I would certainly not oppose to a implementation for jack2.
I remember someone volunteered to work on that ??
I have to say that I become quite tired of all that mess, since I don't see any clear
way to solve the situation. After about 5 years of real commitment in JACK project, I
decided to move back a bit and work on some other stuff. I still try to follow bug reports
and jack1 changes, release a package from time to time and maintain JackOSX project. I
still think some interesting ideas (like the "pipelining" mode that currently
stay in a jack2 branch...) are of interest (especially since we now see with those "4
cores/threads" model in new laptops...) and should be pushed in mainline.
Stéphane
17 Apr
17 Apr
11:08 a.m.
New subject: distros migrating to JACK2?
On Sat, Apr 17, 2010 at 12:10:10PM +0200, Stéphane LETZ wrote:
Concerning session management added in JACK codebase,
I did not followed the discussion in details. I said to Paul in a private mail that I
though it was not a good idea (but maybe I am completely wrong...) but I would certainly
not oppose to a implementation for jack2. I remember someone volunteered to work on that
??
yeah. paniq said he would do it. but he somehow disappeared.
i am working on it now.
gonna push what i have to repo.or.cz after i finish this mail.
its not finished yet. but please comment.
--
torben Hohn
18 Apr
18 Apr
7:16 a.m.
New subject: [Jack-Devel] distros migrating to JACK2?
On Sat, 2010-04-17 at 12:10 +0200, Stéphane LETZ wrote:
At Grame, we started working on JACK (jack1 at that
time) in 2003 and our first commitment was to port the C code base on OSX. Even if the
result was working, we rapidly felt that the C code base was not flexible enough to evolve
in the direction we wanted to explore: multi-platforms support, SMP and glitch-free
connections (among other ideas we had...) . Around 2004-2005 we had a new C++ based code
base that was first developed on OSX, later ported in Linux (2005), on Windows (summer
2006) and Solaris (summer 2008 as a result of funding coming from RTL french radio). In
2004 we also found the way to better "integrate" JACK in the CoreAudio
architecture on OSX (the JackRouter JACK/CoreAudio bridge) that allowed any CoreAudio
application to become a JACK client, thus participating in the success we had on OSX with
the JackOSX package.
I think the "about 3 years ago, the JACK mini-summit in Berlin" Paul told
about, was actually during LAC 2008 in Kohn. It was my impression that most of the JACK
community was interested to see jackdmp (renamed jack2 at that moment) become the future
of JACK, and late 2008 and 2009 was an intense period of work to reach this goal. Nedko
(mostly but some other) did a huge job of improving the build system, implement the
so-called "JACK Control API" (or at least the server side of it) and helped in
other areas. The D-Bus based server control code (Nedko) was also integrated at that time.
In spring 2009 started this "D-Bus war" and after endless discussion with
people with strong opinions (Fons, Nedko...) it appeared that no agreement could be found.
The best that we could achieve (in my view) was to clearly define the "JACK Control
API" as the "frontier" between the external world that wants to control the
JACK server, and the server code itself, and report all more sophisticated control
mechanism outside. At about the same time, some developers (Torben, Paul ...) started to
rebirth the jack1 codebase, and it appeared more and more clear that the "jack2
become the official code base" idea start to become a vanishing goal.
I must say that I still don't have a clear understanding of why this happened. I
still don't understand the sentence "Like Torben, there are some design decisions
there that I have questions about." and I think explaining it in more details would
really help.
It's pretty odd that you guys didn't discuss this clearly with each
other. It seems that people have an opinion about something, but only
share this with people who have the same opinion and not with the one
who himself or his code is subject of 'critique'. This is bad
communication and bad team management.
The fact that jack1 and jack2 are almost
indistinguishable in everyday use is quite satisfactory, but at the same time the subtle
difference that stay continue to cause some endless comments from users about the
"real" advantages of each of the two implementations. I still see reports from
"more xruns" here or a "bit less CPU use" there, but with no real data
and clear "step by step way to reproduce issues" that would help to fix
remaining bugs in jack2 codebase (for example jack2 still probably has issue with
multi-cards support compared to jack1, but AFAICS this is in ALSA backend, and I cannot
progress on that without the help of people with multi-cards and knowledge in ALSA backend
code).
Concerning session management added in JACK codebase, I did not followed the discussion
in details. I said to Paul in a private mail that I though it was not a good idea (but
maybe I am completely wrong...) but I would certainly not oppose to a implementation for
jack2. I remember someone volunteered to work on that ??
I have to say that I become quite tired of all that mess, since I don't see any clear
way to solve the situation. After about 5 years of real commitment in JACK project, I
decided to move back a bit and work on some other stuff. I still try to follow bug reports
and jack1 changes, release a package from time to time and maintain JackOSX project. I
still think some interesting ideas (like the "pipelining" mode that currently
stay in a jack2 branch...) are of interest (especially since we now see with those "4
cores/threads" model in new laptops...) and should be pushed in mainline.
It would be good if an '(mini) JACK Conference' will be organized, where
JACK developers can speak each other face to face, code to code. And
share future vision, coding vision etc. IRC and mailinglists are great,
but not always the good method for communication.
Regards,
\r
10:31 a.m.
New subject: [Jack-Devel] distros migrating to JACK2?
On Sun, Apr 18, 2010 at 5:16 AM, rosea.grammostola
<rosea.grammostola(a)gmail.com> wrote:
It's pretty odd that you guys didn't discuss
this clearly with each
other. It seems that people have an opinion about something, but only
share this with people who have the same opinion and not with the one
who himself or his code is subject of 'critique'. This is bad
communication and bad team management.
oh god. you clearly don't understand ANYTHING about how open source
development works.
there was constant discussion about all of this. But Stephane doesn't
own JACK, I don't own JACK, Torben doesn't own JACK, Jack O'Quinn
doesn't own JACK. When someone works on their own implementation of
JACK, they are free to make their own decisions about how things are
done. Maybe their ideas will be better (or worse, or about the same)
as any existing implementation, and because of this, its important to
allow them to take shape as they see fit. Clearly, providing useful
feedback and ideas is great, but there's no reason for any committees
or meetings to decide how a different implementation is going to work.
In this particular case, Jack2 started out (as Stephane has described)
as a sort of experiment - how would SMP support work, could we do
click-free graph changes, would a C++ implementation be easier to
manage, etc. etc. In that context, its not appropriate for anyone
who's not actually working on it to be trying to make decisions about
internal design. Lots of people, including myself, had input into the
design and evolution of Jack2. Pretending otherwise is ridiculous.
Jack1, Jack2 (and even the not-quite-born tschak) all implement 99.83%
of the same API. Beyond that, how they work internally is the business
of their implementors and maintainers. If someone has an opinion about
it, they are free to take it up with the implementors and maintainers.
If they feel strongly enough about it, and they don't feel that the
implementors/maintainers are doing things in the right way, they can
fork or reimplement (this clearly doesn't happen much).
It would be good if an '(mini) JACK
Conference' will be organized, where
JACK developers can speak each other face to face, code to code. And
share future vision, coding vision etc. IRC and mailinglists are great,
but not always the good method for communication.
Traditionally, this would be done at the Linux Audio Conference, which
I will, alas, be unable to attend this year. That doesn't stop other
people from meeting on these issues, but my impression is that we have
all become somewhat tired of struggling with the situation and instead
have been trying to find ways to allow the status quo to continue, but
better.
6:21 p.m.
New subject: [Jack-Devel] distros migrating to JACK2?
On Sun, 2010-04-18 at 08:31 -0400, Paul Davis wrote:
On Sun, Apr 18, 2010 at 5:16 AM, rosea.grammostola
<rosea.grammostola(a)gmail.com> wrote:
This could all be true, but that's not the point I was talking about.
JACK2 was planned as successor of JACK1. But at some point that changed,
that's all ok, not the point here. But isn't it odd that this isn't
clearly communicated with the JACK2 maintainer, why this is happened?
That was raising questions here about the communication within the
(highly appreciated) JACK project.
quote=Stephane
It's pretty odd that you guys didn't
discuss this clearly with each
other. It seems that people have an opinion about something, but only
share this with people who have the same opinion and not with the one
who himself or his code is subject of 'critique'. This is bad
communication and bad team management.
oh god. you clearly don't understand ANYTHING about how open source
development works.
there was constant discussion about all of this. But Stephane doesn't
own JACK, I don't own JACK, Torben doesn't own JACK, Jack O'Quinn
doesn't own JACK. When someone works on their own implementation of
JACK, they are free to make their own decisions about how things are
done. Maybe their ideas will be better (or worse, or about the same)
as any existing implementation, and because of this, its important to
allow them to take shape as they see fit. Clearly, providing useful
feedback and ideas is great, but there's no reason for any committees
or meetings to decide how a different implementation is going to work.
In this particular case, Jack2 started out (as Stephane has described)
as a sort of experiment - how would SMP support work, could we do
click-free graph changes, would a C++ implementation be easier to
manage, etc. etc. In that context, its not appropriate for anyone
who's not actually working on it to be trying to make decisions about
internal design. Lots of people, including myself, had input into the
design and evolution of Jack2. Pretending otherwise is ridiculous.
Jack1, Jack2 (and even the not-quite-born tschak) all implement 99.83%
of the same API. Beyond that, how they work internally is the business
of their implementors and maintainers. If someone has an opinion about
it, they are free to take it up with the implementors and maintainers.
If they feel strongly enough about it, and they don't feel that the
implementors/maintainers are doing things in the right way, they can
fork or reimplement (this clearly doesn't happen much). I must say that I still don't have a clear
understanding of why this
happened. I still don't understand the sentence "Like Torben, there
are some design decisions there that I have questions about." and I
think explaining it in more details would really help.
Regards,
\r
It would be good if an '(mini) JACK
Conference' will be organized, where
JACK developers can speak each other face to face, code to code. And
share future vision, coding vision etc. IRC and mailinglists are great,
but not always the good method for communication.
Traditionally, this would be done at the Linux Audio Conference, which
I will, alas, be unable to attend this year. That doesn't stop other
people from meeting on these issues, but my impression is that we have
all become somewhat tired of struggling with the situation and instead
have been trying to find ways to allow the status quo to continue, but
better.
8:03 p.m.
New subject: [Jack-Devel] distros migrating to JACK2?
On Sun, Apr 18, 2010 at 10:21:06PM +0200, rosea.grammostola wrote:
On Sun, 2010-04-18 at 08:31 -0400, Paul Davis wrote:
its sort of my fault. i dont feel comfortable with the jack2 codebase.
this partly has to do with the style used.
the important thing however is the class hirarchy.
i find it unacceptable that i need to add a method to 5 classes to
implement some new api function for example.
i end up writing a lot of boilerplate code i find useless, and
i really hate to write useless code.
many of the other design decisions dont make sense to me, and i am
having a pretty hard time finding the relevant code fragments.
(who would search for the servers event processing loop in the platform
specific Communication channels ?)
this makes hacking jack2 a rather unpleasant experience for me.
since nobody pays me to work on jack and i am doing this for fun.
i minimize hacking jack2.
yet since nobody will do the jack2 session patch i am forced again to
work on jack2.
i wrote tschack because i wanted to try out a different approach to the
functionality in jack2. and to understand how a parallel jack works.
now some people who had bad experience with jack2 tried it, and it works
for them.
so there is no reason to hide tschack.
i dont see a reason to try to get stephane to reconsider his design
decisions. it were his decisions, and he seems to be happy with them.
my way is to start from scratch with a new c++ implementation.
for me this has the benefit of not using CamelCase. which will never get
removed from jack2 (why should it? stephane likes it)
regarding distros move to jack2 i think its the right thing.
i just made sure, that it will be possible to install an alternative
jack implementation.
iE people had a pretty hard time installing jack2 on debian.
if they had just moved to jack2 without making libjack a virtual
package, people would have problems instlling jack1 or tschack.
now the packagers dont really want to package N versions of jack, since
they would need to test all combinations of apps and jacks.
but as long as sombody is able to provide jack1 and tschack .debs it
will be fine.
packagers are happy, and other people are able to install some
alternative.
On Sun, Apr 18, 2010 at 5:16 AM,
rosea.grammostola
<rosea.grammostola(a)gmail.com> wrote:
This could all be true, but that's not the point I was talking about.
JACK2 was planned as successor of JACK1. But at some point that changed,
that's all ok, not the point here. But isn't it odd that this isn't
clearly communicated with the JACK2 maintainer, why this is happened?
That was raising questions here about the communication within the
(highly appreciated) JACK project. It's pretty odd that you guys didn't
discuss this clearly with each
other. It seems that people have an opinion about something, but only
share this with people who have the same opinion and not with the one
who himself or his code is subject of 'critique'. This is bad
communication and bad team management.
oh god. you clearly don't understand ANYTHING about how open source
development works.
there was constant discussion about all of this. But Stephane doesn't
own JACK, I don't own JACK, Torben doesn't own JACK, Jack O'Quinn
doesn't own JACK. When someone works on their own implementation of
JACK, they are free to make their own decisions about how things are
done. Maybe their ideas will be better (or worse, or about the same)
as any existing implementation, and because of this, its important to
allow them to take shape as they see fit. Clearly, providing useful
feedback and ideas is great, but there's no reason for any committees
or meetings to decide how a different implementation is going to work.
In this particular case, Jack2 started out (as Stephane has described)
as a sort of experiment - how would SMP support work, could we do
click-free graph changes, would a C++ implementation be easier to
manage, etc. etc. In that context, its not appropriate for anyone
who's not actually working on it to be trying to make decisions about
internal design. Lots of people, including myself, had input into the
design and evolution of Jack2. Pretending otherwise is ridiculous.
Jack1, Jack2 (and even the not-quite-born tschak) all implement 99.83%
of the same API. Beyond that, how they work internally is the business
of their implementors and maintainers. If someone has an opinion about
it, they are free to take it up with the implementors and maintainers.
If they feel strongly enough about it, and they don't feel that the
implementors/maintainers are doing things in the right way, they can
fork or reimplement (this clearly doesn't happen much).
quote=Stephane
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
--
torben Hohn
I must say that I still don't have a clear
understanding of why this
happened. I still don't understand the sentence "Like Torben, there
are some design decisions there that I have questions about." and I
think explaining it in more details would really help.
Regards,
\r
It would be good if an '(mini) JACK
Conference' will be organized, where
JACK developers can speak each other face to face, code to code. And
share future vision, coding vision etc. IRC and mailinglists are great,
but not always the good method for communication.
Traditionally, this would be done at the Linux Audio Conference, which
I will, alas, be unable to attend this year. That doesn't stop other
people from meeting on these issues, but my impression is that we have
all become somewhat tired of struggling with the situation and instead
have been trying to find ways to allow the status quo to continue, but
better.
19 Apr
19 Apr
4:07 a.m.
New subject: [Jack-Devel] distros migrating to JACK2?
This could all be true, but that's not the point I was talking about.
JACK2 was planned as successor of JACK1. But at some point that changed,
that's all ok, not the point here. But isn't it odd that this isn't
clearly communicated with the JACK2 maintainer, why this is happened?
That was raising questions here about the communication within the
(highly appreciated) JACK project.
its sort of my fault. i dont feel comfortable with the jack2 codebase.
this partly has to do with the style used.
the important thing however is the class hirarchy.
i find it unacceptable that i need to add a method to 5 classes to
implement some new api function for example. i end up writing a lot of boilerplate code i find
useless, and
i really hate to write useless code.
many of the other design decisions dont make sense to me,
Like what?
and i am
having a pretty hard time finding the relevant code fragments.
(who would search for the servers event processing loop in the platform
specific Communication channels ?)
Because on OSX the "event processing loop" is handled in the Mig generated RPC
code , so the "event processing loop" moves in the "platform specific
communication channels".
If OSX specific stuff is removed, then the "event processing loop" may go in a
more generic part the code yes.
this makes hacking jack2 a rather unpleasant experience for me.
since nobody pays me to work on jack and i am doing this for fun.
i minimize hacking jack2.
yet since nobody will do the jack2 session patch i am forced again to
work on jack2.
i wrote tschack because i wanted to try out a different approach to the
functionality in jack2. and to understand how a parallel jack works.
now some people who had bad experience with jack2 tried it, and it works
for them.
so there is no reason to hide tschack.
i dont see a reason to try to get stephane to reconsider his design
decisions. it were his decisions, and he seems to be happy with them.
my way is to start from scratch with a new c++ implementation.
A Linux specific version ? (so would be simpler yes) or a multi-platform version?
for me this has the benefit of not using CamelCase.
which will never get
removed from jack2 (why should it? stephane likes it)
So naming convention (class, class fields...) yes?
regarding distros move to jack2 i think its the right thing.
i just made sure, that it will be possible to install an alternative
jack implementation.
iE people had a pretty hard time installing jack2 on debian.
if they had just moved to jack2 without making libjack a virtual
package, people would have problems instlling jack1 or tschack.
now the packagers dont really want to package N versions of jack, since
they would need to test all combinations of apps and jacks.
but as long as sombody is able to provide jack1 and tschack .debs it
will be fine.
packagers are happy, and other people are able to install some
alternative.
I don't see (yet) any of the proposed arguments as "fundamental" critic of
the jack2 design. Some improvements are certainly possible, like trying to remove this OSX
specific server//client communication code, and we could agree on that. I don't think
starting a new c++ implementation will improve the situation. If a Linux specific version
only is developed, then we move a step back yes?. But OTOH nobody is never forced to do
anything in OSS.
Stéphane
9:45 a.m.
New subject: [Jack-Devel] distros migrating to JACK2?
i wrote tschack because i wanted to try out a
different approach to the
functionality in jack2. and to understand how a parallel jack works.
now some people who had bad experience with jack2 tried it, and it works
for them.
so there is no reason to hide tschack.
On this specific point, what makes more sense : try to understand and fix the problems
for "some people who had bad experience with jack2" ? or wait for a C++
rewritten jack1 ???
Stéphane
18 Apr
18 Apr
8:34 p.m.
New subject: [Jack-Devel] distros migrating to JACK2?
On Sun, Apr 18, 2010 at 4:21 PM, rosea.grammostola
<rosea.grammostola(a)gmail.com> wrote:
This could all be true, but that's not the point I
was talking about.
JACK2 was planned as successor of JACK1. But at some point that changed,
No, Jack2 (then jackdmp) was not planned as a successor of Jack1. It
was initially planned as an alternate implementation and a playground
to try out some ideas, mostly because Stephane didn't feel that it was
going to be easy to do that with the existing C codebase of Jack (and
I think that everybody else agreed with him about that). *Later*, we
agreed that Jack2 would become the successor of Jack1.
19 Apr
19 Apr
4:31 a.m.
New subject: [Jack-Devel] distros migrating to JACK2?
Le 19 avr. 2010 à 00:34, Paul Davis a écrit :
On Sun, Apr 18, 2010 at 4:21 PM, rosea.grammostola
<rosea.grammostola(a)gmail.com> wrote:
It was jackdmp *then* jack2 ((-:
This could all be true, but that's not the
point I was talking about.
JACK2 was planned as successor of JACK1. But at some point that changed,
No, Jack2 (then jackdmp) was not planned as a successor of Jack1. It
was initially planned as an alternate implementation and a playground
to try out some ideas, mostly because Stephane didn't feel that it was
going to be easy to do that with the existing C codebase of Jack (and
I think that everybody else agreed with him about that).
The reasons for a new code base were multiple:
- after the initial "jack1on OSX work" , I has a good understanding of the C
code, enough to think that going for the SMP *and* multi-platform support would be a
nightmare... or would require huge rework, that was done in the C+ version indeed.
- they were some stability problems on OSX (like random crashes..) I could not find and
fix. The kind of crash I usually describe as coming from "too complex and non
understandable code"
- they were some subtle bugs in the C code (like memory leaks in jack port management
because of this double sever side/client side management, some shared memory issue.. some
more i don't remember right now)
The C++ code base then has been improved by a lot of people, Michael Voigt did a lot of
work to improve multi-platform support (for his L4/drop port), Tim Blechmann simplified
the C++ class hierarchy and did optimization everywhere, Nedko added the control API and
D-Bus support in *pure* C with his own naming conversion (so this can even be done..),
Devin Anderson added some MIDI related code.... etc...
*Later*, we
agreed that Jack2 would become the successor of Jack1.
Stephane
10:31 a.m.
New subject: [Jack-Devel] distros migrating to JACK2?
On Monday 19 April 2010 02:31:15 Stéphane Letz wrote:
This may not be not a misunderstanding of the timeline, rather just a perhaps
an unfamiliar turn of phrase.
Let's say you have Mary Smith who you knew as a child and then moved away and
you lost touch. She got married to Brad Jones and is now Mary Jones.
Someone could say:
Mary Jones [Jack2] (then Mary Smith [jackdmp]) wasn not ....
So... Jack2 (which was known as jackdmp at the time) was not planned...
Jack2 (which was then known as jackdmp) was not planned...
Jack2 (then known as jackdmp) was not planned...
Jack2 (then jackdmp) was not planned...
Something like that. Hope it helps. English sure is a world of fun. (I have an
8 year old and am going through it again.)
Food.
Mood.
Wood.
Blood.
Stood.
What does oo sound like again?
all the best,
drew
No, Jack2
(then jackdmp) was not planned as a successor of Jack1.
It was jackdmp *then* jack2 ((-: 
noon
New subject: [Jack-Devel] distros migrating to JACK2?
drew Roberts wrote:
On Monday 19 April 2010 02:31:15 Stéphane Letz wrote:
This may not be not a misunderstanding of the timeline, rather just a perhaps
an unfamiliar turn of phrase.
Let's say you have Mary Smith who you knew as a child and then moved away and
you lost touch. She got married to Brad Jones and is now Mary Jones.
Someone could say:
Mary Jones [Jack2] (then Mary Smith [jackdmp]) wasn not ....
So... Jack2 (which was known as jackdmp at the time) was not planned...
Jack2 (which was then known as jackdmp) was not planned...
Jack2 (then known as jackdmp) was not planned...
Jack2 (then jackdmp) was not planned...
Something like that. Hope it helps. English sure is a world of fun. (I have an
8 year old and am going through it again.)
Food.
Mood.
Wood.
Blood.
Stood.
What does oo sound like again?
all the best,
drew
Hahaha :D
native English speaking people should empathize with the rest of the
community, e.g. better than the usage of "then" would have been "back
then" or "before then". Btw. my English is terrible broken, but I did
understand - still do understand - the "then" correctly, because I
wasn't emotional involved in this specific part of the discussion.
Language is a funny virus.
On German, my native language, I had flame wars when writing, but when
having phone calls with the same people everything was fine again,
because it just were misinterpretations of the way we used or language.
Not least because I'm a dyslexic, but because the written word in all is
problematic, I love the language called music.
Off topic greets,
Ralf
No, Jack2
(then jackdmp) was not planned as a successor of Jack1.
It was jackdmp *then* jack2 ((-:
5365
days inactive
5367
days old
linux-audio-dev@lists.linuxaudio.org
11 comments
6 participants
participants (6)
-
drew Roberts -
Paul Davis -
Ralf Mardorf -
rosea.grammostola -
Stéphane LETZ -
torbenh