21 Jan
2007
21 Jan
'07
7:41 a.m.
As much more of a music maker than a developer, I'm not able to evaluate
whether this post from a current thread on Slashdot is a valid criticism
of JACK:
http://ask.slashdot.org/comments.pl?sid=217898&cid=17700570
I'm curious what people here think?
-c
--
Chris Metzler cmetzler(a)speakeasy.snip-me.net
(remove "snip-me." to email)
"As a child I understood how to give; I have forgotten this grace since I
have become civilized." - Chief Luther Standing Bear
21 Jan
21 Jan
8:26 a.m.
On Sun, 2007-01-21 at 07:46 -0500, Chris Metzler wrote:
As much more of a music maker than a developer,
I'm not able to evaluate
whether this post from a current thread on Slashdot is a valid criticism
of JACK:
http://ask.slashdot.org/comments.pl?sid=217898&cid=17700570
I'm curious what people here think?
Isn't the --nperiods option used to get multiple JACK periods per
hardware buffer?
--ll
9:01 a.m.
On 1/21/07, Lars Luthman <lars.luthman(a)gmail.com> wrote:
On Sun, 2007-01-21 at 07:46 -0500, Chris Metzler
wrote:
> As much more of a music maker than a developer, I'm not able to evaluate
> whether this post from a current thread on Slashdot is a valid criticism
> of JACK:
>
> http://ask.slashdot.org/comments.pl?sid=217898&cid=17700570
Looks like a troll.
If he knows a better solution, where is it?
There's no way to have big processing period and low-latency at the same time.
If you are processing your audio in big chunks, then there's just no
sense to use short hw-buffers (if only to stress irq subsystem).
So, this post is BS.
The only thing that may be useful, is to have cients with different
period sizes in the same graph. But it's quite hard to implement,
though possible.
Regards,
Dmitry.
22 Jan
22 Jan
6:59 a.m.
Le Sun, 21 Jan 2007 14:15:16 +0100,
Lars Luthman <lars.luthman(a)gmail.com> a écrit :
On Sun, 2007-01-21 at 07:46 -0500, Chris Metzler
wrote:
> As much more of a music maker than a developer, I'm not able to
> evaluate whether this post from a current thread on Slashdot is a
> valid criticism of JACK:
>
> http://ask.slashdot.org/comments.pl?sid=217898&cid=17700570
Here's what I replied to the guy. Unfortunately the /. system
seems to have some problem with posting the reply.
You *can* still get Jack to work perfectly with 2ms
latency (and hundreds of people do), but only with extreme care
about what applications you're running and with the use of fast
top-end audio hardware, no Internet access, and no random
commands invoked from xterms.
I run a lot of Linux audio apps using a low-cost M-Audio 1010LT
card on a X86_64 AMD X2 machine with 4 GB of RAM. I run audio
sequences and Ardour recordings while the windowm manager is
Beryl and it shows the water ripples and snow effects on the
screen and there's an active internet connection. Never heard a
missed note or beat and in fact, I still do not know what xruns
are.
Although 4GB is not that common nowadays, the X86_64 machines, as
well as the dual core CPUs, are becoming cheap.
I think that someone who can fly in a musician from the other
side of the globe shouldn't really be running a cheap setup, be
it Linux or Windows or Mac.
Al
7:09 a.m.
Le Mon, 22 Jan 2007 07:06:24 -0500,
lanas <lanas(a)securenet.net> a écrit :
Although 4GB is not that common nowadays, the X86_64
machines, as
well as the dual core CPUs, are becoming cheap.
Damn, I forgot to mention that I run Fedora Core 6 with the distro
kernel, unmodified.
Al
7:43 a.m.
its clear from this thread that there simply aren't enough
linux-audio pimps making the rounds and hyping the scene. hands up
who has been making tons of music with linux lately? it sure would
be nice to hear a lot more from those folks, and maybe even be able
to push it further out into the mainstream as examples of doing it
right with linux-audio ..
--
;
Jay Vaughan
9:06 a.m.
Jay Vaughan wrote:
its clear from this thread that there simply
aren't enough linux-audio
pimps making the rounds and hyping the scene. hands up who has been
making tons of music with linux lately? it sure would be nice to hear
a lot more from those folks, and maybe even be able to push it further
out into the mainstream as examples of doing it right with linux-audio ..
Hi Jay,
While I agree, I have to wonder what else we can do. The LAM site holds
a fair amount of music made with Linux tools, and not too long ago I
stocked the Internet Archive with a batch of recently-composed pieces. I
have a few other sites dedicated to my music, but perhaps you can
suggest ways of making all this stuff more visible ?
Btw, I did continue monitoring the traffic for the /. thread re: music
sequencing software for Linux. Same old same old. Paul got some good
response, but overall I'd say the thread was a waste of everybody's
time. The ignorance on /. regarding Linux audio development is simply
too deep, and I see little indication that posters there want to do
little but echo the same old mantras.
Has any user on this list come here by being persuaded by what he or she
has read on Slashdot ?
Best,
dp
9:32 a.m.
While I agree, I have to wonder what else we can do.
The LAM site
holds a fair amount of music made with Linux tools, and not too long
ago I stocked the Internet Archive with a batch of recently-composed
pieces. I have a few other sites dedicated to my music, but perhaps
you can suggest ways of making all this stuff more visible ?
I think there should be a more regular call for details about what
people are up to with Linux audio tools .. like, every week, someone
ought to ask "what have you guys been up to", and start keeping a bit
of a blog on the subject.
Sure, the LAM site contains such details, but I think it needs update
and maintenance by the core Linux-audio users and producers more than
just the guys who are trying to hold it all together.
Perhaps we could arrange a "Linux-only" audio meet, some sort of
conference a la the synth-diy UK meets, where folks come together for
linux-only audio production in a friendly conference arrangement?
Btw, I did continue monitoring the traffic for the /.
thread re:
music sequencing software for Linux. Same old same old. Paul got
some good response, but overall I'd say the thread was a waste of
everybody's time.
Only for those concurrently watching the thread; but for sure, its
going to be helpful to future generations of google-search'ers
looking for details on such issues as were discussed, and in my
opinion its good to have beefed up the counter-argument in that
circumstance. Imagine that thread never got a response; without the
real details being discussed, the google'ification of the web results
in a stagnant conclusion..
The ignorance on /. regarding Linux audio
development is simply too deep, and I see little indication that
posters there want to do little but echo the same old mantras.
Maybe we need a few "Linux-only audio producer" web-lables actively
pimping the end results in order to make this passion felt by otheres
..
Has any user on this list come here by being persuaded
by what he or
she has read on Slashdot ?
I've been on /. since it was chips&dips, I know how lunatic it can
get .. but alas, I also am aware of the un-noticed influence it has
as a result of google.
--
;
Jay Vaughan
11:26 a.m.
I think there should be a more regular call for
details about what
people are up to with Linux audio tools .. like, every week, someone
ought to ask "what have you guys been up to", and start keeping a bit
of a blog on the subject.
Except, when you have such blogs scattered all across the internet, it does
not do much good.
Best wishes,
Ico
9:46 a.m.
måndag 22 januari 2007 15:04 skrev Dave Phillips:
Btw, I did continue monitoring the traffic for the /.
thread re: music
sequencing software for Linux. Same old same old. Paul got some good
response, but overall I'd say the thread was a waste of everybody's
time. The ignorance on /. regarding Linux audio development is simply
too deep, and I see little indication that posters there want to do
little but echo the same old mantras.
To get visibility for LA[UD] the debate should be started by the LA[UD] side.
Not the contrary. The problem is that people don't bother to read more than 1
or 2 comments. At least I do that and I concider myself sort of normal. I
should say that I got tired of /. a few years ago so I'm not that up to date
whats happening on there but I did read this article that we are talking
about.
So. Receipt for small success. Schedule a few articles on /. Especially
articles from the people who develop software and people who use them. Not
the debaters who debate for it's own sake.
Has any user on this list come here by being persuaded
by what he or she
has read on Slashdot ?
If you aske me, that is a definite no.
regards,
/bengan
1:48 p.m.
On 1/22/07, Bengt Gördén <bengan(a)kthnoc.net> wrote:
At least I do that and I concider myself sort of
normal. I
should say that I got tired of /. a few years ago so I'm not that up to date
whats happening on there but I did read this article that we are talking
about.
It's basically an Apple fanboy site these days.
Lee
9:42 a.m.
New subject: Advocacy (was: Re: [linux-audio-user] This criticism of jackd valid?)
its clear from this thread that there simply
aren't enough
linux-audio pimps making the rounds and hyping the scene. hands up
who has been making tons of music with linux lately? it sure would
be nice to hear a lot more from those folks, and maybe even be able
to push it further out into the mainstream as examples of doing it
right with linux-audio ..
We have a group here in London UK set up to do that in our own small way:
http://www.pawfal.org/openlab/
Basically it's purpose is to put on events, performances and workshops
showing people what can be done with free software, by actually getting
out and doing it.
It does seem (from anecdotal evidence) to work in getting people to go
home and give it a try. I'd recommend this as a down to earth way of
approaching advocacy.
There are related organisations doing similar work such as goto10:
http://www.goto10.org
cheers,
dave
12:37 p.m.
Hi,
I have been making music with linux *only* for the past 6-7 years.
Maybe 8... Well, granted, other things get involved, too, like
voices, acoustic instruments and such, but the linux computer is used
for FX, sampling and whatnot.
I have also been teaching workshops to local artists (Canada - in
Montreal and Ottawa, too), usually on linux and usually Pd.
What I notice is that people are usually constantly busy with various
projects and rather reluctant to drop all the tools they know and own
completely to concentrate only on linux-based production. The
curiosity is usually there but a leap from, say MacOSX to linux seems
still too much to handle for those who just want to boot a computer
and run (not to mention having to change habits related to use of this
or that software for years).
I notice the same issues in office work. I'm trying to push linux in
my dayjob environment but so far without much real success other than
sparking a little curiosity.
As for mainstream, well, my music is not mainstream enough to push it
through such channels. I suppose when people come to talk to me after
a show they associate obscure music with obscure operating system, so
sorry for blowing it for you :) As per Marshall MacLuhan, "Medium is
the message." Perhaps it is so... But it sould work equally well
for those who are into the mainstream.
./MiS
http://www.creazone.ca
Jay Vaughan <jayv(a)synth.net> writes:
its clear from this thread that there simply
aren't enough linux-audio
pimps making the rounds and hyping the scene. hands up who has been
making tons of music with linux lately? it sure would be nice to hear
a lot more from those folks, and maybe even be able to push it further
out into the mainstream as examples of doing it right with linux-audio
..
--
;
Jay Vaughan
12:50 p.m.
On 22 Jan 2007 12:36:57 -0500, Michal Seta <mis(a)artengine.ca> wrote:
Jay Vaughan <jayv(a)synth.net> writes:
> its clear from this thread that there simply aren't enough linux-audio
> pimps making the rounds and hyping the scene. hands up who has been
> making tons of music with linux lately? it sure would be nice to hear
> a lot more from those folks, and maybe even be able to push it further
> out into the mainstream as examples of doing it right with linux-audio
Raises hand...
I use Linux exclusively for sequencing and recording (I have a second
machine running XP that I use exclusively for plugins only, almost
like a Receptor or Plugzilla kind of thing) ... my studio isn't
'mainstream' by any stretch of the imagination, but I am starting to
record people other than myself, now that I have two isolation booths
in my studio now and am aiming at going semi-pro.
In fact, yesterday, I spent quite a few hours recording a band for
their 5 song demo... 8 tracks recording all at once (via Delta1010)
and not a single xrun in all that time. In fact, I don't remember the
last time I got an xrun... I can't even say my DAW is exactly cutting
edge, just a 1.4GHz Athlon Gentoo machine with 512M of RAM (and
firewire drives).
-- Brett
------------------------------------------------------------
"In the rhythm of music a secret is hidden;
If I were to divulge it, it would overturn the world."
-- Jelaleddin Rumi
21 Jan
21 Jan
9:12 a.m.
Chris Metzler wrote:
As much more of a music maker than a developer, I'm
not able to evaluate
whether this post from a current thread on Slashdot is a valid criticism
of JACK:
http://ask.slashdot.org/comments.pl?sid=217898&cid=17700570
I'm curious what people here think?
<Achtung! Grumpy Sunday morning rant!>
AFAIC, any mention of Linux audio on /. is a troll.
I wrote a reply to the original post but didn't send it (see below).
"Slashdot + Linux audio" is a non-starter. I couldn't even get the
service to announce the Linux Audio Conference decently (two years ago).
I'm still astonished by the utter lack of support for Linux audio from
within the Linux community itself. It's as though it never occurs to
users that their precious music is made with non-free tools on non-free
systems. I guess as long as they can play it on a free platform, it's
all okay.
Slashdot is not a good place to go for accurate information. Nice for
some things, sucks for others. Linux audio is one of its others.
The Coward writes :
"You *can* still get Jack to work perfectly with 2ms latency (and
hundreds of people do), but only with extreme care about what
applications you're running and with the use of fast top-end audio
hardware, no Internet access, and no random commands invoked from xterms."
Right, and pros routinely use less powerful hardware and are thoughtless
about their software selection, while they surf the Web and run random
commands during paid sessions. WTF?!
That post is filled with contradictions. This is ripe :
"In contrast, the thousands of other people running Jack with
realtime-lsm on their general-purpose Linux box still get the occasional
XRUN at the best of times despite running with a load average of 0.01,
and for professional work, even 1 XRUN per week is 1 XRUN too many."
Does anyone else notice how adroitly he confutes normal desktop use with
pro audio ? He acknowledges it's possible to get sub 2ms latency for pro
work, but normal users typically get xruns from general-purpose (not
pro-audio) systems, but pro-audio people (who we can safely assume are
*not* using unmodified systems) can't tolerate even a single xrun.
I'm sure Paul and the JACK crew will find this statement interesting:
"it requires *HARD* realtime to work"
His numbers are interestingly suspect:
"hundreds of people do"
"thousands of other people running Jack"
"a million Jack clients"
Even allowing for hyperbole the article reads like it's written by a
troll. According to his title, Jack is broken, but in his discourse he
makes it clear that people can and do successfully run it. So is this a
troll or just poor reasoning and writing ? You decide.
Here's my unposted response:
"I'm curius to read your explanation for the following scenario:
Yesterday I ran ImproSculpt, a massive Csound + FLTK program with
extensive GUI controls, for more than three hours, running under JACK
(set for sub 6ms latency), processing multiple input streams in
realtime, with not one xrun. I surfed the Web and wrote an article while
ImproSculpt did its thing. I do similar stuff with Ardour. Your
assertions don't hold up here at Studio Dave.
Machine is an AMD64 3200. Yes, it's fast, but none of my Mac and Win
audio buddies use anything less. You are bound to use power hardware if
you intend to do serious audio, as I'm sure you know. Btw, Linux distro
is 64Studio."
Also btw: None of my Windows-based music friends like the OS at all.
Some still run Cubase on Win98, citing better performance than with XP.
Those fellows have absolutely 0 intention to purchase Vista for their
music purposes. My friends running Pro Tools *never* run anything else
during a session with that software. They are also unhappy about being
so completely locked into a commercial scheme. Nevertheless, their
innate conservatism and their heavy investment into the Win/Mac world
saps their incentive to step out of it.
Anyone else remember the days when Mozilla received the same treatment
from naysayers ? Anyone using Firefox these days ?
I need more coffee.
</rant>
Best,
dp
9:55 a.m.
On 1/21/07, Dave Phillips <dlphillips(a)woh.rr.com> wrote:
Here's my unposted response:
[snip]
I need more coffee.
</rant>
Great answer, Dave.
Thanks for sharing it with us. Don't waste it on that idiot.
"Never try to teach a pig to sing -- it wastes your time and annoys the pig."
--
joq
2:28 p.m.
On Sun, 2007-01-21 at 08:45 -0600, Jack O'Quin wrote:
On 1/21/07, Dave Phillips
<dlphillips(a)woh.rr.com> wrote:
Especially when I'm happy to waste my time for you:
http://ask.slashdot.org/comments.pl?sid=217898&threshold=2&comments…
Here's my unposted response:
[snip]
I need more coffee.
</rant>
Great answer, Dave.
Thanks for sharing it with us. Don't waste it on that idiot. 
4:21 p.m.
Hi Paul
I have a question about something you say in your slashdot post:
"The overhead of calling the graph associated with the data flow for
the frames is not insignificant, even on contemporary processors.
Therefore, calling the graph the minimum number of times is of some
significance, significance that only grows as the latency is reduced.
Because of this, all existing designs, including ASIO and CoreAudio
(with the proviso that CoreAudio is *not* driven by the interrupt from
the audio interface) call the graph only once for every hardware buffer
segment/period/whatever."
Do you have some numbers to show how relevant this overhead actually is?
I mean, if I use a specific internal buffer size (say 128 samples),
independend of the system buffer size, would that really be noticable?
I can think of some situations where this would be preferable. For
example, if you have many points in your callgraph where a fixed buffer
size is required (say some FFT's). Rather than doing buffering at all
these points, it seems to make more sense to do the whole callgraph
with that buffer size. I hope I make myself clear...
I did some experiments, and did not notice any significant difference
using different internal buffer sizes for my call graph. I am talking
about a call graph within a single application, and maybe you were
talking about a call graph with context switches?
maarten
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
22 Jan
22 Jan
11:03 a.m.
On Sun, 2007-01-21 at 22:21 +0100, Maarten de Boer wrote:
Hi Paul
I have a question about something you say in your slashdot post:
"The overhead of calling the graph associated with the data flow for
the frames is not insignificant, even on contemporary processors.
Therefore, calling the graph the minimum number of times is of some
significance, significance that only grows as the latency is reduced.
Because of this, all existing designs, including ASIO and CoreAudio
(with the proviso that CoreAudio is *not* driven by the interrupt from
the audio interface) call the graph only once for every hardware buffer
segment/period/whatever."
Do you have some numbers to show how relevant this overhead actually is?
I mean, if I use a specific internal buffer size (say 128 samples),
independend of the system buffer size, would that really be noticable?
I can think of some situations where this would be preferable. For
example, if you have many points in your callgraph where a fixed buffer
size is required (say some FFT's). Rather than doing buffering at all
these points, it seems to make more sense to do the whole callgraph
with that buffer size. I hope I make myself clear...
I did some experiments, and did not notice any significant difference
using different internal buffer sizes for my call graph. I am talking
about a call graph within a single application, and maybe you were
talking about a call graph with context switches?
both, really.
if you get down to very, very small buffer sizes (say, 4), the overhead
of making the function calls gets to be a significant fraction of the
total time spent processing the audio. this is partly why running JACK
with low buffer sizes shows the "DSP load" as significantly higher, even
if almost nothing is happening. you will only see this effect with deep
call trees. inside a single, simple app, the effect is probably hard to
detect.
but yes, because of context switches between clients, it becomes even
more true in JACK. that effect is measurable and isn't tiny.
--p
23 Jan
23 Jan
11:18 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Mon, Jan 22, 2007 at 10:58:10AM -0500, Paul Davis wrote:
On Sun, 2007-01-21 at 22:21 +0100, Maarten de Boer
wrote:
By coincidence, I was just experimenting with this a few hours ago, before reading this.
I'm puzzled-- and a bit worried-- by the difference between the high CPU load with
small -p values vs. low CPU load with high -p values.
It turns out it makes a significant difference on my system. If I load up a couple
fluidsynth instances, ardour, hydrogen, and rosegarden, and then jack-rack, running a
single processing chain of CAPS Tube Amp IV, CAPS Cabinet II, TAP Autopanner, and CAPS
Plate 2x2 Reverb (this is my Rhodes piano sound), then my CPU usage goes up to 50% with -p
64 -n 2, and absolutely nothing actually being played. With -p 1024 -n 3 the CPU usage
was about 8%. When my system was working, I was using -p 256 -n 3, which was passable for
most purposes although a little too laggy.
This is a Mac Mini Intel Core Duo 1.66Mhz, 2GB RAM, and FA-66 audio interface with
FreeBOB, running 2.6.19.1-rt15 and jack 0.101.1-2.
It looks like it might another system tuning complication now: if I lower my latency, I
will get Xruns and bad crackles due to too much CPU usage.
- -ken
Hi Paul
I have a question about something you say in your slashdot post:
"The overhead of calling the graph associated with the data flow for
the frames is not insignificant, even on contemporary processors.
Therefore, calling the graph the minimum number of times is of some
significance, significance that only grows as the latency is reduced.
Because of this, all existing designs, including ASIO and CoreAudio
(with the proviso that CoreAudio is *not* driven by the interrupt from
the audio interface) call the graph only once for every hardware buffer
segment/period/whatever."
Do you have some numbers to show how relevant this overhead actually is?
I mean, if I use a specific internal buffer size (say 128 samples),
independend of the system buffer size, would that really be noticable?
I can think of some situations where this would be preferable. For
example, if you have many points in your callgraph where a fixed buffer
size is required (say some FFT's). Rather than doing buffering at all
these points, it seems to make more sense to do the whole callgraph
with that buffer size. I hope I make myself clear...
I did some experiments, and did not notice any significant difference
using different internal buffer sizes for my call graph. I am talking
about a call graph within a single application, and maybe you were
talking about a call graph with context switches?
both, really.
if you get down to very, very small buffer sizes (say, 4), the overhead
of making the function calls gets to be a significant fraction of the
total time spent processing the audio. this is partly why running JACK
with low buffer sizes shows the "DSP load" as significantly higher, even
if almost nothing is happening. you will only see this effect with deep
call trees. inside a single, simple app, the effect is probably hard to
detect.
but yes, because of context switches between clients, it becomes even
more true in JACK. that effect is measurable and isn't tiny.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFFtt24e8HF+6xeOIcRAgJPAKD1rPtwn/BoSp9T5MDul/st7GiH8QCg5oDr
2LIoj4qWQy5UGeM47Qc6cuo=
=ARq+
-----END PGP SIGNATURE-----
9:57 a.m.
On Sun, 21 Jan 2007 09:13:20 -0500
Dave Phillips <dlphillips(a)woh.rr.com> wrote:
<Achtung! Grumpy Sunday morning rant!>
A good time for it, too. I started looking at that thread on /. but
didn't care to raise my blood pressure that much.
Having just tuned my son's system so that he can run Ardour and Hydrogen
and record without crashing, I can attest that yes, it takes some work
even with a music-oriented distro (in this case, Planet CCRMA), but it's
less voodoo than what a lot of Windows people have to go through to get
a stable recording setup. His implication that other systems handle this
routinely but that Jack is fundamentally broken speaks to his trollishness.
--
======================================================================
Joe Hartley - UNIX/network Consultant - jh(a)brainiac.com
Without deviation from the norm, "progress" is not possible. - FZappa
12:38 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Chris Metzler schrieb:
http://ask.slashdot.org/comments.pl?sid=217898&cid=17700570
I'm curious what people here think?
I think the poster lacks experience with jackd - he appears to be
ignorant, what an xrun is in the real world, I posted this reply on
slashdot:
I can run jackd with ardour at 2.3ms stable and reliable on a 2.5 year
old PIV 2.8 with a 6 year old Terratec Audiocard, while having Firefox
browsing the Internet and with a Desktop Preempt Kernel.
Plus: xruns occour from time to time but only if I start up critical
Apps like Zynadd, load huge Projectfiles etc. So to be sure, that xruns
do not cause any harm, I only need to avoid starting major apps while a
Recording is running...
When I close a usual session after 3-5 h I have maybe 3-4 xruns and none
of them influenced the recorded material in any way. Even if I run into
real trouble with jackd (by playing a problematic Zynadd-Patch with too
much polyphony or the like), the session recovers usually without need
to restart, when stopping the apps, that had caused the trouble.
So I fail to get your point: what are you doing with your system and
your other-side-of-the-globe Musicians that a single xrun can destroy
your work??
best regards
Z
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFs6UF1Aecwva1SWMRAtc8AKCNjtaYkgV7KAx9Uwk49Rp3OKktwACggp8u
r1DTFUElAiNAA9H98CVpCXw=
=3KiY
-----END PGP SIGNATURE-----
2:34 p.m.
Hartmut Noack <zettberlin(a)linuxuse.de> writes:
xruns occour from time to time but only if I start up
critical Apps
like Zynadd
Not any application what so ever should cause an xrun, but you're
talking about an app that connects to the JACK graph. JACK does not
support this yet, without a possible xrun, but it's planned. JACKDMP
does this.
--
Esben Stien is b0ef@e s a
http://www. s t n m
irc://irc. b - i . e/%23contact
sip:b0ef@ e e
jid:b0ef@ n n
12:52 p.m.
Chris Metzler wrote:
As much more of a music maker than a developer,
I'm not able to evaluate
whether this post from a current thread on Slashdot is a valid criticism
of JACK:
http://ask.slashdot.org/comments.pl?sid=217898&cid=17700570
I'm curious what people here think?
-c
Ha!
So a better alternative is what then?? ARTS!?...ESD? OSS?? Maybe
"shes" a Widows user! (unnecessary slur there..I'm a windows user for
some things but it seemed as informed and appropriate as the authors theme!)
To me, within the authors own text, one of Jack's supreme capabilities
was clearly highlighted...
"You *can* still get Jack to work perfectly with 2ms latency (and
hundreds of people do)," And I am yet to see a developer of a RT
kernel who doesn't take great care in stating the possible negative
effects of running RT kernels. And if Jack sucks SO much, why has it
become the most popular audio medium for All serious Audio applications?
I know Paul and crew have sufficiently thick skin to not be dented by
this clown but it must be supremely irritating to have your work
criticized in this manner, especially when no *better* solutions are
offered up!
I give /. "anonymous coward" a big <oh brother> and a "see a
therapist
over petty jealousy issues" for this weeks show!
R
2:17 p.m.
On Sunday 21 January 2007 13:46, Chris Metzler wrote:
As much more of a music maker than a developer,
I'm not able to evaluate
whether this post from a current thread on Slashdot is a valid criticism
of JACK:
http://ask.slashdot.org/comments.pl?sid=217898&cid=17700570
I'm curious what people here think?
Actually after pondering a bit, he actually does have one valid point.
Although it is hidden below several layers of FUD and nonsense.
When using jack as an interface, the app always _has to meet the rt
contraints_ even if not interested in low latency.
Examples are media players, etc.. 0.5 secs delay don't count as long as audio
and video stay in sync.
So to make jack a little more complete and and to speed up the vanishing of
other sound servers it would be cool to have a possibility of requesting
_larger_ buffers than whatever jack is running at.
This would of course involve extra buffering and _always_ at least one period
of extra delay (kinda like the Mac OS X scheme).
Of course this functionality should be totally optional. If an app wants to
use the direct no-additional-buffering-way it should be free to do so..
What do you think? Is there some concensus that such functionality has a place
in libjack?
And how would it have to look from an API point of view..
Regards,
Flo
P.S.: and while this might be pretty straightforward for audio only jack_midi
would need soe extra work of changing the timecode stamps to correspond to
values in the now larger buffer..
--
Palimm Palimm!
http://tapas.affenbande.org
2:32 p.m.
Florian Schmidt <mista.tapas(a)gmx.net> writes:
Is there some concensus that such functionality has a
place in
libjack?
I don't understand this. Why care about the JACK buffer?. Why not just
buffer a little before?, especially with a media player.
--
Esben Stien is b0ef@e s a
http://www. s t n m
irc://irc. b - i . e/%23contact
sip:b0ef@ e e
jid:b0ef@ n n
3:35 p.m.
On Sunday 21 January 2007 22:21, Esben Stien wrote:
Florian Schmidt <mista.tapas(a)gmx.net> writes:
Well, in this case the media player has to do all the decoupling from jack,
which, while not terribly complicated, does have some pitfalls..
If you simply say: "jack, give me a 0.5 sec buffer" you can get away with
quite a bit of non-rt programming, because a 0.5 sec deadline is rather easy
to meet (maybe the need to prebuffer in the media player is gone completely).
It's about making jack easier to use for application programmers, that do no
care for quick response times (a realtime effect processor would care, as
would a softsynth, but my media player doesn't).
In the world of audio applications there are quite a few usecases where
latency is not that much of an issue. Those apps should be able to happily
coexist in a jack graph with low latency apps. And as there are quite a few
of these apps, the problem should be solved once and not by every app writer
again and again..
A blocking interface like in libjackasyn, which partly solves this problem
afaict, would be a nice feature, too..
Regards,
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
Is there some concensus that such functionality
has a place in
libjack?
I don't understand this. Why care about the JACK buffer?. Why not just
buffer a little before?, especially with a media player.
6334
days inactive
6336
days old
linux-audio-user@lists.linuxaudio.org
27 comments
21 participants
participants (21)
-
Bengt Gördén -
Brett W. McCoy -
Chris Metzler -
Dave Griffiths -
Dave Phillips -
Dmitry Baikov -
Esben Stien -
Florian Schmidt -
Hartmut Noack -
Ivica Ico Bukvic -
Jack O'Quin -
Jay Vaughan -
Joe Hartley -
Ken Restivo -
lanas -
Lars Luthman -
Lee Revell -
Maarten de Boer -
Michal Seta -
Paul Davis -
Russell Hanaghan