Discussion:
[linux-audio-dev] image problem [was Re: [Alsa-devel] help for a levelmeter]
Richard Bown
2002-10-18 09:24:00 UTC
Permalink
My opinion is that there is not enough people working on the
promotional side of ALSA and Linux Audio.
ALSA/LAD is too geeky and too die-hard techno hardcore to appeal to
anyone but geeks. IMHO music geeks are the worst type of geeks and
Linux geeks are the worst type of computer geeks. This isn't a
ALSA/LAD problem - it's a general Linux image problem. Out with the
beards and fusty academia, kernel hacking and tweakery and in with the
primary colours and the big square buttons to get The Kids into it all.
The Linux desktop is now sufficiently advanced that this should all be
possible.

I argued all this with a guy from Newsforge when we showed at Linux Expo
last week. The article has typos all over it (including my name of
course) and it's a little quote light but:

http://newsforge.com/newsforge/02/10/14/196240.shtml?tid=23

The point is that selling Linux Audio isn't just about Linux Audio -
it's about selling the whole desktop. It's about letting people know
that if they want to make music they can just get on and make music.
People shouldn't have to have a degree to install music software and to
start using it. This problem is bigger that LAD/ALSA or even AGNULA
and it crosses that distasteful line between hobbyists twiddling and
research and big business. It treads on a lot of toes.

Yes, this is a troll and not a very original one at that, but it's time
that there was a clear distinction between Linux Sound/Audio and Linux
for Music. The latter has a clearly defined marketplace, the former
doesn't.

B
Richard Bown
2002-10-18 09:29:00 UTC
Permalink
it's time that there was a clear distinction between Linux Sound/Audio
and Linux for Music. The latter has a clearly defined marketplace,
the former doesn't.
Sorry, that's not quite right. The former does too, but it's just a
little more esoteric. The point is that they are different beasts.

B
Patrick Shirkey
2002-10-18 13:56:01 UTC
Permalink
Post by Richard Bown
it's time that there was a clear distinction between Linux Sound/Audio
and Linux for Music. The latter has a clearly defined marketplace,
the former doesn't.
Sorry, that's not quite right. The former does too, but it's just a
little more esoteric. The point is that they are different beasts.
I see your point. But feel that the problem is not that it is too
difficult or ugly for the majority of people but that we have not done a
good enough job of showing how worthwhile it is to spend long hours on
figuring out how to get the stuff working.

If someone asks about why the buttons are not the cool flavour of the
month just say we have retro tastes:)

While not everyone has the time or interest or skills to become a
hacker. Most musos do spend very long hours learning how to use their
tools efficiently in any system from the guitar to ardour.

Saying that Linux Audio hackers are the worst kind of geeks is not
looking at this from the right angle. Who gives if we are or we aren't,
the Chemical brothers, and most of Oasis could easily be classified with
the same stereotype. Yet they appeal to a huge number of people mostly
because they have very good promoters working on their behalf.

I don't think we stand much chance of competing anywhere near that level
but we can surely do a lot better than the current scenario.

We are managing to accomplish some pretty amazing things round here but
AfAICT we haven't figured out how to let the right people know about it
to get the kind of boost in user numbers that will make the audio world
pay attention.

While I was in Thailand I spent most of my time pondering how to make
more impact. I have a few ideas which require serious investment of my
time and energy.

As a good friend of mine says if you want to be successful (make money)
in the music industry it's all about how much dick you can suck. Richard
are you prepared to get down? As we all know there is more than one way
to titilate.
--
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.com
Http://www.djcj.org - The Linux Audio Users guide
========================================

"Um...symbol_get and symbol_put... They're
kindof like does anyone remember like get_symbol
and put_symbol I think we used to have..."
- Rusty Russell in his talk on the module subsystem
Patrick Shirkey
2002-10-18 14:36:00 UTC
Permalink
Post by Patrick Shirkey
While I was in Thailand I spent most of my time pondering how to make
more impact. I have a few ideas which require serious investment of my
time and energy.
One of my ideas was to get a community fund for advertising in the
correct publications.

I know several people have reservations about running a non-profit
financial system around here but most of the concerns appear to have
been based on trust issues and having someone who is willing to do the
grunt work.

My suggestion is that we ask the people on this list who have proven
their trustworthyness and live in strategic countries like England,
Germany, USA, Australia to open a savings bank account which we can
deposit funds into. The account would belong to the person who opened it
so they would also be able to close it if it became a drain.

This would allow us to easily collect funds which we could use to
advertise in the correct publications on a national/regional basis.

In order to find the correct pulications I would like to canvas this
community for a list. Don't send in names yet. First we need to decide
on what qualities we are looking for.

I am willing to collate this information and write it up into an
official site and document (no prob for me these days).

So please don't flame me about this concept. Instead let me run with the
ball for a while and see if I can gather some momentum. The more help
and support I recieve from round here the better the chance is that I
will keep the wind in my sails.
--
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.com
Http://www.djcj.org - The Linux Audio Users guide
========================================

"Um...symbol_get and symbol_put... They're
kindof like does anyone remember like get_symbol
and put_symbol I think we used to have..."
- Rusty Russell in his talk on the module subsystem
Richard Bown
2002-10-18 14:57:00 UTC
Permalink
Post by Patrick Shirkey
I see your point. But feel that the problem is not that it is too
difficult or ugly for the majority of people but that we have not
done a good enough job of showing how worthwhile it is to spend long
hours on figuring out how to get the stuff working.
People want it simple - they want to buy it in a box and for it to work
and then probably to discard it or forget about it. Anything above that
is pure geekiness. This isn't to say there's not a place for geekiness
- it's just that most people don't want it.

Steve's mention of Carillon seemed pretty much on the money.

B
Steve Harris
2002-10-18 15:53:00 UTC
Permalink
Post by Richard Bown
Post by Patrick Shirkey
I see your point. But feel that the problem is not that it is too
difficult or ugly for the majority of people but that we have not
done a good enough job of showing how worthwhile it is to spend long
hours on figuring out how to get the stuff working.
People want it simple - they want to buy it in a box and for it to work
and then probably to discard it or forget about it. Anything above that
is pure geekiness. This isn't to say there's not a place for geekiness
- it's just that most people don't want it.
Yes. It has been my intention to pull in a few favours once I consider
Linux audio to be competetive with other platforms. A friend writes for
the German "Keyboards" magazine, and he has promised to cover Linux in an
indepth article when its viable, and a friend-of-a-friend-of-a... writes
for Sound On Sound (a respected UK publication) so I could proably get
him to do something.

Notice the future tense. I dont think its a good idea now, better to wait
'til we have a nice bunch of jack'd (+ alsa midi/whatever), stable,
documented apps, all playing well together than put people off with the
kind of stuff we're prepared to use.

Something I think is important is mouse launched applications - no
"app_foo -Zdr7 alsa_pcm:in_23 alsa_..." I know most of us will want to run
that this way anyway (well, I will ;), but windows and mac users aren't
going to be too impressed. Yes, I am guilty of this.

Things like jack have to be graphically wrappered or hidden too, no
scrolling text windows of xruns. The occasionaly discussed jack session
saving gizmo would be a knock dead feature.

That said, I think Patrick is right to start thinking about this now.

- Steve
Richard Bown
2002-10-18 16:52:01 UTC
Permalink
Post by Steve Harris
Notice the future tense. I dont think its a good idea now, better to
wait 'til we have a nice bunch of jack'd (+ alsa midi/whatever),
stable, documented apps, all playing well together than put people
off with the kind of stuff we're prepared to use.
Well, there's a line at which you have to decide if you're ready. Our
demo of RG last week sufficiently convinced me that we're just about
ready and a lot of the other stuff is ready too. Out of the box
ALSA/LADPSA support in SuSE and Mandrake helps a lot, JACK aside (not a
big packaging problem) what else do you need?
Post by Steve Harris
Something I think is important is mouse launched applications
We launched RG from a desktop icon all last week. It now has
Logic-style status messages on the splash screen while you're waiting
for it to start and (while they can be a little naff) touches like that
are give it a professional air if nothing else. I was also showing off
Sweep (because you have to) and Audacity (again..) and indeed RG was
launching both those too. I was recording random punters playing the
guitar, editing what they'd played, cutting it up, bunging it through a
plugin and adding a drum track etc.and then burning it onto CD. The
average person with money to spend on music tech doesn't really want to
do too much more than that. In fact if they can get that far then
they're really chuffed.

It's probably up to the bread and butter products to drive the bespoke,
studio-end products. The complete, finished solution that does both
ends sufficiently well will take a while to arrive (ardour releasing
tarballs may be a start). Perhaps you can't really apply the logic
that we see in the rest of the music-tech industry to Linux. Once
again we'll get there in the end but we'll probably end up doing it our
own way. I've was canvassing people's opinions last week and asking
them how they could see us progressing from here - it pretty much seems
that there is no One True Path, it'll take something to start it all
off. I'm pretty convinced it is going to go somewhere too.
Post by Steve Harris
That said, I think Patrick is right to start thinking about this now.
I think he's completely right - I'm not sure about this bank account
thing but I do think that now is the time to be demoing, talking up and
generally approaching people and companies about Linux music software.
I wrote us up (and mentioned a few other apps) in the latest edition of
Linux User - John at mstation.org has been very kind so far as well.
Now is the right time to be talking to people and getting the "products"
out there. If it works - why not tell people about it?

B
Steve Harris
2002-10-18 17:59:02 UTC
Permalink
Post by Richard Bown
We launched RG from a desktop icon all last week. It now has
Logic-style status messages on the splash screen while you're waiting
for it to start and (while they can be a little naff) touches like that
are give it a professional air if nothing else. I was also showing off
No, I agree. You're talking to the guy who spend an evening drawing cheezy
moving-needle meters in gimp ;)
Post by Richard Bown
plugin and adding a drum track etc.and then burning it onto CD. The
average person with money to spend on music tech doesn't really want to
do too much more than that. In fact if they can get that far then
they're really chuffed.
Maybe, but the people I'm thinking of are looking for a replacement for
thier protools+logic systems, not cubase or cakewalk.

Home users are important too, but...
Post by Richard Bown
It's probably up to the bread and butter products to drive the bespoke,
studio-end products. The complete, finished solution that does both
ends sufficiently well will take a while to arrive (ardour releasing
I'm not sure it ever will. I dont think theres that much overlap between
protools and cubase.

- Steve
Dave Griffiths
2002-10-18 16:54:01 UTC
Permalink
Post by Steve Harris
Things like jack have to be graphically wrappered or hidden too, no
scrolling text windows of xruns. The occasionaly discussed jack session
saving gizmo would be a knock dead feature.
mmm a jack controller app that you could configure (with a mouse) start jack
and check the current state, use as a central patchbay... anyone working on
such a thing?

dave
Steve Harris
2002-10-18 17:54:00 UTC
Permalink
Post by Dave Griffiths
Post by Steve Harris
Things like jack have to be graphically wrappered or hidden too, no
scrolling text windows of xruns. The occasionaly discussed jack session
saving gizmo would be a knock dead feature.
mmm a jack controller app that you could configure (with a mouse) start jack
and check the current state, use as a central patchbay... anyone working on
such a thing?
No that I know of. A postgrad here was considering it (the guy who wrote
xmms-ladspa), but I think he is busy at the moment.

- Steve
Patrick Shirkey
2002-10-18 15:03:00 UTC
Permalink
Post by Patrick Shirkey
I am willing to collate this information and write it up into an
official site and document (no prob for me these days).
http://www.djcj.org/LAU/openads/
--
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.com
Http://www.djcj.org - The Linux Audio Users guide
========================================

"Um...symbol_get and symbol_put... They're
kindof like does anyone remember like get_symbol
and put_symbol I think we used to have..."
- Rusty Russell in his talk on the module subsystem
Steve Harris
2002-10-18 10:21:00 UTC
Permalink
Post by Richard Bown
The point is that selling Linux Audio isn't just about Linux Audio -
it's about selling the whole desktop. It's about letting people know
that if they want to make music they can just get on and make music.
People shouldn't have to have a degree to install music software and to
start using it. This problem is bigger that LAD/ALSA or even AGNULA
and it crosses that distasteful line between hobbyists twiddling and
research and big business. It treads on a lot of toes.
The problem, I think, is the state of the software that many of us are
happy to use. It needs CVS this, and pl17 that, and we stop hacking when
it builds on most peoples machines and doesn't crash too often.

OK, this is no worse than Windows, but I dont think users will switch en
masse to Linux audio just because it doesn't chash any more often than
Windows, and if they spend a week playing with kernels and PCI busses they
might be able to get an extra ms of latency.
Post by Richard Bown
Yes, this is a troll and not a very original one at that, but it's time
that there was a clear distinction between Linux Sound/Audio and Linux
for Music. The latter has a clearly defined marketplace, the former
doesn't.
Uhu, and I suspect that the marketplace is for preconfigured machines,
installed with the current, stable software, and backed by some kind of
support/upgrade program. The sort of thing that Carillon offer
http://www.carillondirect.com/ for Windows [not reccomendation - never
used them].

Thier prices are reasonable, even given windows s/w licencing costs, so
they ought the be able to produce a Linux based box for less money with
the same/better QoS. We shall see.

- Steve
Conrad Parker
2002-10-19 07:02:01 UTC
Permalink
Hi all,

If you're a coder, *please* read my long rant below. It contains many
project management details that I've been collecting over the past few
months, and I honestly hope it can be useful to the LAD community.

What if you're not a coder? there's plenty you can do to help out!

We don't just need apps, we need documentation and tutorials. We need
promotional crap: screenshots, audio demos (I've been going crazy with
these for sweep lately, but I'd really like to hear more from what other
software can do, and these are *essential* for showing the world what
can be done with Linux audio). Make some recordings from your favourite
apps, hook up your favourite filters, make a LAD fan site :))
Post by Steve Harris
Post by Richard Bown
The point is that selling Linux Audio isn't just about Linux Audio -
it's about selling the whole desktop. It's about letting people know
that if they want to make music they can just get on and make music.
People shouldn't have to have a degree to install music software and to
start using it. This problem is bigger that LAD/ALSA or even AGNULA
and it crosses that distasteful line between hobbyists twiddling and
research and big business. It treads on a lot of toes.
The problem, I think, is the state of the software that many of us are
happy to use. It needs CVS this, and pl17 that, and we stop hacking when
it builds on most peoples machines and doesn't crash too often.
<rant mode="ON">
ok, I totally agree with Steve here.

there's a _lot_ of really good coders in this community. There's a lot
of good code floating around. The only problem is making the resulting
software accessible to the general public.

I've been extremely lucky to learn what this means; a year ago I thought
I knew, but now I look back and know I sure has hell didn't. Opportunity
forced me to learn this (sweep, Pixar, yada yada yada) -- I was forced
to sit back and think "shit, if this code is going to get seriously used,
it had better be seriously bloody useful". I've been luckier still to
have the opportunity to keep working on sweep at csiro.au, but now, even
though we're doing research work with it, I'm trying to maintain the goals
of it being both production quality and accessible to the general public.

These are two different things, and I'm not out to diss anyone's coding
abilities -- this isn't about being a good coder and being smart enough to
solve tough problems -- this is about having the perseverance to spend
hours tracking down stupid little bugs, it's about checking every single
little error condition that could occur, it's about second guessing
problems with file permissions and invalid input. In libraries and daemons,
it's about giving exact error states to apps and only printing to log
files. In a GUI application, it's about using info dialogs not printfs, and
it's about making dialogs that (for the general public) assume no knowledge
of audio (sample rates etc.) -- but still making them useful for experts.

I spent the first few months of the year spiffing up sweep and getting rid
of a crapload of stupid bugs. Slowly I realised my attitude changed from
"I'm a leet haxor dude, ignore those crashes they're trivial" to "whoah,
what a stupid bug, I'd better put some coffee on and stomp on it". I worked
over the usability, and I went for a month or two spending as much time
in the Gimp drawing little pixmaps as actually writing code. These last
few weeks, sure I've put in support for new codecs (vorbis, mp3, speex ;)
but I spent as much time making dialogs (threadsafe system error dialogs
in GTK, and other fun ways to spend a lazy tuesday afternoon), checking
file permissions, and catching system errors.

none of this stuff is hard -- it's certainly the most mind-numbing part
of writing audio software. I much prefer to spend my time tweaking filters
and mixing beats. But I'll tell you what, a few weeks ago I went to a mate's
place, plugged my laptop into an amp and we jammed for four or five hours,
him on a keyboard, me mixing a bunch of loops and dropping samples with
sweep. Sweep didn't crash once ... until 3am, when it barfed on some silly
file access error as its sleepy user (me) accidentally hit save on the wrong
thing. It was time to go home, and I fixed that bug the next day.
Nevertheless it was really satisfying knowing that sweep could stand up to
that kind of usage, and if it wasn't for the hours of mind-numbing effort
I'd put into fixing bugs and testing error conditions, it simply wouldn't
have been up to the task. And I'm confident that next jam, it'll last even
longer :)

ok, that's general coding stuff covered -- write good code, try to make
sure it doesn't fall over no matter what you throw at it, make it speak
to users in terms they understand. It takes just as long to write this
tedious code to make your program generally useful, as it does to write
the cool audio whacking functionality. Deal with it, stop kidding yourself,
just sit down and write the damn code. Pace yourself, put off the next
set of whizz bang features until the current set are rock solid.

Now then, how to get the code out to people? Make releases. This is what
Steve's talking about above, don't just leave your code sitting in CVS and
expect users to sync up to it. You think your code's not good enough to
release, or that doing that will raise too many expectations? bullshit. If
your code is alpha quality, mark it as such, people will respect that. But,
having a tarball with some kind of notion of "this snapshot is worth trying
out" is far more useful than "get it out of CVS, if you're lucky not too
much will be broken at that particular instant". Make those releases
regularly, and make it a point of pride that at each release you've fixed
as many bugs as you've added features, and that you're providing some
level of assurance that the project is on track.

You want to use CVS to experiment with random new features, and there's
no way you can see anything release worthy in the next six months? probably
bullshit. Most new features can sit in an experimental branch of the
source, without a separate CVS branch -- you only need those for total
rewrites. Have an "experimental" configuration option which pulls in the
not-quite-ready code, but at each release make sure that the experimental
branch still compiles -- sweep, libsndfile, the Linux kernel do this, and
it's far easier than letting CVS branches wander off and trying to do "a
big merge" (phwoar!) later. This way, people can still work on the
in-development code if they want to, it's always synced to the current
state of the rest of the code, and you can _still_ provide some assurance
that the default build is "stable".

Now, where were we .. tarballs. Right, who likes tarballs. Trick question,
the answer is GEEKS. Geeks love tarballs, geeks love sourcecode. Problem
is, we're trying to make software that non-geeks will use. Non-geeks are
a wierd bunch, they often lack essential organs like gcc. I went through
the enlightening experience of handholding a non-geek, via email, in a
different timezone, through "./configure; make" on a half-installed
system with a distro I wasn't used to, for a few weeks.

Ideally, there will be binary packages for your program. You don't need
to be the one making these, but you do need to make sure that others can
build these as easily as possible, and it's a good idea to make your
source autoconfigure itself as helpfully and accurately as possible.

You already use automake/autoconf/libtool/etc? great. You use the
supplied library macros (AM_PATH_BLAH, PKG_CONFIG_CHECK etc)? that's a
good start. If they fail, do you bomb out with a few short words of error
message or do you provide useful info? "but I've got that library installed
and it still fails!!!" -- non-geeks often don't understand the difference
between a library and it's devel package; if the macro fails, check the
library, and check the header. Provide a summary of what's missing, or
what configured ok. Provide URLs of where to get the missing libraries.
Sounds like a lot of tedious configure.in scripting? Deal with it; it's
easier than putting the same info in emails to the few users who bother
to ask you, and it gets the info out to the potentially many more who will
otherwise just give up silently.

without meaning to pimp sweep too much, it's configure.in has grown to over
500 lines of boilerplate shell script, all out of necessity. If you can
compare strings and write if statements, you can write a decent
configure.in. Take mine, write your own, whatever, just stop putting it off
and do it.

ok, we've covered coding and configuration. Encourage others to make
binary packages and maintain them (there's way too many distros for you
to do the job properly).

A really important thing to note here is the feedback loop between users
and developers. If you want to fix bugs and get really good feature
requests, you need users using your program. The best way to get real
users is to have binary packages available, the next best way is to make
it as braindead easy as possible to configure and build from source.
Put the configure help in early, fix trivial bugs in even the earliest
versions (bad input, non-existant files, etc). Close the feedback loop
between users and developers as early as possible, as it grows it will
strengthen your project. At every release (ideally once a week or so) try
to keep the source in a "useful" state, not just "whizz bang crash".

Imagine real people using your program; imagine you had to ship it off
on CD to martians who can't contact you for further advice. Imagine
your long-lost childhood sweetheart finding your program on the latest
RedHat CD: will they be impressed, or will it blow up in their face?
As Dilbert's pointy haired boss would say, "whatever it takes to motivate
you, think about that". Take your program seriously, that's the _only_
difference between a real app and a "toy" -- put the attitude in place
first, then the functionality will appear as if by magic.

Right, as you can probably guess by now, my attitude here is very much
"if you build it, they will come". You have to trust yourself on that.

First, you have to throw away the geek arrogance that your code is great
but everyone else must be stupid for not using it, and realise that you
probably just need to fix a few little things to make it actually useful.
Identify these things, write them down, stomp on them one by one.

If your software is worth building, build it properly, and they will come.

Now then, what's the state of Linux audio? The rest of the world is
ignoring it because they're stupid? bullshit!

Everywhere I go, I hear musicians and DJs saying they want to try out
Linux, and they've heard good things about it. They know Linux is stable
and has excellent potential for low-latency audio, they know that kickass
innovative products like FinalScratch use Linux. Sure, I hear this in
Sydney, which has a pretty vibrant alternative electronic music scene.
The point is, people _know_ Linux rocks, they're just waiting for the
apps. And they're not waiting with their fingers on the keyboard,
frantically patching kernels and syncing CVS trees between gigs. They're
waiting for a time when a simple CD install of ... whatever -- Mandrake,
SuSe, some packaged AGNULA from their local music store ... simply
boots and runs kickass apps that don't fall over, and don't spew cryptic
error messages.

If the system is worth building, build it properly, and they will come.

</rant>


I hope I haven't offended anyone with all that, I'm referring to a general
attitude not any particular project. The advice I'm giving isn't perfect,
and I need to do a better job of taking it myself -- there's still gaping
big TODOs in sweep, --enable-experimental was broken in the last two
releases, it's sorely lacking in documentation. But everything I've
described has worked well for me, and I hope it does for you too.

Linux audio rocks hard, and it's only getting better. Let's start taking
it to the real world.

Conrad.
Paul Davis
2002-10-18 18:15:00 UTC
Permalink
Post by Steve Harris
Maybe, but the people I'm thinking of are looking for a replacement for
thier protools+logic systems, not cubase or cakewalk.
Home users are important too, but...
Post by Richard Bown
It's probably up to the bread and butter products to drive the bespoke,
studio-end products. The complete, finished solution that does both
ends sufficiently well will take a while to arrive (ardour releasing
I'm not sure it ever will. I dont think theres that much overlap between
protools and cubase.
/h+ on the vst-plugins list (i still don't know his real name but he's
a smart guy) made a very similar observation last month. he noted that
the home user world is dominated by people who didn't pay for the
software, never call support (because they didn't pay) and whose
expectations are not particularly important given their status as
non-paying customers. by contrast, the pro world, which these days
includes things like protools, paris, nuendo, sadie, perhaps logic,
and a few more obscure tools, is made up of paying customers who call
support often, pay a lot and expect a lot.

--p
Tom
2002-10-18 19:46:01 UTC
Permalink
Post by Steve Harris
Things like jack have to be graphically wrappered or hidden too, no
scrolling text windows of xruns. The occasionaly discussed jack session
saving gizmo would be a knock dead feature.
And any offering to the general public that doesn't contain this feature
will probably end up just plain dead. Be patient.

Tom
Steve Harris
2002-10-19 09:50:00 UTC
Permalink
Post by Tom
Post by Steve Harris
Things like jack have to be graphically wrappered or hidden too, no
scrolling text windows of xruns. The occasionaly discussed jack session
saving gizmo would be a knock dead feature.
And any offering to the general public that doesn't contain this feature
will probably end up just plain dead. Be patient.
I'm not a patient man ;) Is nayone working on this? I have some ideas, I
could deveote a few hours to it over the next week.

My current thinking is that it should communicate with the jack sockets,
using hte existing jack callback mechanism (which means it needs to be
mediated by jackd).

Better to get it working *before* there are too many jack apps to add
support into.

- Steve
Tom
2002-10-19 23:34:00 UTC
Permalink
Post by Steve Harris
Post by Tom
Post by Steve Harris
The occasionaly discussed jack session
saving gizmo would be a knock dead feature.
And any offering to the general public that doesn't contain this feature
will probably end up just plain dead. Be patient.
I'm not a patient man ;)
I didn't mean you. I meant that anyone interested in announcing linux
audio to the world should wait until this level of functionality is
present. I'm not suggesting that anyone delay development of the gizmo.

The closest thing that I have used is OMS on the mac. It's quite
different than a jack environment but it does allow me to save synth
midi routings and send/receive channels, and provides synth names to
midi apps so I can refer to them directly in my sequencer app.

Tom
Patrick Shirkey
2002-10-20 09:42:00 UTC
Permalink
Post by Richard Bown
Post by Steve Harris
That said, I think Patrick is right to start thinking about this now.
Thanks.
Post by Richard Bown
I think he's completely right - I'm not sure about this bank account
thing but I do think that now is the time to be demoing, talking up and
generally approaching people and companies about Linux music software.
I wrote us up (and mentioned a few other apps) in the latest edition of
Linux User - John at mstation.org has been very kind so far as well.
Now is the right time to be talking to people and getting the
"products" out there. If it works - why not tell people about it?
The reason I believe we need to have various bank accounts are because
we cannot afford to waste money on excessive service charges and not
everyone has access to credit cards. If we have the accounts in the
right countries then people can just donate cash.
Steve Harris
2002-10-20 12:43:00 UTC
Permalink
This is from the Sound on Sound advertising package.
Speaking of which, just how much does it cost to advertise in SOS? I dont
think a little 1/16 b+w ad will help things much, infact it might make the
situation look worse than it is. I'm thinking of the lowgrade ads for
Atari ST software in the dying days of the ST.
They will ask "What kind of cash have we invested" and if we come back
with "Ahh, well we don't actually have a scope on the financial side of
our open community." They are just going to look around for a while and
leave.
I'm not so sure. I dont remember seeing any "Windows doesn't suck to much,
really" adverts when Windows was trying to make an impact on the audio
world. It was just the software vendors porting thier software, and
hardware vendors producing drivers.
It's a choice between being amatuer enthusiasts or professionals.
Yes, and I think I like being an enthusiast. The amatuer v's professional
thing is a bit of a moot point in my case.

- Steve
Len Moskowitz
2002-10-20 13:21:00 UTC
Permalink
Post by Steve Harris
It's a choice between being amatuer enthusiasts or professionals.
Yes, and I think I like being an enthusiast. The amatuer v's professional
thing is a bit of a moot point in my case.
With Linux, the enthusiasts are the foundation. Without them (you) nothing
would have been developed to the point that Linux attracted wider attention.

To take it to the next step, it may take the involvement of profit making
businesses. Profit seems to be the incentive in this society to make things
solid enough for to offer a real (read: stable and useful) product.

If we want to see Linux reach a wider audience, the enthusiasts will need to
take roles in those commercial projects as developers, consultants and
advisors, for without them the commercial projects won't get off the ground.
So please encourage them to accept these roles in commercializing their
programs.


Len Moskowitz
Core Sound
http://www.core-sound.com
David Gerard Matthews
2002-10-20 15:34:00 UTC
Permalink
Post by Steve Harris
Yes, and I think I like being an enthusiast. The amatuer v's professional
thing is a bit of a moot point in my case.
- Steve
That being said, I don't know too many "enthusiasts" who spend their
spare time writing their own
plugins. :)
-dgm
Richard Bown
2002-10-20 13:11:01 UTC
Permalink
On Sunday 20 October 2002 09:37, Patrick Shirkey wrote:
David Gerard Matthews
2002-10-20 15:54:01 UTC
Permalink
I seem to remember a few years back - around 1998 or so, if I recall,
that Electronic Musician magazine
ran an article on Linux. (It was called "The Penguin's Song") I read
the article, and even though there
didn't seem to be too many useful apps at that point, it got me curious.
I started using Linux about
a year later. Dave Phillips's book also helped drum up a little
interest, although I think that was mainly
among people who were already using Linux who may not have been aware
that it was possible to
do much with music/audio on their chosen platform. My point is that
rather than simpy take out ads
in magazines like Sound on Sound, actual articles would probably do a
lot to help. People at all levels,
from rank newbies right on up to multi-platinum producers read those
publications. At this point, I highly
doubt that anyone is going to chuck their ProTools (TM) system in favor
of Linux anytime soon. The people
we might attract are the middle ranks - the people with moderate
technical savvy, decent computer skills, and
professional-level demands, but minimal budgets. This level of customer
has historically been attracted to Linux
in other domains, from IS to scientific computing - (think Beowulf:
"Damn! I wish I had a Cray. Hmmm.... I know!
I stack of Pentiums running Linux!) The other market (and I know this
is niche, but I happen to be in it) is the
world of academic compuiter music, where Linux already has a presence.
(CCRMA, IRCAM, etc.) A lot of
people like to use the same tools they were taught how to use in school,
so if the academic institutions use Linux,
their students will probably want to use it too. (Don't forget that
that's how Unix got established in the first place.)
I don't think you can sell Linux on technical merits alone anymore. At
this point, Mac OSX has many of the same
geeky advantages (protected memory, low-latency, etc.) we love to tout
and the audio apps are beginning to show
up. However, Macs are still quite a bit more expensive than Lintel
hardware and that doesn't even take the cost
of audio warez into consideration. The thing that could do it is to
have some killer apps - 90% of the functionality
of say, Logic would be good enough - with free redistribution. Once that
happens, we get it written up in Sound on Sound,
Electronic Musician, EQ, etc.
I do think we've got some strong potential. Jack is a very good thing,
and once ardour achieves something resembling
stable and truly usable status we'll be close. FreqTweak is brilliant,
especially since it's jack-ified. PD already has
Jack support, and a working version of SC will do wonders.
-dgm
Patrick Shirkey
2002-10-20 18:26:01 UTC
Permalink
Patrick Shirkey
2002-10-20 18:58:00 UTC
Permalink
Post by Richard Bown
Post by Steve Harris
Yes, and I think I like being an enthusiast. The amatuer v's
professional
Post by Steve Harris
thing is a bit of a moot point in my case.
- Steve
That being said, I don't know too many "enthusiasts" who spend their
spare time writing their own
plugins. :)
-dgm
I'm looking at professional from the perspective that if you spend more
than 20 hours of your time per week working on Linux Audio then you
should be considered a professional.

There are other factors that would qualify someone as a Linux
professional. Just because you don't get paid in money doesn't mean it
is not a job.

Every successful organisation I have ever heard of has financial
commitments. What makes us any different? If anything we have more of an
obligation to provide a community funded intiative as money is not
supposed to be the driving force in our motivation. Therefore we
shouldn't care if we spend a little as a group.

BTW. I was not suggesting that we advertise in SoS. I thought that quote
had direct relevance to the target audience of who we would be
advertising to.

I have no definitive idea of where or what would be the best media to
advertise. I have many ideas of what should be said though.

DGM has mentioned

SoS
Electronic musician

I would like to add

google
The independant
The New York times

What are some of the non english speaking possibilities?

Steve you were wondering what the basic rate is for Sos. I think that is
a good standard to work from.

http://www.sound-on-sound.com/html/advert/adsos1.htm

I believe firmly that taking control here will benefit all areas of
Linux Multimedia and the community at large.
Post by Richard Bown
My point is that rather than simpy take out ads
in magazines like Sound on Sound, actual articles would probably do a
lot to help.
Some of us have really been trying for a while now. I think they would
have to do something if they were overwhelmed with success stories from
our community. But that requires people to pull finger and actually
write to the publications and inform them. A campaign along these lines
could be extremely effective at gathering publicity.

I will write something up as guidelines and add it to the openads site.

However, remember a picture tells a thousand words.


--
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.com
Http://www.djcj.org - The Linux Audio Users guide
========================================

"Um...symbol_get and symbol_put... They're
kindof like does anyone remember like get_symbol
and put_symbol I think we used to have..."
- Rusty Russell in his talk on the module subsystem
David Gerard Matthews
2002-10-20 19:50:01 UTC
Permalink
Post by Patrick Shirkey
I have no definitive idea of where or what would be the best media to
advertise. I have many ideas of what should be said though.
DGM has mentioned
SoS
Electronic musician
I would like to add
google
The independant
The New York times
It occurs to me that maybe the people to go after (for the time being)
are people already using Linux, but
who use other platforms for music. This is a not insignificant
population. Lots of people dual-boot or have
several machines, but don't think of Linux as a possibility for audio.
Some of these people are also developers,
which helps, but I think one of the biggest problems we've got is that
we have too many people working on too
many different projects. Lots of people are trying to write their own
softsynths - but everyone would be better
served by their contributing code to existing projects instead. All
those hackers working on little toy editors
should probably be contributing to Sweep or Snd or even Ardour. So it
seems to me that if we're going to
advertise, the place to do it is on sites like Slashdot or the Onion,
and the thing to do is to try to attract developers
to existing projects.
Post by Patrick Shirkey
What are some of the non english speaking possibilities?
There's a pretty good German magazine I used to read when I lived in
Austria, but I forget the name of it.

-dgm
Peter L Jones
2002-10-20 20:54:00 UTC
Permalink
On Sunday 20 Oct 2002 19:58, David Gerard Matthews wrote:
[snip]
Post by David Gerard Matthews
Some of these people are also developers,
which helps, but I think one of the biggest problems we've got is that
we have too many people working on too
many different projects. Lots of people are trying to write their own
softsynths - but everyone would be better
served by their contributing code to existing projects instead.
[snip]

So, we need to take a poll of the best architected open source example of each
category of sound app and put it up in big letters somewhere so people can
find it.

Of course, the examples would have to be useable and useful at the point of
being announced, otherwise time-poor hackers (like me) who want to spend
their (scarse) time playing with the apps rather than debugging will go
elsewhere. (I'm quite happy learning and extending TiMidity++ for example -
it works well enough; I'm considering using it as a way of learning JACK but
the learning curve compared with translating the esd support to artsd looks
kind of steep ;-).)

<rant> I also want to be able to do this on my current machine, a Celeron 400.
Jack won't run - my machine's too slow. MPlayer won't run - my machine's too
slow. But under Windows, WMP works, dropping frames quite happily.
(TiMidity++, now I've learned how to tune it, works _better_ than under
Windows. I don't _believe_ my machine is too slow. So I object to jack and
MPlayer telling me it is.) </rant>

-- Peter
Patrick Shirkey
2002-10-20 20:45:01 UTC
Permalink
I have just updated the site for this discussion to include information
on starting or contributing to a mail campaign for success stories. If
people get motivated it could spark some interest in the media.
--
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.com
Http://www.djcj.org - The Linux Audio Users guide
========================================

"Um...symbol_get and symbol_put... They're
kindof like does anyone remember like get_symbol
and put_symbol I think we used to have..."
- Rusty Russell in his talk on the module subsystem
Patrick Shirkey
2002-10-20 21:56:00 UTC
Permalink
Another reason for advertising (assuming we can choose the correct
places) is that we increase our chances of the reporters being able to
publish their yet to be written stories if we have a proven track record
of supporting the publications.

We scratch their back and they will be less resistant to scratching ours.

I agree with Mark that we shouldn't be promoting Linux Audio as fully
functioning because we will get a negative reaction which will be hard
to overcome. There is definite scope for targetting the techies though.
As long as we don't promote lies we will be doing a lot more for our
image than most consumers expect from advertising campaigns.
--
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.com
Http://www.djcj.org - The Linux Audio Users guide
========================================

"Um...symbol_get and symbol_put... They're
kindof like does anyone remember like get_symbol
and put_symbol I think we used to have..."
- Rusty Russell in his talk on the module subsystem
nick
2002-10-20 22:53:00 UTC
Permalink
Post by Patrick Shirkey
I agree with Mark that we shouldn't be promoting Linux Audio as fully
functioning because we will get a negative reaction which will be hard
to overcome.
This is definitely important. its like the boy who cried wolf..
We have to be realistic and realise Linux is _not_ ready for the average
computer musician. The apps are definitely getting better, but what is
needed is much greater integration, and yes, well never get taken
seriously without a fully featured sequencer.

Developer support is extrememly important - if we dont want to put off
most potential developers we really have improve the documentation front
- fully documented, many examples..

Standards, APIs, good documentation etc.. are the kind of things which
normally take big companies to impose. Say if (crazy idea) steinberg
wanted to bring cubase to linux, do you think they'd use the existing
apis? no way! theyd bring VST over, and all the existing stuff would be
swept into the sideline.

But we dont care about that really, do we? personally, i just enjoy the
satisfaction of working on my own little projects, and fantasising about
where it could all lead... :)

maybe we shouldnt be too worried about pushing linux into the public.
they'll just get put off by our hard-sell. let them come to us, if they
like it, theyll be much more grateful..

-nick

__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
Patrick Shirkey
2002-10-21 13:35:01 UTC
Permalink
Last night I decided to start on the ad campaign on my own in a small way.

Do a search on google for anything with music and recording in the search.

It works that for every hit I get charged up to a max of US$1.50 per day.

I don't think anyone knows that my partner of 5 years has quite
extensive experience in information media marketing and promotions as
well as event management. She has recently become very interested in
applying her skills to help out with Boost Hardware and in general Linux
Audio. She has decided that if you can't beat it join it :)

We have been discussing this at length.

Another idea we have formed is to have a database of contact addresses
of people who would like to offer their skills as tech support for
anyone interested in setting up a Linux Audio System.

If you would like to have your name or business on the list can you let
me know. I will add a page to djcj.org.

Please let us know:

Name
email
phone number
Address

We are also working on a template presentation for people to use if you
want to try your hand at selling to studios or businesses that could use
Linux Audio.
--
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.com
Http://www.djcj.org - The Linux Audio Users guide
========================================

"Um...symbol_get and symbol_put... They're
kindof like does anyone remember like get_symbol
and put_symbol I think we used to have..."
- Rusty Russell in his talk on the module subsystem
Richard Bown
2002-10-21 14:09:01 UTC
Permalink
Post by Patrick Shirkey
Do a search on google for anything with music and recording in the search.
Yikes.
Post by Patrick Shirkey
If you would like to have your name or business on the list can you
let me know. I will add a page to djcj.org.
While I applaud your conviction - I still don't quite get it. If you're
collecting names and buying advertising space does this now make you an
agency? And if so will you be collecting commissions at any point in
the future? And can you prove this?

Forgive my scepticism but I was brought up to believe that you don't
ever get something for nothing.

B
Patrick Shirkey
2002-10-21 16:26:00 UTC
Permalink
Post by Richard Bown
Post by Patrick Shirkey
Do a search on google for anything with music and recording in the search.
Yikes.
I thought you might say that ;)
Post by Richard Bown
Post by Patrick Shirkey
If you would like to have your name or business on the list can you
let me know. I will add a page to djcj.org.
While I applaud your conviction - I still don't quite get it. If you're
collecting names and buying advertising space does this now make you an
agency? And if so will you be collecting commissions at any point in
the future? And can you prove this?
I'm not interested in taking revenues from people who want to be listed.
I'll make some disclaimers in regards to that just to make sure people
have no misconceptions.

I'm not interested in under cutting the hard work of the LAD community
if you are worried about that. Do you realise that I run Boost Hardware?
If you haven't already seen the website for BH you should take a look,
that will give you a better impression of what some of my motivation is.
Post by Richard Bown
Forgive my scepticism but I was brought up to believe that you don't
ever get something for nothing.
Well I don't consider the work put in by the LADers to be nothing and I
most certainly don't consider the work I do to be nothing. In terms of
money I would like to be financially stable solely from selling the
equipment I can build. Currently that isn't how I make my cash.

Anyway in terms of the pecking order of people who seem to be giving a
lot for no financial return, I'm pretty low in the ranks.
--
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.com
Http://www.djcj.org - The Linux Audio Users guide
========================================

"Um...symbol_get and symbol_put... They're
kindof like does anyone remember like get_symbol
and put_symbol I think we used to have..."
- Rusty Russell in his talk on the module subsystem
Patrick Shirkey
2002-10-21 17:09:00 UTC
Permalink
Post by Patrick Shirkey
Post by Richard Bown
Post by Patrick Shirkey
Do a search on google for anything with music and recording in the search.
Yikes.
I thought you might say that ;)
Post by Richard Bown
Post by Patrick Shirkey
If you would like to have your name or business on the list can you
let me know. I will add a page to djcj.org.
While I applaud your conviction - I still don't quite get it. If
you're collecting names and buying advertising space does this now
make you an agency? And if so will you be collecting commissions at
any point in the future? And can you prove this?
I'm not interested in taking revenues from people who want to be listed.
Or did you mean "will I be asking people to donate money to help me
advertise"?

If that is the case I won't be asking for help with the google ad but
donations won't be turned away. I am asking people to contribute to a
larger fund specifically for advertising Linux Audio. I've already spent
just over US$100 this year on the increased traffic from linking the
LAU guide directly into the alsa website.

I am in the process of writing up a full plan for how I see a community
sponsored fund working.

I feel that we are in a very important time right now which we can use
as a launching point for increasing peoples motivation to get involved
in Linux Audio. There are two major international events happening at
the moment that are getting the target audience to question the
established norms. We should be riding that wave as we have a really
good concept that answers many of the questions. Open Source.

I think many of the products are ready for people to use and especially
contribute to. The problem I see is that most people are not ready for
that because they have not been given the incentive to get involved.

it's been said many times before that another way we could add serious
clout to our image is having some high profile users.
--
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.com
Http://www.djcj.org - The Linux Audio Users guide
========================================

"Um...symbol_get and symbol_put... They're
kindof like does anyone remember like get_symbol
and put_symbol I think we used to have..."
- Rusty Russell in his talk on the module subsystem
Len Moskowitz
2002-10-21 18:12:01 UTC
Permalink
Post by Patrick Shirkey
If that is the case I won't be asking for help with the google ad but
donations won't be turned away. I am asking people to contribute to a
larger fund specifically for advertising Linux Audio. I've already spent
just over US$100 this year on the increased traffic from linking the
LAU guide directly into the alsa website.
If you will be making money from a Linux-based product, then you *should* be
investing your own money for promotion.


Len Moskowitz
Core Sound
http://www.core-sound.com
Lea Anthony
2002-10-21 19:49:01 UTC
Permalink
Hi guys,

Most musicians I know really don't give a hoot for what OS they run or
indeed what philosophy drove the development of the apps. All they care
about is if it will do the job better then their current setup at a
cheaper cost. Piracy is rife in the audio world which means people can
get their hands on pretty decent software. This is what they'll be
comparing LAD with. For Linux to compete in the audio field, I believe
it must be able to do a number of things including the following:

1. Provide an easy to use system that is exactly that
2. Provide 32bit support where possible
3. Have the ability to use DirectX plugins

Sure, there is probably a lot more but I'm just gathering my thoughts
here. What I'm afraid of is that LAD will end up with the same problems
as most Linux distros suffer from: Bloat. Choice is good, but do I
really need 7 text editors on my system? No. What I believe would
benefit LAD, and correct me if I'm wrong, is to create a 'big picture',
a complete DAW system. It should consist of AN audio editor, AN audio
recorder, A sample editor, etc. Like I said, choice is great but
musicians don't give a hoot about choice, they want something that
works, not 7 things that are half done. If all effort was pushed in this
direction, I believe we would end up with a quality system that the
world would take seriously.

I don't know if the 3 points I've made have already been done, I'm new
to LAD, but they are important. Especially 3 as it gives a "migration
path" to existing windoze users. I know, I know, DirectX plugins are
written against Microsoft libraries, but how come mplayer on Linux can
use windows binaries (codecs) in it's system? Could the same not be done
for audio? Surely it's the same principle? (Media data input, process,
media data ouput).

Maybe I'm going over old ground here but I wanted to say something
anyway. Isn't that what mailing lists are for? I know people who would
move away from windows at the drop of a hat. They hate windows. High
latency, instability...

So how about it? An integrated system using your good talents. If you
have a waveform in an audio recorder you want to double click to edit
it, not drop out, load up a different program and then search around the
directories for audio_track_3_guitar_take_7.wav. Stupid stuff like this
creates a good user experience which in turn wins people. I have a ton
of ideas for audio editing that aren't in the 'big name' apps and if I
had the time, would code them myself (but I'm sure there are people who
could do it in half the time here :).

Aaanyway, that's my brain dump for today. Hope I didn't lose you on the
way :)

Cheers,

-Lea.

PS: There was no criticism intended in this post.
Patrick Shirkey
2002-10-21 19:57:01 UTC
Permalink
Post by Len Moskowitz
If you will be making money from a Linux-based product, then you
*should* be investing your own money for promotion.
I am. What's your point?

If you are percieving this thread as me doing a plug for my site and
business then I have not been specific enough about what I want to see
happen.

I have a small business and there are others out there in similar
positions. We don't have the financial resources to fund large scale ad
campaigns on our own. But we do if we work together.

There are also plenty of people who might be willing to invest a little
into a community run initiative if we can prove that we are not doing it
for self serving purposes. Maybe these people would like to see us succeed.

I want to tap that vein.

Sorry if this is short but I find your comment a little on the short
side too. If it's a joke then you got me ;]
--
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.com
Http://www.djcj.org - The Linux Audio Users guide
========================================

"Um...symbol_get and symbol_put... They're
kindof like does anyone remember like get_symbol
and put_symbol I think we used to have..."
- Rusty Russell in his talk on the module subsystem
Patrick Shirkey
2002-10-21 20:26:00 UTC
Permalink
We run the risk of annoying people by starting an ad campaign now.
This didn't sit with me when I read it. Now I think I know why.

Why should we let these people who could get annoyed wait for us to
polish the products to perfection. If they want to use them as much as
they say they do they should not be under the impression that we are
happy to be unpaid workhorses so they can gain without showing respect.

They should be contributing in some way and for many of them it will be
financial assistance that is the easiest option.

If they are not prepared to contribute code or time in debugging or
skills in documentation construction then they should have the option of
contributing financially to the community.

They are far more likely to donate to a community run initiative than to
any independant project.

Mark said we need a game plan and list of necessary targets for
stability of the Linux Audio Platform. I feel I'm presenting one part of
that here.

But am I just wasting my breath because the Agnula crew are going to do
all the work for us?

Anyone from the Agnula project have a position on this?
--
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.com
Http://www.djcj.org - The Linux Audio Users guide
========================================

"Um...symbol_get and symbol_put... They're
kindof like does anyone remember like get_symbol
and put_symbol I think we used to have..."
- Rusty Russell in his talk on the module subsystem
Richard Bown
2002-10-22 09:38:00 UTC
Permalink
Post by Patrick Shirkey
But am I just wasting my breath because the Agnula crew are going to
do all the work for us?
Oh well _now_ you come on to my pet subject.
Post by Patrick Shirkey
Anyone from the Agnula project have a position on this?
A while ago I got involved in a flamespat with the head honcho of AGNULA
when I suggested that they should improve their communication with the
rest of the LAD community and specifically with the development teams.
I think we'd pretty much all like to know what's happening with AGNULA
(apart from the minutes of their meetings) and naively I saw it as
their job to tell us and be nice to us.

While they do have selective communication with those that they consider
to be key people I think my fundamental mistake was to actually think
of AGNULA as an organisation. While it appears to be an organisation
it's really just a tech project - it's run by geeks and it will aim to
deliver some packaged apps and code in the time allowed. Once it's
packaged it'll ship and LAD type projects will get exposure to the rest
of the world through their distro. AFAICT that's the deal. While
that's not a bad deal of course I think AGNULA should have more of a
personality and a PR role with and in the LAD community. I've said in
the past that I think it'd benefit "them" and "us".

But hey. I'm not going to get on my hobby horse again over that one.
No chance. No sir.

B
Len Moskowitz
2002-10-22 16:49:00 UTC
Permalink
Post by Patrick Shirkey
Post by Len Moskowitz
If you will be making money from a Linux-based product, then you
*should* be investing your own money for promotion.
I am. What's your point?
Other people (people who are not in business) need not and likely won't
invest money to promote Linux Audio.

People here invest their time and effort (but usually not money for
promotion), mostly because they're techies who want to to build something
that they really need/want. Businesses invest money for another reason,
because they want to develop and promote commercial products. They're
mostly two different worlds (though there is crossover).
Post by Patrick Shirkey
I have a small business and there are others out there in similar
positions. We don't have the financial resources to fund large scale ad
campaigns on our own. But we do if we work together.
Perhaps there's no need to promote Linux Audio; perhaps instead there is a
need to promote useful products. If those products happen to need Linux
(and ALSA & Jack) as a foundation, then Linux will get promoted as a side
effect of successful products. Much like MacOS.

So if you want Linux Audio to be promoted, either make broadly useful
products or assist the companies that want to turn your work into broadly
useful products.


Len Moskowitz
Owner, Core Sound
http://www.core-sound.com
Patrick Shirkey
2002-10-22 16:52:01 UTC
Permalink
it is also pretty much useless for general users. I mean if I can't
listen to mp3 and browse the web at the same time ... (without sound
servers which were discussed recently and as far as I can tell the
general consensus is that they are bad and not to be used).
This is a misconception on your part. The general consensus is that the
artsd, esd, gstreamer... servers are *very* useful just not for
professional audio needs.

I am pretty sure that people who only need to browse and hear mp3's at
the same time have a fully functioning system with kde and gnome. Seeing
as they are the standard desktops anyone who cannot install a different
desktop would be even less likely to be playing around with professional
audio. If they are trying to then they need to either learn how to use
their computer more effectively like everyone else round here or get
someone to do the work for them.

If they want the latter thought they will have a hard time finding
contact details because we haven't yet made a site that provides that
info. LAD centric of course.

I am working on it now and hope to have it finished in the next few
days. At that time I hope the people on this list will use it as a resource.
--
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.com
Http://www.djcj.org - The Linux Audio Users guide
========================================

"Um...symbol_get and symbol_put... They're
kindof like does anyone remember like get_symbol
and put_symbol I think we used to have..."
- Rusty Russell in his talk on the module subsystem
Steve Harris
2002-10-20 21:41:00 UTC
Permalink
Post by Patrick Shirkey
Some of us have really been trying for a while now. I think they would
have to do something if they were overwhelmed with success stories from
our community. But that requires people to pull finger and actually
write to the publications and inform them. A campaign along these lines
could be extremely effective at gathering publicity.
Or anoyning people in the industry. My experince of music proffesions in
the UK is that they are largly interested in what we have to offer, but I
think they will rapidly loose interest if we keep pestering them.

I'm sure that I can get column inches in the music press convering linux,
but I can do that *once*. If it turns out to be interesting to people out
there I'm sure it will continue. SOS for example run PC and Apple Notes
sections, a Linux Notes section would be a great platorm for our work, but
badgering the edtiors for one just isn't going to help.

- Steve
Mark Knecht
2002-10-20 18:36:00 UTC
Permalink
David,
[Embedded comments at the end also.]

I've been staying on the sidelines of this thread up 'til now. I'd like
to add a users' perspective. I am not a programmer at all. I come at this
totally from the point of view of a user. A little bit of this post might
sound like a low-end rant, but mostly it's an opinion of someone that's used
tools like this and spent a lot of time around other folks that do also.
And, as always, the opinions are mine alone.

I personally think it's a bit too early to start talking outside of an
interest group like this. It's not too early to figure out what we're going
to say, and figure out how we're interested in saying it, but to go out an
bring people here before there is a toolset that really works is just asking
people to be beta testers. If we're doing that, then let's be honest when we
tell them.

There is a really GREAT reason for people to start migrating somewhere
though - 96KHz support. Everyone is worried about getting trapped in a
close, expensive, buggy solution when they more to 96K. DigiDesign is really
messing with the semi-pro guys. They know it, but they don't know what to
do. That's why I'm here.

I did start talking to people in the Pro Tools area about Ardour and too
many people showed up that didn't know Linux, (like me!) couldn't fix the
problems they were having, and went away saying Ardour has nothing to offer.
They are not right, but they say these things and it turns other people off.
I don't want to see that happen. It takes too long to recover.

When speaking about tools from a users' perspective, be he/she a
professional, a semi-pro or a home enthusiast like me, the thing that really
matters is whether the tools do the job. I think your list below points up
the one totally glaring problem with the Linux tools that needs to be
address long before you go push people to look at this work. That problem is
the lack of MIDI integrated to work with audio. Today we have some great
MIDI apps coming along (Muse, Rosegarden, Midi Mountain) Ardour on the audio
side, soft synths galore (although they are not all usable in an integrated
way yet) loads of interesting plugins and jack to allow the audio to talk
between apps. But, unfortunately, there's no way I know of yet to talk about
all of the Alsa apps to users who want to replace Pro Tools, which is where
I'm coming from. This needs to be handled in a convincing way before talking
to people, or the negative press will be very hard to overcome.

Here comes my little rant. The 'problem' here is that Linux apps are
developed by very intelligent, well meaning, technical people who work on
what they want to work on and not necessarily what's wanted and needed by
the 'marketplace'. I think that some real program management is required.
Look at what the market wants and needs, (audio, MIDI, soft synths, plugins,
scoring, automation, etc.) write it down somewhere and then do an honest
assessment of where Linux audio solutions are. If we have what the users
need, then we talk. If we don't, then we put a program in place to make that
stuff happen fast, so that when we do have it we can talk. Unfortunately,
this would require the developers to respond more like work and less like a
hobby. I don't know that they want to do that. <EOR>

Beyond that, we need to handle the installation stuff much more cleanly.
PlanetCCRMA is doing a great job of that for the Redhat platform. I know
that many people wouldn't want to be forced into a distribution long term,
but in the beginning many people who will come and try out this stuff won't
be Linux users and should be directed towards a COMPLETE solution. Currently
I think the Planet is the best I know of.

As I don't want you to think I'm negative on what's going on here, I
think there are MANY things that Linux could offer, but isn't even trying to
talk about yet. Things like:

1) Real multi-processor support
2) Distributed processing where different apps are on multiple machines all
working together
3) Remote access - all the application computers are in a different room and
one very quiet PC is used in the studio to display their screens. No noise,
but water cooling not required.
4) Much more stable platform. No reboots, no sad Macs, no BSODs.
5) More open hardware support, presuming someone ever makes the multicard
thing understandable by those of us that don't have a PhD. in Alsa.

Anyway, all said, I personally don't think money and bank accounts are
the answer right now, but they may be helpful in the future, and I'd
certainly contribute time and a bit of money to help things move along when
we have a real plan. I just don't think we're thee yet.

Actually, I think we don't even have a plan to have a plan yet, and that
needs to be solved before anything will really work out right.

Thanks for listening. I hope you got this far.

Cheers,
Mark



-----Original Message-----
From: linux-audio-dev-***@music.columbia.edu
[mailto:linux-audio-dev-***@music.columbia.edu]On Behalf Of David
Gerard Matthews
Sent: Sunday, October 20, 2002 8:02 AM
To: linux-audio-***@music.columbia.edu
Subject: Re: [linux-audio-dev] Re: image problem [was Re: [Alsa-devel]
help for a levelmeter]


At this point, I highly doubt that anyone is going to chuck their ProTools
(TM) system in favor
of Linux anytime soon.

[MWK] I'm trying!!!!!!!!!!!!


The thing that could do it is to have some killer apps - 90% of the
functionality of say, Logic would be good enough - with free redistribution.

[MWK] Yep! The caveat is that you have to have the right 90%!


Jack is a very good thing, and once ardour achieves something resembling
stable and truly usable status we'll be close. FreqTweak is brilliant,
especially since it's jack-ified. PD already has Jack support, and a
working version of SC will do wonders.

[MWK] Great examples, but I'm not sure this morning what 'SC' is. However,
not a MIDI app in the bunch yet, as per my comments above.
David Gerard Matthews
2002-10-20 19:42:01 UTC
Permalink
Post by Mark Knecht
I've been staying on the sidelines of this thread up 'til now. I'd like
to add a users' perspective. I am not a programmer at all. I come at this
totally from the point of view of a user.
So do I, for the most part.
Post by Mark Knecht
There is a really GREAT reason for people to start migrating somewhere
though - 96KHz support.
The biggest problem with 96 kHz is that at the moment there isn't a
really great way to get a 96 kHz
digital stream from one device to another. Double speed AES/EBU is
probably the best solution, but
not many people have multiple channels of AES. You can send 96 kHz over
lightpipe or TDIF, but you
lose half the channels. Lots of cards (like my nifty Delta 1010)
support it, lots of apps support it, but once
it's inside the computer, there's not an easy way to get it out. Not
only that, but it's going to be awhile before
everyone has DVD-A, so most people won't be able to listen to 96 kHz
recordings anytime soon. The point:
44.1 and 48 kHz are going to remain standard for awhile, and the
presence or lack of 96 kHz at this point
doesn't seem to make or break a platform for most people that I know.
Post by Mark Knecht
Everyone is worried about getting trapped in a
close, expensive, buggy solution when they more to 96K. DigiDesign is really
messing with the semi-pro guys. They know it, but they don't know what to
do. That's why I'm here.
Digidesign is a pretty arrogant company, as I see it. They just
unveiled all this nifty new hardware, like
the Digi002 and the ProTools HD systems (96 is one thing, but who really
needs 192 kHz?), but they're
still committed to Mac OS 9. I have the feeling that the only reason
Apple still puts OS 9 on their
boxes is for the people who want to run ProTools. (I cite the continued
preference of many musicians
for classic MacOS as proof of the inherent conservatism of many of the
people we're trying to reach.)
Post by Mark Knecht
That problem is
the lack of MIDI integrated to work with audio. Today we have some great
MIDI apps coming along (Muse, Rosegarden, Midi Mountain) Ardour on the audio
side, soft synths galore (although they are not all usable in an integrated
way yet) loads of interesting plugins and jack to allow the audio to talk
between apps.
Fair enough criticism, I suppose. The list reflected my own personal
needs and priorities, and I don't
often use or care about MIDI. (I like old-school text-driven synthesis
languages and graphical synthesis
environments like PD and jMax.)
Post by Mark Knecht
But, unfortunately, there's no way I know of yet to talk about
all of the Alsa apps to users who want to replace Pro Tools, which is where
I'm coming from. This needs to be handled in a convincing way before talking
to people, or the negative press will be very hard to overcome.
Here comes my little rant. The 'problem' here is that Linux apps are
developed by very intelligent, well meaning, technical people who work on
what they want to work on and not necessarily what's wanted and needed by
the 'marketplace'.
True enough. One sees this in Linux across the board. I do, however,
think that this is changing. Geeks and
non-geeks can blissfully coincide. One does not need to give up emacs
to use OpenOffice.
Post by Mark Knecht
I think that some real program management is required.
Look at what the market wants and needs, (audio, MIDI, soft synths, plugins,
scoring, automation, etc.) write it down somewhere and then do an honest
assessment of where Linux audio solutions are.
I don't think lack of awareness is the problem. The problem is that
most Linux audio apps are developed by
people who have full-time jobs doing other things. The problems
involved in designing audio apps are so great
that even those people who are able to work full time on Linux audio are
often stupmed as to how to implement
the desired solutions. Everyone knows we need a decent midi sequencer,
and I for one would love to have a truly
usable notation program. Great. Just about everyone who knows how to
develop such an app is working for one
of the big companies, and you can bet they ain't going to open-source
their code anytime soon. Guys like Paul Davis
and Bill Schottstaedt do not have the benefit of a team of full-time
codes who can help them solve the sorts of problems
they face.
Post by Mark Knecht
If we have what the users
need, then we talk. If we don't, then we put a program in place to make that
stuff happen fast,
Suggestions as to how to make this happen?
Post by Mark Knecht
so that when we do have it we can talk. Unfortunately,
this would require the developers to respond more like work and less like a
hobby. I don't know that they want to do that. <EOR>
Beyond that, we need to handle the installation stuff much more cleanly.
PlanetCCRMA is doing a great job of that for the Redhat platform.
Yes they are. Nando rocks.
Post by Mark Knecht
I know
that many people wouldn't want to be forced into a distribution long term,
but in the beginning many people who will come and try out this stuff won't
be Linux users and should be directed towards a COMPLETE solution. Currently
I think the Planet is the best I know of.
AGNULA is also a possibility.
Post by Mark Knecht
As I don't want you to think I'm negative on what's going on here, I
think there are MANY things that Linux could offer, but isn't even trying to
1) Real multi-processor support
2) Distributed processing where different apps are on multiple machines all
working together
3) Remote access - all the application computers are in a different room and
one very quiet PC is used in the studio to display their screens. No noise,
but water cooling not required.
4) Much more stable platform. No reboots, no sad Macs, no BSODs.
5) More open hardware support, presuming someone ever makes the multicard
thing understandable by those of us that don't have a PhD. in Alsa.
Unfortunately Linux is no longer the only platform to offer all that.
Mac OSX has all of the above, as wel.
Post by Mark Knecht
At this point, I highly doubt that anyone is going to chuck their ProTools
(TM) system in favor
of Linux anytime soon.
[MWK] I'm trying!!!!!!!!!!!!
Great! But are we talking ProTools LE or a big ol' nasty TDM system? I
could see someone ditching
LE, but TDM users (and the highest echelon of the market is exclusively
TDM, even if the software is not
ProTools) have too much invested in the hardware.
Post by Mark Knecht
The thing that could do it is to have some killer apps - 90% of the
functionality of say, Logic would be good enough - with free redistribution.
[MWK] Yep! The caveat is that you have to have the right 90%!
As I said before, the problem isn't that the developers are ignorant as
to what the users want, it's that they
don't really know how to implement it.
Post by Mark Knecht
[MWK] Great examples, but I'm not sure this morning what 'SC' is. However,
not a MIDI app in the bunch yet, as per my comments above.
SC = SuperCollider. Formerly a proprietary MacOS app, recently GPL'd
and ported to OSX, and
there's a project underway to port the OSX version to Linux.

-dgm
Steve Harris
2002-10-20 21:57:00 UTC
Permalink
Post by David Gerard Matthews
Post by Mark Knecht
I think that some real program management is required.
Look at what the market wants and needs, (audio, MIDI, soft synths, plugins,
scoring, automation, etc.) write it down somewhere and then do an honest
assessment of where Linux audio solutions are.
I don't think lack of awareness is the problem. The problem is that
most Linux audio apps are developed by
people who have full-time jobs doing other things. The problems
involved in designing audio apps are so great
that even those people who are able to work full time on Linux audio are
often stupmed as to how to implement
This might be true on the macro scale, "what we need is a complete DAW
that does everything" ;) but I, personally have no idea what the average
musician wants from plugins. My needs are pretty esoteric, and I'm trying
not to flood the LADSPA scene with bizarre, special purpose plugins (belive
it or not ;).

Which brings me to my off-topic rant, I think its my turn again ;)

Don't be afraid to criticise. I am very thick skinned, and wont be
offended if you tell me that plugin X is crap, or should be different. Or
something. Complain! Just because you're not paying me doesn't mean I
don't care if it sucks.

I have a bigish todo list, but some of the things on it are truly hard,
however if what you want is easy, it will get done quickly, and if enough
people want something I will be more motivated to pull my finger out.

</rant>

- Steve
Kai Vehmanen
2002-10-20 21:43:00 UTC
Permalink
Post by Peter L Jones
<rant> I also want to be able to do this on my current machine, a Celeron 400.
Jack won't run - my machine's too slow. MPlayer won't run - my machine's too
As for JACK requiring a +400Mhz machine, that's simply not true! I've
run JACK just fine on a number of old <200Mhz Pentiums with no problems
what so ever.
--
http://www.eca.cx
Audio software for Linux!
Peter L Jones
2002-10-21 22:52:01 UTC
Permalink
Post by Kai Vehmanen
Post by Peter L Jones
<rant> I also want to be able to do this on my current machine, a Celeron
400. Jack won't run - my machine's too slow. MPlayer won't run - my
machine's too
As for JACK requiring a +400Mhz machine, that's simply not true! I've
run JACK just fine on a number of old <200Mhz Pentiums with no problems
what so ever.
Exactly.

So why, having studied the docs, am I completely stumped with jack? It
refuses to play. I don't consider any solution based on a piece of software
_I_ can't operate suitable for general use.

Yes, I'm big headed maybe: I frequently overlook the glaringly obvious. I
frequently need the glaringly obvious carefully pointed out. However, jack
isn't spotting it either so either (a) jack doesn't spot the glaringly
obvious when it should or (b) it's not glaringly obvious. In either case, I
reckon this justifies the view it's not suitable for general use.

When I get time, I'll get over to the jack users list (if there is one).
Right now, I don't _need_ jack working.

-- Peter
Mark Knecht
2002-10-20 22:42:00 UTC
Permalink
David,
Great thoughts. Thanks!

Mark
Post by Mark Knecht
There is a really GREAT reason for people to start migrating somewhere
though - 96KHz support.
The point: 44.1 and 48 kHz are going to remain standard for awhile, and the
presence or lack of 96 kHz at this point doesn't seem to make or break a
platform for most people that I know.

[MWK] - I agree with you technically, but if I understand the point of this
thread then marketing is the real issue. Everyone out there is thinking
they're going to go to 96K. Any solution that comes out from now on will
have some sort of support for it, and people think they need it to keep up.
Linux can, and does, offer it. The cost is no worse here than anywhere else,
and for a number of reason probably better.
Post by Mark Knecht
That problem is the lack of MIDI integrated to work with audio. Today we
have some great MIDI apps coming along (Muse, Rosegarden, Midi Mountain)
Ardour on the audio side, soft synths galore (although they are not all
usable in an integrated way yet) loads of interesting plugins and jack to
allow the audio to talk between apps.

Fair enough criticism, I suppose. The list reflected my own personal needs
and priorities, and I don't often use or care about MIDI. (I like
old-school text-driven synthesis languages and graphical synthesis
environments like PD and jMax.)

[MWK] - Yep, we all look at this from our own perspective, me included.
Linux give you tools to do that, but in my mind the discussion is about what
most people want, and today most people are in the graphics based,
Windows/Mac world. We need reasons to bring them over. I don't want to see
things get in the way.
Post by Mark Knecht
Here comes my little rant. The 'problem' here is that Linux apps are
developed by very intelligent, well meaning, technical people who work on
what they want to work on and not necessarily what's wanted and needed by
the 'marketplace'.


True enough. One sees this in Linux across the board. I do, however, think
that this is changing. Geeks and
non-geeks can blissfully coincide. One does not need to give up emacs to
use OpenOffice.

[MWK] - Yep, I agree completely
Post by Mark Knecht
I think that some real program management is required.
Look at what the market wants and needs, (audio, MIDI, soft synths,
plugins,
Post by Mark Knecht
scoring, automation, etc.) write it down somewhere and then do an honest
assessment of where Linux audio solutions are.
I don't think lack of awareness is the problem.

[MWK] Agreed


The problem is that most Linux audio apps are developed by people who have
full-time jobs doing other things. The problems involved in designing audio
apps are so great that even those people who are able to work full time on
Linux audio are often stumped as to how to implement the desired solutions.
Everyone knows we need a decent midi sequencer, and I for one would love to
have a truly usable notation program. Great. Just about everyone who knows
how to develop such an app is working for one of the big companies, and you
can bet they ain't going to open-source their code anytime soon. Guys like
Paul Davis and Bill Schottstaedt do not have the benefit of a team of
full-time codes who can help them solve the sorts of problems they face.

[MWK] David, I more than agree, but when a new person looking for tools
comes here because he read an article in Sound on Sound, he isn't going to
accept that Linux developers have other things to do. He's going to make a
decision based on his needs in a certain time frame. If what he's looking
for is here, he becomes a user. If not, he goes away. The only real point
I'm making is let's not over commit, and my thought on how to do that was in
the original post.
Post by Mark Knecht
If we have what the users
need, then we talk. If we don't, then we put a program in place to make
that
Post by Mark Knecht
stuff happen fast,
Suggestions as to how to make this happen?

[MWK] First it takes a common vision about what we want. Do we want a single
program like PTLE or Cubase SX, or do we want something more distributed? Is
it possible to have both? I have my vision. Others undoubtedly have theirs.
I'd be happy to try and set up some way for us to monitor, measure, track,
manage something like this. Beyond that, it takes developers and
users/testers getting committed to making it happen. Personally I think at
least 80-90% of what we need is probably here somewhere. If I was running
this as a business, my input would be that we need to choose a direction,
find the pieces, figure out how to integrate them, find people who have some
time to do it, and get started.
Post by Mark Knecht
so that when we do have it we can talk. Unfortunately,
this would require the developers to respond more like work and less like a
hobby. I don't know that they want to do that. <EOR>
Beyond that, we need to handle the installation stuff much more cleanly.
PlanetCCRMA is doing a great job of that for the Redhat platform.
Yes they are. Nando rocks.
Post by Mark Knecht
I know
that many people wouldn't want to be forced into a distribution long term,
but in the beginning many people who will come and try out this stuff won't
be Linux users and should be directed towards a COMPLETE solution.
Currently
Post by Mark Knecht
I think the Planet is the best I know of.
AGNULA is also a possibility.
Post by Mark Knecht
As I don't want you to think I'm negative on what's going on here, I
think there are MANY things that Linux could offer, but isn't even trying
to
Post by Mark Knecht
1) Real multi-processor support
2) Distributed processing where different apps are on multiple machines all
working together
3) Remote access - all the application computers are in a different room
and
Post by Mark Knecht
one very quiet PC is used in the studio to display their screens. No noise,
but water cooling not required.
4) Much more stable platform. No reboots, no sad Macs, no BSODs.
5) More open hardware support, presuming someone ever makes the multicard
thing understandable by those of us that don't have a PhD. in Alsa.
Unfortunately Linux is no longer the only platform to offer all that.
Mac OSX has all of the above, as well.
Post by Mark Knecht
At this point, I highly doubt that anyone is going to chuck their ProTools
(TM) system in favor
of Linux anytime soon.
[MWK] I'm trying!!!!!!!!!!!!
Great! But are we talking ProTools LE or a big ol' nasty TDM system? I
could see someone ditching LE, but TDM users (and the highest echelon of the
market is exclusively
TDM, even if the software is not ProTools) have too much invested in the
hardware.

[MWK] There are reasons they will NEVER ditch those systems, but it has
nothing to do with the sound. It's business. They see the Pro Tools (tm)
name as a business advantage. They will, however, put a Linux box in place
and use it if it works.
Post by Mark Knecht
The thing that could do it is to have some killer apps - 90% of the
functionality of say, Logic would be good enough - with free
redistribution.
Post by Mark Knecht
[MWK] Yep! The caveat is that you have to have the right 90%!
As I said before, the problem isn't that the developers are ignorant as to
what the users want, it's that they
don't really know how to implement it.

[MWK] I sincerely hope that I'm not saying anything that would make you or
anyone else think I believe the developers are ignorant. Far from it. They
are amazing. However, if we have a vision of what we want to do, as we've
been speaking of above, will they develop it?
Post by Mark Knecht
[MWK] Great examples, but I'm not sure this morning what 'SC' is. However,
not a MIDI app in the bunch yet, as per my comments above.
SC = SuperCollider. Formerly a proprietary MacOS app, recently GPL'd and
ported to OSX, andthere's a project underway to port the OSX version to
Linux.

[MWK] Yes, Super Collider! It looks cool!

-dgm
Mark Knecht
2002-10-20 22:53:15 UTC
Permalink
Patrick,
Nobody, me included, thought anyone would promote anything except the
truth. We can certainly work on the plans and figure out what to promote,
and when to promote it.

I'm in need of a better MIDI setup first. If anything in the Linux
environment could run along side of my Pro Tools setup, giving me what I
need (instrument naming, better program changes, scoring, etc.) then I could
just wait for Ardour to get there on the audio side.

One step at a time with a vision of where we're going.

Mark

-----Original Message-----
From: linux-audio-dev-***@music.columbia.edu
[mailto:linux-audio-dev-***@music.columbia.edu]On Behalf Of Patrick
Shirkey
Sent: Sunday, October 20, 2002 1:51 PM
To: Patrick Shirkey
Cc: linux-audio-***@music.columbia.edu
Subject: Re: [linux-audio-dev] Re: image problem [was Re: [Alsa-devel]
help for a levelmeter]


Another reason for advertising (assuming we can choose the correct
places) is that we increase our chances of the reporters being able to
publish their yet to be written stories if we have a proven track record
of supporting the publications.

We scratch their back and they will be less resistant to scratching ours.

I agree with Mark that we shouldn't be promoting Linux Audio as fully
functioning because we will get a negative reaction which will be hard
to overcome. There is definite scope for targetting the techies though.
As long as we don't promote lies we will be doing a lot more for our
image than most consumers expect from advertising campaigns.

--
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.com
Http://www.djcj.org - The Linux Audio Users guide
========================================

"Um...symbol_get and symbol_put... They're
kindof like does anyone remember like get_symbol
and put_symbol I think we used to have..."
- Rusty Russell in his talk on the module subsystem
Mark Knecht
2002-10-20 22:54:01 UTC
Permalink
Steve,
I think your commitment and abilities are amazing. (Re: the compressor
you did within a couple of days of me even suggesting it.)

I haven't been able to do enough work with Ardour to really use the
plugins you've done and make good comments on them.
[mailto:]On Behalf Of Steve Harris
1970-01-01 00:00:00 UTC
Permalink
You're meters are going to make people very happy, especially when we
have some way to let users plug them in where ever they need to in their
signal chains. Viva la patch bay.

Mark

-----Original Message-----
From: linux-audio-dev-***@music.columbia.edu
[mailto:linux-audio-dev-***@music.columbia.edu]On Behalf Of Steve
Harris
Sent: Sunday, October 20, 2002 1:54 PM
To: linux-audio-***@music.columbia.edu
Subject: Re: [linux-audio-dev] Re: image problem [was Re: [Alsa-devel]
help for a levelmeter]
Post by David Gerard Matthews
Post by Mark Knecht
I think that some real program management is required.
Look at what the market wants and needs, (audio, MIDI, soft synths,
plugins,
scoring, automation, etc.) write it down somewhere and then do an honest
assessment of where Linux audio solutions are.
I don't think lack of awareness is the problem. The problem is that
most Linux audio apps are developed by
people who have full-time jobs doing other things. The problems
involved in designing audio apps are so great
that even those people who are able to work full time on Linux audio are
often stupmed as to how to implement
This might be true on the macro scale, "what we need is a complete DAW
that does everything" ;) but I, personally have no idea what the average
musician wants from plugins. My needs are pretty esoteric, and I'm trying
not to flood the LADSPA scene with bizarre, special purpose plugins (belive
it or not ;).

Which brings me to my off-topic rant, I think its my turn again ;)

Don't be afraid to criticise. I am very thick skinned, and wont be
offended if you tell me that plugin X is crap, or should be different. Or
something. Complain! Just because you're not paying me doesn't mean I
don't care if it sucks.

I have a bigish todo list, but some of the things on it are truly hard,
however if what you want is easy, it will get done quickly, and if enough
people want something I will be more motivated to pull my finger out.

</rant>

- Steve
Benno Senoner
2002-10-22 00:31:01 UTC
Permalink
Post by Lea Anthony
I don't know if the 3 points I've made have already been done, I'm new
to LAD, but they are important. Especially 3 as it gives a "migration
path" to existing windoze users. I know, I know, DirectX plugins are
written against Microsoft libraries, but how come mplayer on Linux can
use windows binaries (codecs) in it's system? Could the same not be
done
for audio? Surely it's the same principle? (Media data input, process,
media data ouput).
Yes this should be possibile since both DirectX and VST are documented
APIs.
Form a latency point of view, I am not sure how this works out, but I
believe the process() calls do not involve windows specific stuff so the
plugs should perform quite well on a low latency kernel.
Of course almost any DX, VST plugin do have a GUI.
The ideal would be letting wine to display the GUI part while executing
the process() stuff directly.
I am not a wine expert so I cannot say how difficult this can be, but
given that wine is able to execute beasts like Word and Excel I guess
it has not problems with plugin GUIs.

Indeed the ability to run DX and VST on Linux would be a good selling
point for pro audio on linux but there is still lot to do in the fields
of basic audio platform infrastructure and integration of the different
components.

cheers,
Benno
Steve Harris
2002-10-22 11:27:00 UTC
Permalink
Post by Benno Senoner
Indeed the ability to run DX and VST on Linux would be a good selling
point for pro audio on linux but there is still lot to do in the fields
of basic audio platform infrastructure and integration of the different
components.
I'm not sure this would be a great idea. It looks good to say we support
90% of DX plugins (or whatever), but it might just disuade developers from
porting to native linux binaries. You can bet DX emulation would be slower
and less reliable than native Windows, giving the impression that Linux
was slow and unreliable.

Given that many of the respected plugin developers allready release for
Windows, Macos and TDM, I dont think they would have a problem with adding
Linux to that list. Not that there is an API for them to port to, but that
is another matter...

- Steve
Lea Anthony
2002-10-23 01:21:00 UTC
Permalink
This is the same issue as with Linux Games. Does wine hurt or help?
Well, here's my take: If Linux doesn't run the software they're used to
then they wont use it in the first place. Once there is a marketbase,
then the NEXT generation of stuff would be written natively as they
would see that it gives them more benefit.

Wishing for people to write native apps for a system with no market is
like wishing Windows would die. It might happen, but it's not bloody
likely.

-Lea.
Post by Steve Harris
I'm not sure this would be a great idea. It looks good to say we support
90% of DX plugins (or whatever), but it might just disuade developers from
porting to native linux binaries. You can bet DX emulation would be slower
and less reliable than native Windows, giving the impression that Linux
was slow and unreliable.
Given that many of the respected plugin developers allready release for
Windows, Macos and TDM, I dont think they would have a problem with adding
Linux to that list. Not that there is an API for them to port to, but that
is another matter...
- Steve
Paul Davis
2002-10-22 02:25:01 UTC
Permalink
Post by Benno Senoner
Post by Lea Anthony
I don't know if the 3 points I've made have already been done, I'm new
to LAD, but they are important. Especially 3 as it gives a "migration
path" to existing windoze users. I know, I know, DirectX plugins are
written against Microsoft libraries, but how come mplayer on Linux can
use windows binaries (codecs) in it's system? Could the same not be
done
for audio? Surely it's the same principle? (Media data input, process,
media data ouput).
Yes this should be possibile since both DirectX and VST are documented
APIs.
VST is a C++ API, and thus its easy for plugins to end up having
dependencies on MSVCRT.dll or its equivalent with other compilers,
which is not available under linux, even with wine.

DirectX is more of a possibility, since its C API (though i am not
sure if this avoid dependencies on unavailable MS system calls - i
don't know what state wine is in). But there are not very many "pro
audio" plugins under DirectX - lots of instruments and wierdo
enthusiast FX, but not the sort of stuff that ProTools, Nuendo and
Logic users are inclined towards.

the reason mplayer works is either:

* they are using wine to help them out
* the codecs are free of all MS system calls

i'd think that the second one was likely. unfortunately for plugins,
especially DirectX ones that come with a GUI, this is not likely to be
the case there. plugins are at least an order of magnitude more
complex than most codec modules.

--p
Lea Anthony
2002-10-22 09:34:00 UTC
Permalink
Post by Paul Davis
But there are not very many "pro
audio" plugins under DirectX - lots of instruments and wierdo
enthusiast FX, but not the sort of stuff that ProTools, Nuendo and
Logic users are inclined towards.
Waaahh!!! I would disagree. The Waves bundles are seriously good and
goes for thousands of dollars. Hardly low end stuff. But I do agree that
there is a lot of what you say. The instruments are DXi though.
Post by Paul Davis
* they are using wine to help them out
* the codecs are free of all MS system calls
i'd think that the second one was likely. unfortunately for plugins,
especially DirectX ones that come with a GUI, this is not likely to be
the case there. plugins are at least an order of magnitude more
complex than most codec modules.
I never said it would be easy :)

-Lea.
Sebastien Metrot
2002-10-22 10:15:01 UTC
Permalink
Hu, in fact it's the other way around: VST is a C ApI based of a very small
set of functions passing "opcodes" arround. It is wrapped with C++ on the
plugin side but you can writte C only VST plugins (well, I don't know of any
C only VST plugins anyway).
DirectX/DirectShow is totaly COM based and thus C++ is almost mandatory. Of
course you would be able to use COM objects in C by calling their methods
thru the virtual functions table but COM allready being a pain in C++ I
wouldn't advise anyone to go for this solution.

MSVCRT is just the equivalent of the gnu libc, most functions are the same
and the missing ones can be emulated quite easily with the corresponding set
of call to the libc. The main problem would more be the dependency to the
Win32 API thru gdi32.dll, user32.dll, kernel32.dll, etc... But all of these
are allready well emulated by wine (you woulnd't be able to run word or
winamp with wine without it).

Just my 0.02 euros,

Sebastien

----- Original Message -----
From: "Paul Davis" <***@linuxaudiosystems.com>
To: <linux-audio-***@music.columbia.edu>
Sent: Tuesday, October 22, 2002 3:23 AM
Subject: Re: [linux-audio-dev] Re: The Image (usablity) problem from a
Musicians point of view
Post by Paul Davis
VST is a C++ API, and thus its easy for plugins to end up having
dependencies on MSVCRT.dll or its equivalent with other compilers,
which is not available under linux, even with wine.
DirectX is more of a possibility, since its C API (though i am not
sure if this avoid dependencies on unavailable MS system calls - i
don't know what state wine is in). But there are not very many "pro
audio" plugins under DirectX - lots of instruments and wierdo
enthusiast FX, but not the sort of stuff that ProTools, Nuendo and
Logic users are inclined towards.
Paul Davis
2002-10-22 02:29:01 UTC
Permalink
Post by Peter L Jones
So why, having studied the docs, am I completely stumped with jack? It
refuses to play. I don't consider any solution based on a piece of software
_I_ can't operate suitable for general use.
JACK *isn't* intended for general use, and i get tired of suggestions
that it should be. there are lots of people working on solutions for
"general use". JACK is intended for people who are serious about
audio. in particular, although it might work with crappy consumer
audio interfaces, its not intended to do so. if you can't run JACK at
all, you basically have a box that wouldn't run an ASIO device driver
under windows or macos. there's not much we can do about that except
to point you at kernel adjustments (like hdparm) and ask that you
check other mailing lists to see if your audio interface, video
interface, etc. are known to be horrible in some respect.

JACK is not yet finished, and it has some definite usability issues
that need to be resolved. but it is not, and i hope will never be
(primarily) a general purpose sound server.

alternatively, there might be a bug in JACK. perhaps you can help us
find it.

--p
Conrad Parker
2002-10-22 03:12:00 UTC
Permalink
Hi Paul,

it might save you some hassles if you changed the intro to jack's web
pages, which currently read:

JACK is a low-latency audio server, written primarily for the
GNU/Linux operating system. It can connect a number of different
applications to an audio device, as well as allowing them to share
audio between themselves.

that, by itself, sounds to the average user an awful lot like a general
purpose audio server. Perhaps what you wrote in the email below, comparing
JACK to ASIO, would be more appropriate.

Conrad.
Post by Paul Davis
Post by Peter L Jones
So why, having studied the docs, am I completely stumped with jack? It
refuses to play. I don't consider any solution based on a piece of software
_I_ can't operate suitable for general use.
JACK *isn't* intended for general use, and i get tired of suggestions
that it should be. there are lots of people working on solutions for
"general use". JACK is intended for people who are serious about
audio. in particular, although it might work with crappy consumer
audio interfaces, its not intended to do so. if you can't run JACK at
all, you basically have a box that wouldn't run an ASIO device driver
under windows or macos. there's not much we can do about that except
to point you at kernel adjustments (like hdparm) and ask that you
check other mailing lists to see if your audio interface, video
interface, etc. are known to be horrible in some respect.
JACK is not yet finished, and it has some definite usability issues
that need to be resolved. but it is not, and i hope will never be
(primarily) a general purpose sound server.
alternatively, there might be a bug in JACK. perhaps you can help us
find it.
--p
Joshua Haberman
2002-10-22 04:49:00 UTC
Permalink
Post by Paul Davis
Post by Peter L Jones
So why, having studied the docs, am I completely stumped with jack? It
refuses to play. I don't consider any solution based on a piece of software
_I_ can't operate suitable for general use.
JACK *isn't* intended for general use, and i get tired of suggestions
that it should be. there are lots of people working on solutions for
"general use". JACK is intended for people who are serious about
audio.
I don't understand this attitude. I think it hinders acceptance of JACK
(even for serious audio) and it contributes to further fragmentation of
the Linux audio world.

If you would rather everyday applications not use JACK, what should they
be using instead? OSS is simple but limited, and spotty
drivers/implementations make it difficult to write robust code. It will
soon be available only through emulation. It forces use of the blocking
model.

ALSA is very powerful and complete, but very complex. This will make
for lots of application that "support" ALSA, but badly. Writing in a
blocking style is not difficult, but writing in callback style using
poll() is basically impossible without studying
jack/drivers/alsa/alsa_driver.c for a week.

This leaves JACK: easy to program for (provided you know the constraints
on the callback's behavoir), uses the callback model, automatically allows
for sharing of data between applictions. The only hitch is getting JACK
up and running.

Writing applications that target JACK will always be a liability if JACK
remains a rare and esoteric platform. OSS will be the safe choice,
followed by ALSA once Linux 2.6 is in widespread use. Applications that
you might find useful even in serious situations might opt to use OSS or
ALSA. Take the recent of announcement of the synth ZynAddSubFX, an
application that could be a very useful in a JACK pipeline. It was
written for OSS. I don't know why Nasca Paul chose the way he did, but
it is evident that JACK wasn't compelling to him, even though this is an
app that is ideal for use with JACK.

I fully understand that crappy consumer interfaces are not going to be
able to run JACK with 128 frames per period, but surely any card could
handle JACK if you bumped that size high enough. Is there any reason
that a particular card/computer could not handle JACK at all, at any
period size? I can't imagine why -- JACK is only making ALSA calls. If
JACK won't work on a crappy consumer card, does this mean no ALSA app
would either?

What is the harm in all applications, XMMS up to Ardour, using JACK? I can
only see benefits.

Josh
--
"Only Angels can sing that high, and only dogs can hear it." -- James Evans
Steve Harris
2002-10-22 11:18:01 UTC
Permalink
Post by Joshua Haberman
I fully understand that crappy consumer interfaces are not going to be
able to run JACK with 128 frames per period, but surely any card could
handle JACK if you bumped that size high enough. Is there any reason
that a particular card/computer could not handle JACK at all, at any
period size? I can't imagine why -- JACK is only making ALSA calls. If
JACK won't work on a crappy consumer card, does this mean no ALSA app
would either?
I can't answer this properly, but there is some issue to with mmap mode I
believe. It is a very small number of cards that dont work.
Post by Joshua Haberman
What is the harm in all applications, XMMS up to Ardour, using JACK? I can
only see benefits.
Its fine, as long as it doesn't alter the design of jack. Theres no point
adapting jack to suit the needs of consumer apps if it will increase the
latency or make it less stable at low buffer siezes. Thats the reason it
exists. There are plenty of alternatives for xmms type things, eg. MAS.

It is a good idea (IMHO) for jack to have interface clients to some of
these consumer port sharing systems, so you can seamlessly interface
between them. Like the alsa interface Taybin mentioned.

If you look at the interfaces of things like MAS, ESD and Arts, they are
very different to jack. If someone writes an mp3 player, with a callback
design and makes it realtime safe then theres no reason it can't be a jack
client, c.f. alsplayer.

- Steve
Paul Winkler
2002-10-22 17:46:01 UTC
Permalink
Post by Steve Harris
I can't answer this properly, but there is some issue to with mmap mode I
believe. It is a very small number of cards that dont work.
We should compile a list of them, and maybe put it in the JACK FAQ.

--PW

--

Paul Winkler
"Welcome to Muppet Labs, where the future is made - today!"
Peter L Jones
2002-10-22 19:58:01 UTC
Permalink
Post by Paul Winkler
Post by Steve Harris
I can't answer this properly, but there is some issue to with mmap mode I
believe. It is a very small number of cards that dont work.
We should compile a list of them, and maybe put it in the JACK FAQ.
--PW
I'd much rather have a list of current cards that work _well_ than a lists of
cards that don't.

The current ALSA card list just says whether or not a card has a driver (and
the state of that driver). It doesn't indicate how well the card is going to
work.

I don't want to have to learn about DSPs and stuff to be able to identify a
_good_ sound card. I've currently got a shortlist for my next machine:
* MidiMan Delta Audiophile 2496 (Envy24)
* VideoLogic SonicFury OEM (CS4360)
* Creative SB PCI 128 (ES1371)

I've read the specs and looked around various review sites. Nothing anywhere
tells me how well they're going to work. Or does it? Am I failing to find
some secret source of information?

All these things just make life _easier_. I want to get on with developing
code, not wondering why my hardware isn't performing. I don't _want_ to have
to learn _that_ part of the system. Because I'll only need to do it once:
when I spec the next machine. (The next time I spec a machine, everything I
found out last time will be out of date.)

-- Peter
ian
2002-10-22 03:09:00 UTC
Permalink
While jack isn't intended for general use, it definitely isn't hard to use
at all. It's a fantastic piece of software - easy to use (and even easier
to write applications that use it). It's one of the best things that ever
happened for linux audio.
Perhaps Peter is having trouble getting jackd running? Try:
jackd -d alsa
That should get it running with the default parameters, and let you
connect clients and hear them. There are also some example clients
included with it.
Good luck with it,
Ian
Post by Paul Davis
Post by Peter L Jones
So why, having studied the docs, am I completely stumped with jack? It
refuses to play. I don't consider any solution based on a piece of software
_I_ can't operate suitable for general use.
JACK *isn't* intended for general use, and i get tired of suggestions
that it should be. there are lots of people working on solutions for
"general use". JACK is intended for people who are serious about
audio. in particular, although it might work with crappy consumer
audio interfaces, its not intended to do so. if you can't run JACK at
all, you basically have a box that wouldn't run an ASIO device driver
under windows or macos. there's not much we can do about that except
to point you at kernel adjustments (like hdparm) and ask that you
check other mailing lists to see if your audio interface, video
interface, etc. are known to be horrible in some respect.
JACK is not yet finished, and it has some definite usability issues
that need to be resolved. but it is not, and i hope will never be
(primarily) a general purpose sound server.
alternatively, there might be a bug in JACK. perhaps you can help us
find it.
--p
c***@easystreet.com
2002-10-22 04:11:01 UTC
Permalink
Post by Steve Harris
Post by Patrick Shirkey
Some of us have really been trying for a while now. I think they would
have to do something if they were overwhelmed with success stories from
our community. But that requires people to pull finger and actually
write to the publications and inform them. A campaign along these lines
could be extremely effective at gathering publicity.
Or anoyning people in the industry. My experince of music proffesions in
the UK is that they are largly interested in what we have to offer, but I
think they will rapidly loose interest if we keep pestering them.
I'm sure that I can get column inches in the music press convering linux,
but I can do that *once*. If it turns out to be interesting to people out
there I'm sure it will continue. SOS for example run PC and Apple Notes
sections, a Linux Notes section would be a great platorm for our work, but
badgering the edtiors for one just isn't going to help.
- Steve
So would it help to provide them with articles?
Having lurked a while, i'd think generating more content would
be very useful. Plus it would add to the general amount of information
available.
cliffw
Ivica Bukvic
2002-10-22 05:00:01 UTC
Permalink
Post by Richard Bown
Post by Paul Davis
Post by Peter L Jones
So why, having studied the docs, am I completely stumped with jack?
It
Post by Richard Bown
Post by Paul Davis
Post by Peter L Jones
refuses to play. I don't consider any solution based on a piece of
software
Post by Paul Davis
Post by Peter L Jones
_I_ can't operate suitable for general use.
JACK *isn't* intended for general use, and i get tired of
suggestions
Post by Richard Bown
Post by Paul Davis
that it should be. there are lots of people working on solutions for
"general use". JACK is intended for people who are serious about
audio. in particular, although it might work with crappy consumer
audio interfaces, its not intended to do so. if you can't run JACK
at
Post by Richard Bown
Post by Paul Davis
all, you basically have a box that wouldn't run an ASIO device
driver
Post by Richard Bown
Post by Paul Davis
under windows or macos.
So, in essence Jack is yet another ASIO wannabe. If I wanted ASIO, I'd
be working on Windows or MacOS.

What about making it more like Core Audio on steroids where everything
can be low latency, or high latency, where USER HAS THE CHOICE? This
"Jackd is only for pro's" sounds too much like Apple die-hard fan
zealotry to me, something that I readily detest.
Post by Richard Bown
Post by Paul Davis
there's not much we can do about that except
to point you at kernel adjustments (like hdparm) and ask that you
check other mailing lists to see if your audio interface, video
interface, etc. are known to be horrible in some respect.
JACK is not yet finished, and it has some definite usability issues
that need to be resolved. but it is not, and i hope will never be
(primarily) a general purpose sound server.
alternatively, there might be a bug in JACK. perhaps you can help us
find it.
--p
And as long as you view JACK as that, it will have a very small user
base and hence very small pool of audio apps that will support it. All
this will lead to the fact that, no matter how good JACK is (or is
supposed to be), it will be always a questionable solution, since a lot
of good PRO apps (contrary to your definition of OSS-based "toys" in one
of your previous e-mails) do not, and will not support it (i.e. RTcmix)
[either due to fact the apps are not being constantly updated any more,
or maybe the developers are skeptical about porting to Jack when there
are so few apps ported into its framework], while a few PRO apps (i.e.
Ardour) will.

This will create an unnecessary polarization in an already heavily
fragmented audio community (oss vs. alsa, esd vs. asd vs. artsd vs.
gstreamer vs. jackd etc.). Linux is supposed to be all-inclusive and
free. Most of us in Linux strive to make everything work under it both
hardware-wise and software-wise, as well as being backwards-compatible.
Yet, in this case if the audio app does not support JACK, then it's
either a "toy" or basically whomever wants to use it is screwed and has
to make a choice whether to use jack-based apps or work with oss drivers
coupled with some kind of artsd high latency daemon (that at least let's
you do multiple opens in software or select mic inputs on the mixer --
something that is not the case with Alsa + artsd). I do not want to have
my artistic ideas limited by the questionable software limitations. Do
you?

If you really want the JACK to take off, then you should look not only
forwards, but also backwards, and find a relatively viable solution
(even if it is at the expense of the latency) that will work with 1000+
decent apps that have not been ported to JACK framework, thus leaving
the issue of latency for the user to choose.

And if the only explanation to this problem is "they need to port their
apps to JACK", while there is no effort to meet the user needs at least
half-way by offering an easy interfacing for apps that may not be ported
to JACK in the recent future for whatever reasons, then I see that as
sheer arrogance. I am not only interested in using Ecasound, Ardour,
FreqTweak, and Pd for my music making purposes, neither is a majority of
other Linux users.

Case and point, I may want to use ardour, but if I take a break and want
to listen to some mp3's on an un-jackified player (such as xmms, for
instance), how user-friendly would it be to have to save session, close
ardour, close jackd, and only then start xmms, and then after 10 minutes
do all that in reverse? Why couldn't xmms simply connect automagically
to jackd by jackd detecting simple oss-open-dsp-resource call? If it
isn't user-friendly, who will want to deal with it, except for Linux
die-hard fans (one of them being myself)? Even you mentioned your
intentions of selling ardour-installed computers. Who will want to deal
with all this configuration crud? People in studios do not want to hear
about jackd -d alsa or hw:0,0 crap, nor do they want to buy a computer
that will do only ardour. They just want it to work, and while working
on pro audio software, they may still want to hear audible alerts that
their laptop is running out of battery or that they have a pending
appointment. Instead they will get mind-boggling errors, such as
/dev/dsp resource busy, and similar junk...

Neither will the commercial companies want to touch jackd with a 20-foot
pole if there will be an aura of limited hw it works with (that
automatically limits a pool of people that may potentially purchase an
app) and in addition requires a 100-page FAQ section to be shipped with
every product, just to cover all that can possibly go wrong during the
jack init.

That's what is wrong with Jack and that's why you are getting so many
requests to do the obvious. Comments like these only make the situation
worse. Jack should (and does!) allow for higher latency work so that it
can accommodate itself to crappier audio hw.

What is yet to be determined is for example why am I getting xruns all
over the place after having jackd run for 10 minutes even at very high
buffer sizes and having it sit idle for most of those 10 minutes?

That being said, I have been at least somewhat convinced that Jack is
possibly the way to go, and after some thinking, I've decided to attempt
porting RTcmix into the Jack framework. Only time will now tell whether
this was worth it or not. Yet, comments like these make me again
reconsider my move before I dig into some serious coding with jackd and
use my precious time on stuff that simply may not take off...

Regards,

Ico
David Gerard Matthews
2002-10-22 22:41:00 UTC
Permalink
Post by Ivica Bukvic
That being said, I have been at least somewhat convinced that Jack is
possibly the way to go, and after some thinking, I've decided to attempt
porting RTcmix into the Jack framework. Only time will now tell whether
this was worth it or not.
Regards,
Ico
That was the most useful part of this email. I've hoping that someone
would port one of the Music N languages to JACK for some
time, and I certainly do not have the skills do it myself. Thank you
very much, Ico. I look forward to trying it out.
-dgm
Taybin Rutkin
2002-10-22 05:48:00 UTC
Permalink
Post by Ivica Bukvic
of good PRO apps (contrary to your definition of OSS-based "toys" in one
of your previous e-mails) do not, and will not support it (i.e. RTcmix)
[either due to fact the apps are not being constantly updated any more,
or maybe the developers are skeptical about porting to Jack when there
are so few apps ported into its framework], while a few PRO apps (i.e.
Ardour) will.
The problem is that OSS and ALSA based programs use the block on
read/write metaphor that kills latency. That's why they need to be
ported/rewritten to the non-blocking style. That jack forces the clients
to do so could probably be considered it's greatest contribution.
Post by Ivica Bukvic
fragmented audio community (oss vs. alsa, esd vs. asd vs. artsd vs.
gstreamer vs. jackd etc.). Linux is supposed to be all-inclusive and
free. Most of us in Linux strive to make everything work under it both
hardware-wise and software-wise, as well as being backwards-compatible.
Yet, in this case if the audio app does not support JACK, then it's
What needs to be done is for someone to implement alsa-server as a jack
client. This has been gone over before, the solution was found
(alsa-server), but no one did it.
Post by Ivica Bukvic
If you really want the JACK to take off, then you should look not only
forwards, but also backwards, and find a relatively viable solution
(even if it is at the expense of the latency) that will work with 1000+
decent apps that have not been ported to JACK framework, thus leaving
the issue of latency for the user to choose.
If latency is a choice for the user (and often it isn't) then they can
pick their sound server. Jack is a no-compromise low-latency server.
Post by Ivica Bukvic
Case and point, I may want to use ardour, but if I take a break and want
to listen to some mp3's on an un-jackified player (such as xmms, for
instance), how user-friendly would it be to have to save session, close
ardour, close jackd, and only then start xmms, and then after 10 minutes
This is unnecessary. I often run xmms and ardour at the same time. Xmms
doesn't talk to Ardour or Jack, but it doesn't interfere either. Of
course, I don't hit play while recording or playing in Ardour.
Post by Ivica Bukvic
Neither will the commercial companies want to touch jackd with a 20-foot
pole if there will be an aura of limited hw it works with (that
automatically limits a pool of people that may potentially purchase an
But companies write for ASIO. Certain software needs a promise of
low-latency.
Post by Ivica Bukvic
That's what is wrong with Jack and that's why you are getting so many
requests to do the obvious. Comments like these only make the situation
worse. Jack should (and does!) allow for higher latency work so that it
can accommodate itself to crappier audio hw.
Everything is about tradeoffs. The important design decision in jack was
to work in lowlatency. Allowing for higher latency would compromise that
decision.

And that's almost besides the point. You can have higher latencies. I
often run with a buffer of 8192. Horrible latency. But I never see an
xrun.
Post by Ivica Bukvic
What is yet to be determined is for example why am I getting xruns all
over the place after having jackd run for 10 minutes even at very high
buffer sizes and having it sit idle for most of those 10 minutes?
Well, that really depends on your system. Latency is tricky. Heck,
digidesign only provides support on certain hardware configurations.

You might want to look at PortAudio also, which has jack as an output.

Taybin
--
http://www.piratesvsninjas.com
Kai Vehmanen
2002-10-22 12:01:00 UTC
Permalink
Post by Lea Anthony
Sure, there is probably a lot more but I'm just gathering my thoughts
here. What I'm afraid of is that LAD will end up with the same problems
as most Linux distros suffer from: Bloat. Choice is good, but do I
really need 7 text editors on my system? No. What I believe would
benefit LAD, and correct me if I'm wrong, is to create a 'big picture',
a complete DAW system. It should consist of AN audio editor, AN audio
recorder, A sample editor, etc. Like I said, choice is great but
musicians don't give a hoot about choice, they want something that
works, not 7 things that are half done. If all effort was pushed in this
direction, I believe we would end up with a quality system that the
world would take seriously.
This is something that has been proposed quite a few times here.
Who's the "we" here? I'd say this is something that has to be
done by a volunteer group (think of debian), company (think of redhat) or
a mixture of two. Currently the best example of this concept is Planet
CCRMA.

If this kind of project is succesful, it will motivate individual
development projects to improve their offerings so that their project
get included in the "promo-projects". If a company would do this, it
could allocate resources to those areas of development that are lacking.

Of course, one possibility is that this kind of group is formed
here on linux-audio-dev and linux-audio-user, but you shouldn't
expect too much help from the individual projects. In the end,
the reason why so much (high-quality) development is happening
here is that people are scratching their itches, not because developers
are trying to create a marketable whole. And I think this is
good for all involved. The other option is to have a group
of not-so-motivated developers aiming at a marketable whole... hmm,
sounds awfully lot like traditional commercial development. ;)

But of course, for any kind of promo, or Linux audio interest group,
it would be silly not to participate on linux-audio-{dev,user},
alsa-lists, and other central lists. I think this is why PlanetCCRMA has
been so popular. On the other hand, Demudi and Agnula seem, at least to
me, more like ivory-tower type of projects. They don't have much of
a presence on any of the mentioned lists.

And btw; it's good to note that participants in free/open-sw projects
are not just volunteers and/or enthusiasts. There can also be companies
involved that just want to scratch their itches, and don't have
a huge interest in marketing Linux audio. I think it's good to keep
these two interests separate.

--
http://www.eca.cx
Audio software for Linux!
Patrick Shirkey
2002-10-22 12:01:31 UTC
Permalink
Post by Richard Bown
Post by Patrick Shirkey
But am I just wasting my breath because the Agnula crew are going to
do all the work for us?
Oh well _now_ you come on to my pet subject.
Post by Patrick Shirkey
Anyone from the Agnula project have a position on this?
A while ago I got involved in a flamespat with the head honcho of AGNULA
when I suggested that they should improve their communication with the
rest of the LAD community and specifically with the development teams.
I think we'd pretty much all like to know what's happening with AGNULA
(apart from the minutes of their meetings) and naively I saw it as
their job to tell us and be nice to us.
While they do have selective communication with those that they consider
to be key people I think my fundamental mistake was to actually think
of AGNULA as an organisation. While it appears to be an organisation
it's really just a tech project - it's run by geeks and it will aim to
deliver some packaged apps and code in the time allowed. Once it's
packaged it'll ship and LAD type projects will get exposure to the rest
of the world through their distro. AFAICT that's the deal. While
that's not a bad deal of course I think AGNULA should have more of a
personality and a PR role with and in the LAD community. I've said in
the past that I think it'd benefit "them" and "us".
But hey. I'm not going to get on my hobby horse again over that one.
No chance. No sir.
Too late :)

So we are not wasting our time to debate this. There is a real problem
that the professional side of this community is not really taking into
account.

I was sceptical that the Agnula team would be doing massive promotional
campaigns.

Peter you said that if we intend to make money out of Linux Audio we
*should* be paying for it. Well doesn't that alsao apply to studios and
professionals who intend solely to use the finished products to make money?

Patrick.







--
Kai Vehmanen
2002-10-22 12:04:00 UTC
Permalink
Post by Conrad Parker
it might save you some hassles if you changed the intro to jack's web
JACK is a low-latency audio server, written primarily for the
GNU/Linux operating system. It can connect a number of different
applications to an audio device, as well as allowing them to share
audio between themselves.
that, by itself, sounds to the average user an awful lot like a general
purpose audio server. Perhaps what you wrote in the email below, comparing
JACK to ASIO, would be more appropriate.
But the second paragraph of the intro basicly already mentions
the focus:

--cut--
JACK is different from other audio server efforts in that it has been
designed from the ground up to be suitable for professional audio work.
This means that it focuses on two key areas: synchronous execution of all
clients, and low latency operation.
--cut--
--
http://www.eca.cx
Audio software for Linux!
Kai Vehmanen
2002-10-22 12:59:01 UTC
Permalink
Post by Paul Davis
JACK *isn't* intended for general use, and i get tired of suggestions
that it should be. there are lots of people working on solutions for
"general use". JACK is intended for people who are serious about
audio.
I'd like to add that not all JACK developers are as strict about this as
Paul ;), but it's true that something more concrete than
suggestions/requests are needed. Technical proposals that extend JACK's
usability without sacrificing the low-latency and synchronous-execution
qualities, are very welcome. I don't think this is an impossible task.

Btw; I also think the continuous flow of negative-ish comments concerning
JACK is a bit unreasonable. There are still lots of work to be done in the
low-latency area and this work of course has top-priority for current
development team.
Post by Paul Davis
audio interfaces, its not intended to do so. if you can't run JACK at
all, you basically have a box that wouldn't run an ASIO device driver
under windows or macos. there's not much we can do about that except
to point you at kernel adjustments (like hdparm) and ask that you
check other mailing lists to see if your audio interface, video
interface, etc. are known to be horrible in some respect.
And I think you can run JACK using pretty much any ALSA-supported
soundcard. It's just that we cannot guarantee good performance or flawless
operation in these cases. These cards will also cause problems to other
applications. It's just that JACK makes these problems much more explicit.
Post by Paul Davis
JACK is not yet finished, and it has some definite usability issues
that need to be resolved. but it is not, and i hope will never be
(primarily) a general purpose sound server.
In other words, development&testing help is welcome!
--
http://www.eca.cx
Audio software for Linux!
Peter L Jones
2002-10-22 21:45:01 UTC
Permalink
On Tuesday 22 Oct 2002 12:55, Kai Vehmanen wrote:
[snip]
Post by Kai Vehmanen
Post by Paul Davis
JACK is not yet finished, and it has some definite usability issues
that need to be resolved. but it is not, and i hope will never be
(primarily) a general purpose sound server.
In other words, development&testing help is welcome!
I'd love to help. But at the moment I don't have the support I need to
determine whether or not I can.

I understand that getting low latency is an extremely complex issue. What I'd
like to see, though, is some tool that will step me through a problem solving
session to identify whether I really have done everything possible and I'm
going to have to suffer.

When I run latencytest0.42-png from ***@gardena.net, I get about 99% sub
2ms latency. But jack still complains of xruns of about 50ms. There's
something here I'm simply failing to understand... but I don't know where to
start investigating.

-- Peter
Kai Vehmanen
2002-10-22 13:55:02 UTC
Permalink
Post by Ivica Bukvic
And as long as you view JACK as that, it will have a very small user
base and hence very small pool of audio apps that will support it. All
this will lead to the fact that, no matter how good JACK is (or is
supposed to be), it will be always a questionable solution, since a lot
I think that JACK will become a huge success not because of the
server technology, but because of the applications. FreqTweak and
Meterbridge are two very good examples of this. If these apps
had read from /dev/dsp and wrote to /dev/dsp, they would have been
interesting acquaintances, but it would have been difficult to actually
use them in real work. But now with JACK, they are tools that you can
really _use_!

Few more apps like this and every Linux audio developer is going to be
very tempted to port their app to JACK.

Mark my words, JACK's going to be big. :)
Post by Ivica Bukvic
This will create an unnecessary polarization in an already heavily
fragmented audio community (oss vs. alsa, esd vs. asd vs. artsd vs.
gstreamer vs. jackd etc.). Linux is supposed to be all-inclusive and
Gstreamer already has JACK support btw.
Post by Ivica Bukvic
If you really want the JACK to take off, then you should look not only
forwards, but also backwards, and find a relatively viable solution
(even if it is at the expense of the latency) that will work with 1000+
decent apps that have not been ported to JACK framework, thus leaving
the issue of latency for the user to choose.
This can be done, but we need someone to do it. I've already posted
a message with a proposed design for an OSS-to-JACK gateway. But I
don't have time to do this myself and I cannot force anyone else to do
it either. What can I do? But I'm not too worried about this. I'm quite
sure someone will do this sooner or later.
Post by Ivica Bukvic
And if the only explanation to this problem is "they need to port their
apps to JACK", while there is no effort to meet the user needs at least
half-way by offering an easy interfacing for apps that may not be ported
to JACK in the recent future for whatever reasons, then I see that as
sheer arrogance.
Well, please consider our side. We are trying to solve a problem that
enables a new level of co-operationg between audio apps (see
http://eca.cx/laaga )... This work is not finished yet. If you go and read
recent jackit-devel messages from the archives, not everything is going
just fine and dandy. We (especially Paul) have had to do enourmous amount
of work to get where we are now and there's still work left. There are
still issues that we don't know for sure how to solve and so the work has
to continue. If this is arrogance, so be it. I really don't know how to
reply to you here.
Post by Ivica Bukvic
I am not only interested in using Ecasound, Ardour,
FreqTweak, and Pd for my music making purposes, neither is a majority of
other Linux users.
Btw, it's many more than that:

Alsaplayer
gstreamer
icsound
iiwusynth
MusE (since 0.6.0pre1)
Rosegarden
Rtsynth
Spiral Synth Modular

... note that this list contains almost all lad "heavy-weights". I've
never seen this level of co-operation between - some even directly competing -
Linux audio projects, and it's a very exciting development!
Post by Ivica Bukvic
Case and point, I may want to use ardour, but if I take a break and want
to listen to some mp3's on an un-jackified player (such as xmms, for
instance), how user-friendly would it be to have to save session, close
Use alsaplayer and let xmms authors know why you made the choice.
Post by Ivica Bukvic
do all that in reverse? Why couldn't xmms simply connect automagically
to jackd by jackd detecting simple oss-open-dsp-resource call? If it
Because nobody has implemented 1) JACK-plugin for xmms, 2) JACK OSS
gateway. We'd like to see both, but cannot force anyone to do them.
Post by Ivica Bukvic
Neither will the commercial companies want to touch jackd with a 20-foot
pole if there will be an aura of limited hw it works with (that
automatically limits a pool of people that may potentially purchase an
app) and in addition requires a 100-page FAQ section to be shipped with
Let's see about that. :)
Post by Ivica Bukvic
What is yet to be determined is for example why am I getting xruns all
over the place after having jackd run for 10 minutes even at very high
buffer sizes and having it sit idle for most of those 10 minutes?
Yes, that's why we are not working on OSS-to-JACK gateways. There's still
work to be done in the core functionality.
--
http://www.eca.cx
Audio software for Linux!
Paul Davis
2002-10-22 15:47:00 UTC
Permalink
Post by Kai Vehmanen
Post by Paul Davis
JACK *isn't* intended for general use, and i get tired of suggestions
that it should be. there are lots of people working on solutions for
"general use". JACK is intended for people who are serious about
audio.
I'd like to add that not all JACK developers are as strict about this as
Paul ;), but it's true that something more concrete than
actually, i'm not really as strict as i sometimes sound.

yes, i think it would be great if JACK can eventually serve as a
general purpose sound server (though an even better intermediate goal
would be get to all apps to use a callback model). but i don't want to
get distracted by that goal when there are still some very difficult
issues standing in the way of 100% reliable operation at low latency
settings. creating something that is a credible replacement for arts
or esd etc. is a very different exercise than what we are focused on
right now.
Post by Kai Vehmanen
And I think you can run JACK using pretty much any ALSA-supported
soundcard. It's just that we cannot guarantee good performance or flawless
operation in these cases. These cards will also cause problems to other
applications. It's just that JACK makes these problems much more explicit.
one set of problems arise with consumer interfaces that don't keep
their capture and playback streams in sync with each other. another
set of problems comes from thos interfaces that don't allow mmap, but
there are almost none of those in current production. another set of
problems arise with cards that have unusual buffer size/division
constraints. other than that, there's nothing about the way JACK uses
ALSA that stops it from working (as Kai said) on pretty much any ALSA
supported soundcard. almost any audio interface that someone who is
"into audio" would use work excellently with JACK (and, not
coincidentally, with ASIO).

and guess what? if there is, you can get the source code and you can
fix it (or reimplement the ALSA driver/client if its basic design is a
problem).

--p
Paul Davis
2002-10-22 15:49:01 UTC
Permalink
Post by Lea Anthony
Post by Paul Davis
But there are not very many "pro
audio" plugins under DirectX - lots of instruments and wierdo
enthusiast FX, but not the sort of stuff that ProTools, Nuendo and
Logic users are inclined towards.
Waaahh!!! I would disagree. The Waves bundles are seriously good and
goes for thousands of dollars. Hardly low end stuff.
thats very true. i forget about the Waves guys.
Paul Davis
2002-10-22 16:30:02 UTC
Permalink
Post by Steve Harris
Post by Paul Davis
all, you basically have a box that wouldn't run an ASIO device
driver
Post by Paul Davis
under windows or macos.
So, in essence Jack is yet another ASIO wannabe. If I wanted ASIO, I'd
be working on Windows or MacOS.
does it occur to you that there might actually be something *good*
about ASIO? that JACK might be trying to learn from what's good? and
that as a result, JACK might have similar behaviour with respect to
hardware design that ASIO does? does that make it an "ASIO wannabe"?
Post by Steve Harris
What about making it more like Core Audio on steroids where everything
can be low latency, or high latency, where USER HAS THE CHOICE? This
"Jackd is only for pro's" sounds too much like Apple die-hard fan
zealotry to me, something that I readily detest.
the reason for not doing this is that there isn't manpower to do it. i
am focused on JACK as the engine for a set of apps that i want to be
able use (and i want others to be able to use them) in pro audio, real
time, low latency environments. i don't have the hours (or the cash)
to support the development of a "joe user" sound server. if you do,
then please join the development team and help us out.
Post by Steve Harris
of good PRO apps (contrary to your definition of OSS-based "toys" in one
of your previous e-mails) do not, and will not support it (i.e. RTcmix)
RTcmix, as fabulous of a program as it is, doesn't meet my definition
of "pro audio". actually, "pro audio" is a bad term. i should stick
with stuff like "studios operated as profit-making entities and/or
real time performance with a mixture of electronic and acoustic sound
sources". i'll call SOPME/RTP from now on, OK?
Post by Steve Harris
This will create an unnecessary polarization in an already heavily
fragmented audio community (oss vs. alsa, esd vs. asd vs. artsd vs.
gstreamer vs. jackd etc.). Linux is supposed to be all-inclusive and
1) who said "linux is supposed to be all inclusive"? who?
2) there has never really been much of an oss vs. alsa debate. i have
never seen anyone suggest that oss was better than alsa, merely
that it was expedient to use it because it was there. well,
from 2.5/2.6/3.0, alsa will just "be there" too. so i suspect
that that particular debate is about to evaporate, though alsa's
continued support for the OSS API will not make it happen
too quickly.
3) the esd/artsd thing was resolved in favor of artsd by the GNOME
crew. KDE was already going with artsd.
4) gstreamer has nothing to do with JACK - its an architecture for
streaming data *within* a program.
Post by Steve Harris
Yet, in this case if the audio app does not support JACK, then it's
either a "toy" or basically whomever wants to use it is screwed and has
i never said that not supporting JACK makes something a toy. i noted
that most of the audio applications for linux are (1) written to use
OSS and (2) are toys. there are thousands of links to such programs on
dave's pages. the toys are fun, and often very useful. however, they
are not viable candidates to act as the basis of SOPME/RTP for most
people.
Post by Steve Harris
If you really want the JACK to take off, then you should look not only
as kai has noted, most of the apps i care about already have JACK
support. from my point of view, its already moderately successful.
Post by Steve Harris
And if the only explanation to this problem is "they need to port their
apps to JACK", while there is no effort to meet the user needs at least
half-way by offering an easy interfacing for apps that may not be ported
to JACK in the recent future for whatever reasons, then I see that as
sheer arrogance.
how about this as alternatives to arrogance?

* 3 kids, including one grumpy and irritable teenage boy, and
two girls who fight endlessly.
* a studio/office under construction
* a house still requiring some basic stuff after moving in
* a long list of bugs and TODO's for my primary software project
* hardly any income (a few US$100's) ever derived from
from linux audio work so far
* 2 CD's of live performances to mix down
* training for ultra-distance cycling racing
* sleep, food, music, sex and books

why should i be doing *anything* for "users" who aren't interested in
paying me, aren't interested in what i'm interested in, and keep
telling me they want things that i can give them but don't like the
package it comes in?
Post by Steve Harris
Case and point, I may want to use ardour, but if I take a break and want
to listen to some mp3's on an un-jackified player (such as xmms, for
instance), how user-friendly would it be to have to save session, close
ardour, close jackd, and only then start xmms, and then after 10 minutes
do all that in reverse? Why couldn't xmms simply connect automagically
to jackd by jackd detecting simple oss-open-dsp-resource call?
because the OSS API is so deeply *FUCKED* and makes this really hard
to do without user intervention!!! how many times do i and others have
to repeat this?

why don't you just spend $US60 on a decent audio interface that
supports hardware multiopen, and stop looking for software solutions?
the trident cards are nice, simple, reliable and cheap. 32 hardware
stereo streams.
Post by Steve Harris
Neither will the commercial companies want to touch jackd with a 20-foot
pole if there will be an aura of limited hw it works with (that
just like they won't touch ProTools TDM with a 20 foot pole despite it
being certified for only a couple of wintel based systems and it
requiring custom audio interfaces and other specific stuff?

just like they won't develop for MOTU's MAS, despite it being a 100%
proprietary solution that works only for MOTU systems?

just like they won't develop develop for ASIO, despite only certain
audio interfaces having ASIO drivers?
Post by Steve Harris
That's what is wrong with Jack and that's why you are getting so many
requests to do the obvious. Comments like these only make the situation
i'm not here to do what you feel is obvious. i'm here to do what i
think is the right thing to do and what satisfies my needs and plans
the best. if you want to influence me then paypal is a few clicks
away, but otherwise, exhortations about what users need will not
accomplish very much.

--p
Benno Senoner
2002-10-22 16:39:01 UTC
Permalink
If I remember correctly, the guy that wrote the VQF (an mp3-like codec)
plugin for xmms
(home page here:http://www.csn.ul.ie/~mel/projects/linux/vqfplugin/ ) used
wine to run the windows version of the audio codec under linux. Reading form
his page he has now switched to a native version of the codec but perhaps he
could share his experiences with us on this list. I'll try to concact him (if
he isn't already on the LAD list) and send him the URL of this thread.

cheers,
Benno
Paul Davis
2002-10-22 17:20:01 UTC
Permalink
Post by Sebastien Metrot
Hu, in fact it's the other way around: VST is a C ApI based of a very small
[ ... ]

sebastien - thanks a lot for the clarification. you are right about
VST being a C API in a fundamental sense, but i think it more than
notable that there are no C plugins, only C++ ones. i was simply wrong
about DX being C. thanks.

--p
Sebastien Metrot
2002-10-22 17:24:00 UTC
Permalink
Yes, sure, I'm pretty sure nobody ever made a pure C vstplugin. I'm not sure
about how Borland C & Delphi users manage to make plugins though. I believe
Delphi user only use the C API but this is becoming mostly rethorical now :)

Sebastien

----- Original Message -----
From: "Paul Davis" <***@linuxaudiosystems.com>
To: <linux-audio-***@music.columbia.edu>
Sent: Tuesday, October 22, 2002 6:18 PM
Subject: Re: [linux-audio-dev] Re: The Image (usablity) problem from a
Musicians point of view
Post by Paul Davis
Post by Sebastien Metrot
Hu, in fact it's the other way around: VST is a C ApI based of a very small
[ ... ]
sebastien - thanks a lot for the clarification. you are right about
VST being a C API in a fundamental sense, but i think it more than
notable that there are no C plugins, only C++ ones. i was simply wrong
about DX being C. thanks.
--p
Fernando Pablo Lopez-Lezcano
2002-10-22 18:38:01 UTC
Permalink
Patrick Shirkey
2002-10-22 20:33:00 UTC
Permalink
Post by Steve Harris
Post by Steve Harris
I can't answer this properly, but there is some issue to with mmap
mode I
Post by Steve Harris
believe. It is a very small number of cards that dont work.
We should compile a list of them, and maybe put it in the JACK FAQ.
--PW
I'd much rather have a list of current cards that work _well_ than a
lists of cards that don't.
The current ALSA card list just says whether or not a card has a
driver >(and the state of that driver). It doesn't indicate how well the
card >is going to work.
Post by Steve Harris
I don't want to have to learn about DSPs and stuff to be able to
identify a _good_ sound card. I've currently got a shortlist for my
* MidiMan Delta Audiophile 2496 (Envy24)
* VideoLogic SonicFury OEM (CS4360)
* Creative SB PCI 128 (ES1371)
I've read the specs and looked around various review sites. Nothing
anywhere tells me how well they're going to work. Or does it? Am I
failing to find some secret source of information?
All these things just make life _easier_. I want to get on with
developing code, not wondering why my hardware isn't performing. I
don't _want_ to have to learn _that_ part of the system. Because I'll
when I spec the next machine. (The next time I spec a machine,
everything I found out last time will be out of date.)
This is a good idea to have this support and you've picked the right
thread for asking for it. Currently there are only a handful of people
who have worked on the official ALSA docs. I have done 90% of the work
myself. It's great I'm learning heaps in the process and will definitely
think about how to make it possible to add the info you require.

Unfortunately we don't often get success stories on the ALSA lists so we
don't really know how well things work until someone says that it's
broken :(

As it is I have tried to provide a feedback inteface via the notes
additions in the docs. So far it is being used but not as much as it
could be. I guess it will just take time. You can lead a horse to water...

Do you have a specific idea envisioned for how we could present the info
more effectively or a way to make more people contribute their results?
I'm listening.
--
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.com
Http://www.djcj.org - The Linux Audio Users guide
========================================

"Um...symbol_get and symbol_put... They're
kindof like does anyone remember like get_symbol
and put_symbol I think we used to have..."
- Rusty Russell in his talk on the module subsystem
Peter L Jones
2002-10-22 22:41:42 UTC
Permalink
Post by Patrick Shirkey
Post by Steve Harris
All these things just make life _easier_. I want to get on with
developing code, not wondering why my hardware isn't performing. I
don't _want_ to have to learn _that_ part of the system. Because I'll
when I spec the next machine. (The next time I spec a machine,
everything I found out last time will be out of date.)
This is a good idea to have this support and you've picked the right
thread for asking for it. Currently there are only a handful of people
who have worked on the official ALSA docs. I have done 90% of the work
myself. It's great I'm learning heaps in the process and will definitely
think about how to make it possible to add the info you require.
Unfortunately we don't often get success stories on the ALSA lists so we
don't really know how well things work until someone says that it's
broken :(
Heh. the life of a software developer. You only get fault reports and feature
requests (that need to be delivered yesterday) :-).
Post by Patrick Shirkey
As it is I have tried to provide a feedback inteface via the notes
additions in the docs. So far it is being used but not as much as it
could be. I guess it will just take time. You can lead a horse to water...
Ah, yes... I ought to post a report on my Evolution 249 USB keyboard. Works a
treat (well, Clemens latest change isn't in my alsa driver yet...).
Post by Patrick Shirkey
Do you have a specific idea envisioned for how we could present the info
more effectively or a way to make more people contribute their results?
I'm listening.
I think the new website is a _huge_ improvement over the old, static, one.
Like I said elsewhere - I still don't really know enough about the hardware
side of audio to know _what_ I'm missing :-(

And getting the positive feedback ... maybe we could convince one of the large
PC mags to do a soundcard comparison on Linux/ALSA... :-)

If I knew enough to do a decent job, I'd happily nag everyone posting here,
individually, into submitting details of their hardware setup and how they
feel about their audio experience under Linux... :-)

-- Peter
Kai Vehmanen
2002-10-22 22:12:01 UTC
Permalink
Post by Peter L Jones
I don't want to have to learn about DSPs and stuff to be able to identify a
* MidiMan Delta Audiophile 2496 (Envy24)
* Creative SB PCI 128 (ES1371)
I've used both of these extensively with JACK and numerous other ALSA apps
and they work really well (full-duplex, low-latency use). Other
soundcards/chipsets that I've used:

- snd-intel8x0 (nice chipset, is suitable for low-latency use)
- snd-cs4281 (good for low-latency although has a max two-interrupts
per buffer limitation which can confuse apps)
- GUS MAX (this very, very old ISA-card can still beat a number of
today's crappy chipsets... I don't know whether to cry or laugh ;))

Cards that I have no personal experience with, but I've heard very
good things about:

- RME Digi9652

Beware:

- SB AWE models (ugh, crap!)
- Yamaha YMF7xx/DS-XG (some have reported that these work ok,
but in any case they have a max 3 periods limitation
similar to cs4281, which can confuse apps)

All in all, most of the PCI-cards supported by ALSA have fairly good
drivers.
--
http://www.eca.cx
Audio software for Linux!
Anthony
2002-10-22 22:22:01 UTC
Permalink
Post by Kai Vehmanen
- snd-intel8x0 (nice chipset, is suitable for low-latency use)
Actually, I've had terrible results with this. It could be due to the
fact that it got pushed to a higher IRQ by my other card, however.

--ant
Peter L Jones
2002-10-22 23:05:01 UTC
Permalink
On Tuesday 22 Oct 2002 22:07, Kai Vehmanen wrote:
Kai,

Many thanks for the reply.
Post by Kai Vehmanen
Post by Peter L Jones
I don't want to have to learn about DSPs and stuff to be able to identify
* MidiMan Delta Audiophile 2496 (Envy24)
* Creative SB PCI 128 (ES1371)
I've used both of these extensively with JACK and numerous other ALSA apps
and they work really well (full-duplex, low-latency use). Other
Heh. Now, one of these I have in my machine ((PII vintage) Celeron 400)
already. The other would set me back £150. Your comment makes me think
there's little to choose between them. So, simply upgrading my soundcard
from a £15 low end consumer-oriented unit to something costing 10 times the
price looks like getting me nothing. Or am I missing something? :-(
Post by Kai Vehmanen
- snd-intel8x0 (nice chipset, is suitable for low-latency use)
- snd-cs4281 (good for low-latency although has a max two-interrupts
per buffer limitation which can confuse apps)
- GUS MAX (this very, very old ISA-card can still beat a number of
today's crappy chipsets... I don't know whether to cry or laugh ;))
I noticed that the ENS1371 seems to have a better rating on one site I looked
than to EMU10K, so this doesn't surprise me!
Post by Kai Vehmanen
Cards that I have no personal experience with, but I've heard very
- RME Digi9652
- SB AWE models (ugh, crap!)
- Yamaha YMF7xx/DS-XG (some have reported that these work ok,
but in any case they have a max 3 periods limitation
similar to cs4281, which can confuse apps)
All in all, most of the PCI-cards supported by ALSA have fairly good
drivers.
But how do I compare one card with another? What should I be looking for?
How can I tell which will reduce the load on my computer and which will
increase the load? Is there any difference?
Kai Vehmanen
2002-10-22 22:15:01 UTC
Permalink
Post by Peter L Jones
2ms latency. But jack still complains of xruns of about 50ms. There's
something here I'm simply failing to understand... but I don't know where to
Are you running JACK as root with "-R" or with "-R --asio"? Do these 50ms
xruns occur even if you don't have any clients connected? If that's not
the case, what client apps you have tested with? Also, do these xruns
happen all by themself, or are you doing something at the same time (maybe
moving windows or something). Does the HD led go on when the xrun occurs
(kernel maybe syncing its caches)? What kernel, with low-latency patches,
with pre-emption enabled or not?
--
http://www.eca.cx
Audio software for Linux!
Ivica Bukvic
2002-10-22 22:22:29 UTC
Permalink
Post by Paul Davis
Post by Paul Davis
JACK *isn't* intended for general use, and i get tired of
suggestions that it should be.
<snip>
and then later...
Post by Paul Davis
the reason for not doing this is that there isn't manpower to do it. i
am focused on JACK as the engine for a set of apps that i want to be
able use (and i want others to be able to use them) in pro audio, real
time, low latency environments. i don't have the hours (or the cash)
to support the development of a "joe user" sound server. if you do,
then please join the development team and help us out.
Then explain it this way, and do not contradict yourself by initially
saying Jack will never replace other sound daemons, and then mention
that it is simply an issue that there is not enough manpower... Besides
Jack can be high-latency (up to 8192 buffer size), so it is already fit
to be used for purposes other than "pro" or SOPMF-whatever...
Post by Paul Davis
RTcmix, as fabulous of a program as it is, doesn't meet my definition
of "pro audio". actually, "pro audio" is a bad term. i should stick
with stuff like "studios operated as profit-making entities and/or
real time performance with a mixture of electronic and acoustic sound
sources". i'll call SOPME/RTP from now on, OK?
First off, I USE RTcmix for "real-time performance with a mixture of
electronic and acoustic sound sources," so obviously you have no idea
what RTcmix is. Sure, it did not have a fancy gui (although that just
changed a couple months ago with a new GUI from Dave Topper that makes
RTcmix look like another Pd-like product). Other thing is, it is VERY
LOW LATENCY, you can specify a single buffer size of 64 if you feel like
it, the only question is whether your computer will keep up with it and
how cpu intensive the process is. RTcmix has one of the best reverb,
flange, place, and move filters I've heard, it has its own sub-busses
(for mixing multiple filters), needless to mention dozens and dozens of
other incredible instruments. It could as well be much better than any
LADSPA plugin out there... Yet you say it's no good for commercial
market... Hmmm...

If you knew anything about the market, then you'd realize that as many
SOPME/RTP studios there are in the world, they don't stack up to the
amount of money educational institutions spend on building their
electronic music studios, and this is where apps like RTcmix are an
equal concern as Protools (even the university this list is hosted on
uses RTcmix). If you had realized that, you'd know you'd be making a lot
more money by selling your computers with Ardour and other stuff
preinstalled to institutions like these (yet the institutions want their
cpu's to do more than just Ardour). Just to give you a perspective, some
of the INDIVIDUAL University studios in the US spend over $100,000/year
for the new equipment/software. How much do the SOPME/RTP spend once
they equip it for the first time?
Post by Paul Davis
Post by Paul Davis
This will create an unnecessary polarization in an already heavily
fragmented audio community (oss vs. alsa, esd vs. asd vs. artsd vs.
gstreamer vs. jackd etc.). Linux is supposed to be all-inclusive and
1) who said "linux is supposed to be all inclusive"? who?
Show me any past hardware that is not any more compatible with Linux and
you'll know what I am talking about. Even if the device is not supported
by the current kernel, you can always find a module and recompile it.
That is by anyone's definition all-inclusive. Sure, some things do not
work yet, but will be there soon (and this is not the issue in this
case, since that falls into the forward-looking aspect).
Post by Paul Davis
i never said that not supporting JACK makes something a toy. i noted
that most of the audio applications for linux are (1) written to use
OSS and (2) are toys. there are thousands of links to such programs on
dave's pages. the toys are fun, and often very useful. however, they
are not viable candidates to act as the basis of SOPME/RTP for most
people.
But are commonly used in educational institutions for professional music
making purposes. Besides, please define "most people". I clearly see
split on this list in terms of interests, so at best it's 50/50.
Post by Paul Davis
why should i be doing *anything* for "users" who aren't interested in
paying me, aren't interested in what i'm interested in, and keep
telling me they want things that i can give them but don't like the
package it comes in?
Who said anything about you being the one who develops all this?

What I did say is that you should not propagate the idea that Jack is
never going to be an all-purpose sound daemon, when it is clear it could
fulfill that purpose. In the end, it should be user's choice what they
will do with it.

Besides, I'd gladly poll my resources to add this feature to Jack, but
the elusive alsa-server is in existence only in these discussions, alsa
docs are still skimpy, and on top of that I do need to familiarize with
the Jack's framework before I can contribute anything. Now why would I
contribute to a project that you are so strongly trying to separate from
having anything to do with what I am trying to contribute?
Post by Paul Davis
why don't you just spend $US60 on a decent audio interface that
supports hardware multiopen, and stop looking for software solutions?
the trident cards are nice, simple, reliable and cheap. 32 hardware
stereo streams.
Because most people who perform their music on concert venues DO NOT
WANT TO LUG ARROUND A TOWER, but rather have a laptop!!! Give me one
laptop that does multiple opens in Alsa RELIABLY (Maestro 3i does two
streams and hiccups on third and is not being used in newer laptops any
more anyhow, even the all-cherished RME Hammerfall DSP on which I spent
way much more than $60 does not do multiple opens (heck it does not work
at all for me, and from what I've seen for many others, in Linux) even
though it clearly stores audio into the memory buffer which could be
easily hacked to do downmixing of outgoing streams, yet it is not me who
has rights to the RME driver changing/updating, is it?)
Post by Paul Davis
i'm not here to do what you feel is obvious. i'm here to do what i
think is the right thing to do and what satisfies my needs and plans
the best.
Well, and that is the source of the problem. "What suits me" instead of
"what suits me and others around me." Besides, I never said it should be
you personally who should do it.

On one hand you complain how your life is tough, but when people propose
additions they are interested in and are willing to chip in their time
and energy, then you push them away with your "JACK *isn't* intended for
general use" statements...
Post by Paul Davis
if you want to influence me then paypal is a few clicks
away, but otherwise, exhortations about what users need will not
accomplish very much.
--p
I got a better idea, perhaps you should let other people chip in their
thoughts and efforts by not pushing them away in the first place...

Alternately, if you find that unacceptable, maybe Jack should be
branched off into another project that would allow this kind of
development to take place...

Cheers!

Ico
Kai Vehmanen
2002-10-22 22:47:01 UTC
Permalink
Btw; this a very interesting topic. Please, tell about your
experiences. By discussing these things in a public forum,
we are actually creating a nice searchable knowledgebase
for all current and future ALSA users!
Post by Anthony
Post by Kai Vehmanen
- snd-intel8x0 (nice chipset, is suitable for low-latency use)
Actually, I've had terrible results with this. It could be due to the
fact that it got pushed to a higher IRQ by my other card, however.
Hmm, what laptop/soundcard and what version of ALSA (the dma routines were
rewritten quite recently)? It's true that intel8x0 is used quite a few
different laptops/cards [1], so it's possible that not all work as well as
I've experienced, but as it's in any case the same driver on the audio
side, these problems shouldn't be common.

[1] {Intel,82801AA-ICH},"
"{Intel,82901AB-ICH0},"
"{Intel,82801BA-ICH2},"
"{Intel,82801CA-ICH3},"
"{Intel,82801DB-ICH4},"
"{Intel,MX440},"
"{SiS,SI7012},"
"{NVidia,NForce Audio},"
"{AMD,AMD768},"
"{AMD,AMD8111},"
"{ALI,M5455}
--
http://www.eca.cx
Audio software for Linux!
Anthony
2002-10-22 23:08:01 UTC
Permalink
Post by Kai Vehmanen
Btw; this a very interesting topic. Please, tell about your
experiences. By discussing these things in a public forum,
we are actually creating a nice searchable knowledgebase
for all current and future ALSA users!
Post by Anthony
Post by Kai Vehmanen
- snd-intel8x0 (nice chipset, is suitable for low-latency use)
Actually, I've had terrible results with this. It could be due to the
fact that it got pushed to a higher IRQ by my other card, however.
Hmm, what laptop/soundcard and what version of ALSA (the dma routines were
rewritten quite recently)? It's true that intel8x0 is used quite a few
different laptops/cards [1], so it's possible that not all work as well as
I've experienced, but as it's in any case the same driver on the audio
side, these problems shouldn't be common.
[1] {Intel,82801AA-ICH},"
"{Intel,82901AB-ICH0},"
"{Intel,82801BA-ICH2},"
"{Intel,82801CA-ICH3},"
"{Intel,82801DB-ICH4},"
One of the intel, but forget what revision. Its actually builtin to
some generic mobo (i.e. not laptop). The ALSA drivers were always
after they fixed some major issues. I think it may have been more due
to JACK which was no where near as reliable as it is now. I should try
it again soon when I have time. Actually I never intended to use it
for serious work, since the hiss is unbearable.

--ant
Paul Davis
2002-10-22 22:55:01 UTC
Permalink
Post by Kai Vehmanen
Post by Peter L Jones
2ms latency. But jack still complains of xruns of about 50ms. There's
something here I'm simply failing to understand... but I don't know where to
Are you running JACK as root with "-R" or with "-R --asio"? Do these 50ms
xruns occur even if you don't have any clients connected? If that's not
the case, what client apps you have tested with? Also, do these xruns
happen all by themself, or are you doing something at the same time (maybe
moving windows or something). Does the HD led go on when the xrun occurs
(kernel maybe syncing its caches)? What kernel, with low-latency patches,
with pre-emption enabled or not?
and finally, a general warning:

JACK tests a lot more of the kernel than benno's latencytest program
or andrew morton's rtc-based tester. that is because JACK requires not
only rapid interrupt servicing and return to user space, it also
requires absolutely correct scheduling between user space contexts
using pipe write(2) and poll(2) calls. if all JACK clients were
in-process, its performance characteristics would be identical, more
or less, to latencytest. but nothing except the ALSA client/driver are
in-process right now, and so if the kernel ever goofs up scheduling,
then whatever the characteristics of the clients, things will break.

the bad news is that the kernel (at least as of 2.4.19) *does* goof up
the scheduling. if anyone wonders why i'm so cranky today, its because
i am trying to discover why it does this, and to see if it can be
fixed without compiling and booting 2.5 (which probably doesn't behave
the same way).

with latencies above 10ms, you will likely not notice the problem i am
debugging. with latencies below that number, especially way below, at
least on an SMP system, you will not JACK to run reliably with
2.4.19+ll. for now. hopefully, this will be fixed soon.

none of the above applies to a system with just jackd+alsa
running. such cases are immune to the scheduling bug i am looking at,
and are more likely to be caused by other system activity that
involves improperly tuned subsystems (such as IDE drives).

--p
Kai Vehmanen
2002-10-22 23:02:01 UTC
Permalink
Post by David Gerard Matthews
That was the most useful part of this email. I've hoping that someone
would port one of the Music N languages to JACK for some
time, and I certainly do not have the skills do it myself. Thank you
Just in case you are not aware of these:

- icsound has JACK-support
-> http://agnula.org/~maurizio/icsound/
- there's patch for PD that provides JACK-support
-> http://sourceforge.net/mailarchive/message.php?msg_id=1169519
- supercollider's alpha version for Linux has JACK-support
-> http://www.cs.tu-berlin.de/~kerstens/pub/SuperCollider3-linux.tgz
- Paul Winkler has written a JACK driver for SAOL/sfront
-> not yet released, mail Paul :)

PS Nopes, it's not just alsaplayer, ardour and ecasound anymore. ;)
--
http://www.eca.cx
Audio software for Linux!
David Gerard Matthews
2002-10-22 23:29:40 UTC
Permalink
Post by Kai Vehmanen
Post by David Gerard Matthews
That was the most useful part of this email. I've hoping that someone
would port one of the Music N languages to JACK for some
time, and I certainly do not have the skills do it myself. Thank you
- icsound has JACK-support
-> http://agnula.org/~maurizio/icsound/
Actually, this was exactly the thing I'd been hoping for, since I
already know CSound and I'd have to learn RTCmix.
I'm already using PD with JACK (beautiful!), am psyched about the
possibility of SC on Linux (used the Mac version
a few years ago), and am curious about SAOL. Thanks for the links!
-dgm
Post by Kai Vehmanen
- there's patch for PD that provides JACK-support
-> http://sourceforge.net/mailarchive/message.php?msg_id=1169519
- supercollider's alpha version for Linux has JACK-support
-> http://www.cs.tu-berlin.de/~kerstens/pub/SuperCollider3-linux.tgz
- Paul Winkler has written a JACK driver for SAOL/sfront
-> not yet released, mail Paul :)
PS Nopes, it's not just alsaplayer, ardour and ecasound anymore. ;)
Kai Vehmanen
2002-10-22 23:27:32 UTC
Permalink
Post by Peter L Jones
Post by Kai Vehmanen
Post by Peter L Jones
* MidiMan Delta Audiophile 2496 (Envy24)
* Creative SB PCI 128 (ES1371)
I've used both of these extensively with JACK and numerous other ALSA apps
and they work really well (full-duplex, low-latency use). Other
Heh. Now, one of these I have in my machine ((PII vintage) Celeron 400)
already. The other would set me back £150. Your comment makes me think
there's little to choose between them. So, simply upgrading my soundcard
from a £15 low end consumer-oriented unit to something costing 10 times the
price looks like getting me nothing. Or am I missing something? :-(
Well, yes. ES1371 brings you 2ch in+out with max 48000Hz sampling rate,
and 16bit sample resolution. Midiman 2496 on the other hands provides up
to 96kHz sampling rate, 24bit sample resolution, 2ch in+out and digital
in+out. Check the specs from manufacturer's site.

And btw, I confused Audiophile with Delta44 (which I have, has 4ins +
4outs, no digital in/out). Both are based on the envy24 chipset, should
perform equally well. Please, correct me if I'm wrong.
Post by Peter L Jones
Post by Kai Vehmanen
- GUS MAX (this very, very old ISA-card can still beat a number of
today's crappy chipsets... I don't know whether to cry or laugh ;))
I noticed that the ENS1371 seems to have a better rating on one site I looked
than to EMU10K, so this doesn't surprise me!
Yup, I'll probably never get tired of the following slogan: "sb128
(ens1371) is the best creative card as it's the one they didn't make
themselves". :) Ok, maybe the current SB cards are better, but I'll
never forgive the company the disappointment their AWE64Gold caused me.
Such waste of money! ;)
Post by Peter L Jones
Post by Kai Vehmanen
All in all, most of the PCI-cards supported by ALSA have fairly good
drivers.
But how do I compare one card with another? What should I be looking for?
How can I tell which will reduce the load on my computer and which will
increase the load? Is there any difference?
Well, it depends on what you want to do. How many channels you need in
and/or out, do you need high-quality recording, do you need digital
ins/out, do you need hardware support for multi-open, etc, etc?

I'm not a hardware expert so I can't answer to all these questions, but I
can tell about the criteria I used when I selected my last card. My
primary use is multitrack recording and mixing. I needed capability to
record >2 channels, high-quality a/d and good support for low-latency and
full-duplex. My choice was midiman delta44. It has 4 ins, an external
a/d&a/d box (important for high-quality conversion), good ALSA drivers and
wasn't too expensive (ie. a lot cheaper that the RME cards for instance).
So far I've been very satisfied with this purchace.

PS Let's cross-post to linux-audio-user. That and alsa-user are
probably the best forums for this discussion.
--
http://www.eca.cx
Audio software for Linux!
Paul Davis
2002-10-22 23:29:01 UTC
Permalink
Post by Ivica Bukvic
Then explain it this way, and do not contradict yourself by initially
saying Jack will never replace other sound daemons, and then mention
yes, i think i wrote contradictory things. i sometimes do that. my
original point was that JACK was not *intended* to replace other sound
daemons. its design, its development process, its performance
characteristics, its capabilities: all these were done with no
attention paid to its suitability as a general purpose server. if it
turns out to be useful for that, great. if not, its not a failure on
our part.
Post by Ivica Bukvic
electronic and acoustic sound sources," so obviously you have no idea
what RTcmix is. Sure, it did not have a fancy gui (although that just
i do know what RTcmix is. i've used it. its a really cool program. its
not the sort of thing i would use for RTP. if you do, thats great, but
most of the people who are buying software for RTP are also not
looking for software like RTcmix.
Post by Ivica Bukvic
LADSPA plugin out there... Yet you say it's no good for commercial
market... Hmmm...
csound is massively more capable of generating interesting sounds and
music than reaktor and unity-ds1 put together. yet which one is "good
for the commercial market"? a lot of good work has gone into making
csound more useful to people without a background in assembler/fortran
programming, and the core program continues to be extremely
capable. that doesn't make it a good tool for "the commercial market".
Post by Ivica Bukvic
If you knew anything about the market, then you'd realize that as many
SOPME/RTP studios there are in the world, they don't stack up to the
amount of money educational institutions spend on building their
electronic music studios, and this is where apps like RTcmix are an
equal concern as Protools (even the university this list is hosted on
i defined my market as the SOPME/RTP world. if you want to point out
that educational institutions are a bigger financial pie, thats
great. the problem is that their needs and goals don't align with
those of the SOPME/RTP world all that much. there are several computer
music and audio technology departments and institutions around the
country that do amazing work, both from a software and a musical
perspective, but just like the stuff that emerges from computer
science departments, very little of it ever sees the light of day in
the rest of the world without a serious mangling, if not a complete
rewrite. its an interesting market, full of a lot of smart and good
people. so smart, in fact, that they have really smart people like
fernando around who can not only compile and install ardour (as well
as send patches), but also build the whole of planet ccrma in his
copious spare time. such institutions might have reasons to send some
grant money toward the LAD community, but they have lots of reasons to
save money when they can, and they can save a lot by using their own
inhouse expertise when it comes to free software. "hmm, we can spend
US$8K on this ardour-based prebuilt DAW, or fernando can put on one of
our stock audio-configured intel PC's and we pay nothing?"
Post by Ivica Bukvic
of the INDIVIDUAL University studios in the US spend over $100,000/year
for the new equipment/software. How much do the SOPME/RTP spend once
they equip it for the first time?
Post by Paul Davis
i never said that not supporting JACK makes something a toy. i noted
that most of the audio applications for linux are (1) written to use
OSS and (2) are toys. there are thousands of links to such programs on
dave's pages. the toys are fun, and often very useful. however, they
are not viable candidates to act as the basis of SOPME/RTP for most
people.
But are commonly used in educational institutions for professional music
making purposes.
if you stick with the first clause of that sentence, i agree with
you. but the second part: i have *never* seen anything but
commemorative recordings of music that were made within education
institutions. professional music making is done outside of such
institutions, fostered by the education and research that is performed
inside of them. the musical pieces that do emerge from the media lab,
from ccrma and other places flutter briefly in the thin air of
academic music appreciation, and then vanish back into the ether from
which they came. meanwhile, hundreds of small studios around the
country are recording jazz, country, blues, pop, rock, mesopotamian,
carnatic, electronic, opera ... some of which will end up being sold
to pay someone's salary. and a few times a week, some large halls and
many more smaller ones will echo (sorry, reverberate) with the sounds
of orchestras and smaller ensembles keeping alive the "serious" music
of the past and the present. occasionally someone will use a computer
in some capacity at one of these concerts, and occasionally what they
do with might end up resulting in some kind of financial exchange that
underlies "professional music making".
Post by Ivica Bukvic
Post by Paul Davis
why don't you just spend $US60 on a decent audio interface that
supports hardware multiopen, and stop looking for software solutions?
the trident cards are nice, simple, reliable and cheap. 32 hardware
stereo streams.
Because most people who perform their music on concert venues DO NOT
WANT TO LUG ARROUND A TOWER, but rather have a laptop!!! Give me one
ah, so that's a new constraint.
Post by Ivica Bukvic
laptop that does multiple opens in Alsa RELIABLY (Maestro 3i does two
streams and hiccups on third and is not being used in newer laptops any
did you try this under windows or macos yet? did you find any laptop
that has a half-decent audio interface available? why do you think
digigram and now rme and others are making the devices they are? my
experience of motherboard-mounted audio interfaces is that they are
universally utter crap.
Post by Ivica Bukvic
more anyhow, even the all-cherished RME Hammerfall DSP on which I spent
way much more than $60 does not do multiple opens (heck it does not work
at all for me, and from what I've seen for many others, in Linux) even
i don't have a laptop. i have tried to report to the best of my
ability what we have learned about how to get the cardbus interface
working (its there in the link from the ALSA card matrix). what needs
changing has nothing to do with the driver, but is instead related to
the kernel, the cardbus mgr software and the BIOS. one of the perils
of the free software world is that its hard to find a direction to
point one's finger in blame. this is definitely one of those
instances. it is clear that the driver works (bar the warm reboot
issue - even RME have no idea about that whatsoever), but its
definitely not clear what has to be done to get the kernel's
pci/cardbus/hotplug system to work smoothly with it.
Post by Ivica Bukvic
though it clearly stores audio into the memory buffer which could be
easily hacked to do downmixing of outgoing streams, yet it is not me who
has rights to the RME driver changing/updating, is it?)
you're welcome to send patches. i don't have any CVS write access to
alsa either, btw.

the rme driver doesn't support software mixing only to the extent that
alsa doesn't support software mixing. no alsa driver supports software
mixing more or less than any other. software mixing doesn't fit into
the alsa driver architecture in any way. people ("us") looked at the
windows kernel mixer that people love for its transparent mixing of
streams and noticed how much cakewalk, motu, steinberg and others
hated it and lobbied microsoft to change it. they did, and those
companies love the result, which is, suprise suprise, rather like
ASIO and JACK in its "callback/interrupt-driven" design. those drivers
don't support software multi-open unless someone writes with that in
mind and creates "subdevices". its been the policy of ALSA not to do
that unless it reflects a true hardware capability. some cards have
multiple subdevices, but alsa never claims that a 10 channel card is
really 5 stereo devices. you can use it as a stereo card, and that
will permit multi-open, but this functionality is not part of the low
level driver in any way - its all in alsa-lib and the infamous
.asoundrc file.
Post by Ivica Bukvic
On one hand you complain how your life is tough, but when people propose
i wasn't complaining. my life is great. its also full.

--p
David Gerard Matthews
2002-10-23 00:07:00 UTC
Permalink
Post by Paul Davis
i do know what RTcmix is. i've used it. its a really cool program. its
not the sort of thing i would use for RTP. if you do, thats great, but
most of the people who are buying software for RTP are also not
looking for software like RTcmix.
Post by Ivica Bukvic
LADSPA plugin out there... Yet you say it's no good for commercial
market... Hmmm...
csound is massively more capable of generating interesting sounds and
music than reaktor and unity-ds1 put together. yet which one is "good
for the commercial market"? a lot of good work has gone into making
csound more useful to people without a background in assembler/fortran
programming, and the core program continues to be extremely
capable. that doesn't make it a good tool for "the commercial market".
Ah, so what it all boils down to is a cultural difference. :)
Seriously, Ico, Paul's right on this one.
I'm also involved with the creation of academic/experimental/avant-garde
electronic music, and I
love and use CSound and PD and things of that ilk. But I would never
recommend trying those
tools to anyone running a commercial (better word than "professional",
IMHO) studio. You
want to talk about a steep learning curve? The commercial audio world
always prefers convenience
over flexibility. I don't doubt for a second that a RTCmix wizard can
probably do things with just
a RTCmix that would require a "pro" audio engineer to use a dozen racks
of outboard gear. But
different trades have different tools. (Personally, the music I'm
working with these days would
probably be best served by a big ol' analog modular synth with 128 sine
wave oscilators. I can't
afford such a beast, so I use software synthesis.)
Post by Paul Davis
Post by Ivica Bukvic
If you knew anything about the market, then you'd realize that as many
SOPME/RTP studios there are in the world, they don't stack up to the
amount of money educational institutions spend on building their
electronic music studios, and this is where apps like RTcmix are an
equal concern as Protools (even the university this list is hosted on
True. It is only in such places that audio on *nix has ever had any
impact until recently, and it's
also true that we had digital audio and synthesis when the rest of the
world still thought C64's were
neat. (Disclaimer: I thought my C64 was pretty neat in 1982.
Disclaimer to above: It was 1982,
and I was 6 years old.)
Post by Paul Davis
i defined my market as the SOPME/RTP world. if you want to point out
that educational institutions are a bigger financial pie, thats
great. the problem is that their needs and goals don't align with
those of the SOPME/RTP world all that much. there are several computer
music and audio technology departments and institutions around the
country that do amazing work, both from a software and a musical
perspective, but just like the stuff that emerges from computer
science departments, very little of it ever sees the light of day in
the rest of the world without a serious mangling, if not a complete
rewrite. its an interesting market, full of a lot of smart and good
people. so smart, in fact, that they have really smart people like
fernando around who can not only compile and install ardour (as well
as send patches), but also build the whole of planet ccrma in his
copious spare time. such institutions might have reasons to send some
grant money toward the LAD community, but they have lots of reasons to
save money when they can, and they can save a lot by using their own
inhouse expertise when it comes to free software. "hmm, we can spend
US$8K on this ardour-based prebuilt DAW, or fernando can put on one of
our stock audio-configured intel PC's and we pay nothing?"
If anything, at this point the academics are more likely to use
commercial stuff than vice versa, by
a large margin. There may still be a few departments without ProTools
systems, but they're
pretty rare. I've gone on record on this list saying that midi is
pretty much useless to me,
but I do want and need a good multitrack DAW and some good plugins.
To draw a parallel: only a small portion of all computer users have use
for a text editor like
vi or emacs, but most of the people who use such things also want a
WSYWIG word processor.
Post by Paul Davis
Post by Ivica Bukvic
of the INDIVIDUAL University studios in the US spend over $100,000/year
for the new equipment/software. How much do the SOPME/RTP spend once
they equip it for the first time?
Depends upon how profitable they are. Also, I don't know which
universities you've been hanging around,
but music departments around the world are suffering budget cuts. Yes,
this is more likely to incline them
to Linux as a possible solution, but that would entail Linux-based
machines actually costing less to deploy.
Post by Paul Davis
if you stick with the first clause of that sentence, i agree with
you. but the second part: i have *never* seen anything but
commemorative recordings of music that were made within education
institutions. professional music making is done outside of such
institutions, fostered by the education and research that is performed
inside of them. the musical pieces that do emerge from the media lab,
from ccrma and other places flutter briefly in the thin air of
academic music appreciation, and then vanish back into the ether from
which they came. meanwhile, hundreds of small studios around the
country are recording jazz, country, blues, pop, rock, mesopotamian,
carnatic, electronic, opera ... some of which will end up being sold
to pay someone's salary. and a few times a week, some large halls and
many more smaller ones will echo (sorry, reverberate) with the sounds
of orchestras and smaller ensembles keeping alive the "serious" music
of the past and the present. occasionally someone will use a computer
in some capacity at one of these concerts, and occasionally what they
do with might end up resulting in some kind of financial exchange that
underlies "professional music making".
Sadly (for me) true. It's one of those things you need to accept if you
live in the academic music
world. It is also, incidentally, the main reason I tend to sympathize
with open-source software
developers, because I've never main anything substantial from what I
consider to be my most
rewarding and important work.
Post by Paul Davis
Post by Ivica Bukvic
Because most people who perform their music on concert venues DO NOT
WANT TO LUG ARROUND A TOWER, but rather have a laptop!!! Give me one
ah, so that's a new constraint.
I can certainly sympathize with that one. Supposedly there is some work
being done on supporting
USB audio devices under ALSA; that may be our best hope. (Yes, I know
USB has potentially
horrible latency. ) Another possibility is to use a 1 or 2 unit
rackmount box with a good
PCI audio card, and then talk to the box via a remote X session going on
on a low-end laptop.
I've considered this myself, but rackmount cases are kind of pricy.
-dgm
Paul Winkler
2002-10-23 00:30:01 UTC
Permalink
Post by David Gerard Matthews
I can certainly sympathize with that one. Supposedly there is some work
being done on supporting
USB audio devices under ALSA; that may be our best hope. (Yes, I know
USB has potentially
horrible latency. )
There have been success reports on linux-audio-user.
Don't know how good/bad the latency is.
--
Paul Winkler
http://www.slinkp.com
"Welcome to Muppet Labs, where the future is made - today!"
Paul Winkler
2002-10-23 00:38:01 UTC
Permalink
Post by Paul Winkler
Post by David Gerard Matthews
I can certainly sympathize with that one. Supposedly there is some work
being done on supporting
USB audio devices under ALSA; that may be our best hope. (Yes, I know
USB has potentially
horrible latency. )
There have been success reports on linux-audio-user.
Don't know how good/bad the latency is.
Forgot to mention, this is with current alsa.
cvs or latest release should do.
--
Paul Winkler
http://www.slinkp.com
"Welcome to Muppet Labs, where the future is made - today!"
Paul Davis
2002-10-23 01:40:00 UTC
Permalink
Post by Lea Anthony
Wishing for people to write native apps for a system with no market is
like wishing Windows would die. It might happen, but it's not bloody
likely.
steinberg committed to neundo on beos when beos had even less market
than linux does now (*). so did several other companies. one of them, iZ,
even went so far as to base an entire product (the RADAR HDR system)
around that OS.

--p

(*) of course, no public release of nuendo for beos, or (i think) even
nuendo for irix, has ever took place.
John Lazzaro
2002-10-23 02:20:02 UTC
Permalink
Post by Lea Anthony
Wishing for people to write native apps for a system with no market is
like wishing Windows would die. It might happen, but it's not bloody
likely.
However, if you port a novel Linux application to Windows or OS X,
the users on those platforms are quite happy to add the free tool
to their workflow if it helps them do their work better. This is
how the GNU project got its start, after all -- free, usable software
that ran on popular commercial UNIX platforms. Sfront has taken
this route -- most of my users are non-Linux users now.

I think there's a migration path to Linux that could be based on
this strategy -- if the free software community comes up with a
set of audio content-creation tools that Windows or OS X users
are willing to use as a complete workflow, the case for switching
over to Linux to run the workflow more efficiently (or to avoid
OS license upgrade fees, etc) is easier to make. Certainly on the
CLI side, many people started out at Cygwin users to run emacs
and gcc and TeX under Windows, and then decided to add a dual-boot
option for Linux to get "the real thing."

-------------------------------------------------------------------------
John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley
lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro
-------------------------------------------------------------------------
Continue reading on narkive:
Loading...