Subject: Re: [linux-audio-dev] What do we need now ?
From: Dave Phillips (dlphilp_AT_bright.net)
Date: ti heinä 27 1999 - 15:04:12 EDT
Greetings to all:
Well, I've certainly learned not to cross-post !
Juhana Sadeharju wrote:
> Could somebody give a short explanation why Snd and MiXViews should be
> considered as pro-level? MiXViews has problems in editing, handling large
> files, playing, no plug-ins, and more.
Hmm. Well, I've been using MiXViews for much of my own work with
soundfiles in Linux, and I've come to know it pretty well. I'd be out of
bounds to claim it or Snd as 'pro-level', but each has certain features
I don't find in Cool Edit (or any other Windoze sound editor) and that I
do use.
The biases of those apps may indicate something about their origins. It
seems to me that both Snd and MiXViews are especially oriented towards
work in the spectral domain, i.e., frequency analysis, display, and
resynthesis. Does CE do LPC analysis and resynthesis ? Does it do phase
vocoder analysis and resynthesis ? Can I use the spectral display as a
source for data to apply to other aspects of the sound ? Will it use
LPC-derived formants as filter components ?
I'm not defending MiXViews against Cool Edit, nor am I arguing that it
is a 'pro-level' (my gaff) piece of software. In point of fact I wrote
that it's "moving closer" to pro-level. The latest version has some new
memory controls, perhaps it has already addressed your concerns about
handling large files. I should also note that I've had no trouble
playing anything in MiXViews, and that in fact it plays files I've had
trouble with elsewheres. Ditto for editing.
However, I understand that your needs are somewhat heavier than mine.
But you're still right when we compare MiXViews and Snd to the big guns
in the Windows world. MiXViews still lacks a tracking cursor !
Snd may be a different order of things. Bill Schottstaedt is working to
include the signal processing power of CLM into Snd (which would be
something like hitching Csound to Cool Edit) but I've been unable to use
it due to LessTif flakiness. I suggest watching Snd's development: it
already has good displays, can handle a large number of file formats, is
already moving into the use of plug-ins, and source code is included.
Francois Dechelle wrote:
> I think that one important and urgent problem is the lack of
> drivers for pro multi-channels audio cards. I don't know
> if you agree, but I think that OSS has not helped progress
> in this area because of the closed-sources, and we should
> fight for open-source drivers.
Right now it appears that Windows enjoys the same sort of industry
patronage that the Mac had in the 80s. But just as the Mac's hegemony
has declined, so can Linux bite into that Windows piece of the audio
pie. And you are correct: serious sound composers and researchers
absolutely need high-end high-quality sound cards.
So who do we fight ? How will we convince manufacturers of the obvious,
namely, that if they open-source their drivers they will sell more cards
? If they can't already see it, how will we convince them ? Frankly, I
doubt that our community's current buying power is simply not great
enough to warrant their attention. And when we _do_ reach critical mass
in numbers of Linuxen, then won't manufacturers be far more interested
in producing mass-market cards instead of high-end audio boards ?
I like the idea of targeting the manufacturers who already make the
cards we want on our Linux machines. Lobbying those builders seems a
sensible thing. Perhaps a group from LAD could start drafting a common
request ?
If there is a most-often heard complaint in the Linux audio world it has
to be about the lack of support for high-end audio cards.
Maurizio Umberto Puxeddu wrote:
> I was thinking of a similar Linux-for-the-musician distribution too.
This seems to be an idea whose time has come. Francois, perhaps you and
Maurizio should hook up on this ? I had the same idea two years ago: can
you imagine how crummy it would have been ? ;)
Nick Fells wrote:
> I would think the establishment of a recognised linux audio users/developers
> group might have some effect here. Such a group could coordinate
> development/testing/evaluation tasks, lobby hardware manufacturers, stress test > kernel releases and work on solutions to latency problems etc...and would have > more clout than individuals.
Well, I'd like to think that this group qualifies, but I think Nick is
proposing a group wth some serious blessings from on-high, i.e., Linus
Torvalds and Alan Cox.
> ...what's lacking are apps which have the
> reliability/flexibility/comprehensiveness of software like CEPro and Cubase
I'm going to say a word which will chill the hearts of many here: money.
The developers of CE and Cubase are paid and probably paid well. Most of
us are doing what we can in Linux for absolutely no pay. I maintain that
in order for Linux audio development to even begin to compete with the
Big Guys we need some better organization of talents, better statements
of principles and goals, and perhaps even some honest-to-goodness
sanction from Linus and Alan and the other primary kernel hackers. In
other words, we need a strong and convincing profile, something that
will notify manufacturers and other targets that we are ready to
develop, that we have the resources, and that the work will see the
light of day.
Fred Floberg wrote:
> ...intermittant latency caused by the kernel locking
> during syncs of the disks [URL1]. The locking causes suspension of writes by
> all drivers in the kernel, including audio drivers, at random intervals.
> This makes hard-disk audio recorder apps, for example, rather unreliable.
>
> From what I understand, this problem is being addressed slowly but surely,
> by the kernel developers. But until the work is finished it's going to
> be difficult for app writers to write rock solid real-time audio tools.
>
> So one of the things that could be done is to encourage kernel developers
> in completing the work in this area, and of course lend a hand if possible.
This direction should be followed asap. Does Alan Cox read this mail
list ? If so, perhaps he could clarify the points needing attention.
Some pretty smart people are on the list, surely someone can lend a
hand.
(Hi, Fred, I wondered what happened to you !)
Rob Melby wrote:
> hard real time scheduling is available to linux now with more or
> less trouble. rtlinux puts a small scheduler under the kernel that
> controls the interrupts, nothing in the linux kernel level can lock its
> resources.
So this needs to be put into our Linux audio CD's kernel ? How would
such an addition impact applications already handling scheduling in
their own way, i.e., how would Quasimodo react, or realtime Csound ? I'm
not baiting, I just don't know much about rtlinux.
Okay, I have to stop somewhere and get back to work. Here's what I'm
tabulating as a partial list of the First Things we still need to get
to:
1. Support for professional quality audio cards.
2. Professional quality software that will use those cards to their
fullest extent.
3. Some method of controlling disk writes and any other kernel
activity which can throw timing to the winds.
4. A Linux-for-musicians CD which would hopefully have #1 and #2.
Thanks to all who responded, and I look forward to reading what comes
next.
== Dave Phillips
http://www.bright.net/~dlphilp/index.html
http://sunsite.univie.ac.at/Linux-soundapp/linux_soundapps.html
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:25:52 EST