Subject: [linux-audio-dev] My 2 cents (contd.)
From: Adam Zygmunt (azygmun_AT_bgnet.bgsu.edu)
Date: ti elo 10 1999 - 12:53:41 EDT
Analog-type sequencers: Kind of fun. Nice toys. Usually pretty bad
interfaces, if only that they don't look for default sounds and don't
label much. Would be even nicer if more of them exported files.
And now for the programming side...
Sound drivers: Enough has already been said on this that I'll keep it to a
minimum. Suffice it to say there are sill significant problems with any of
them. OSS/Free still has quite a few bugs that it would be nice to fix.
The latest shows up with OSS/Free PnP Soundblasters (I've tried an AWE-32)
and jMax. If audio in is enabled, the system locks up hard. I personally
have an Ensoniq Audio PCI, and OSS/Free doesn't support /dev/sequencer for
this card at all. I know the wavetable interface for this card is
proprietary, but I don't want to use that. I have external MIDI stuff that
I quite enjoy and would prefer to use anyway, thank you. Trying to explain
this to some of the OSS/Free developers was like talking to a brick wall.
/dev/sndstat support for many of the newly added cards would be nice, too.
Personally, I use ALSA, which suits me well for most purposes. It, however
doesn't support /dev/sequencer2, so I have to go to Windows now to use
Jazz++.
More documentation of both the OSS and ALSA API's would be extremely
helpful, as would more short, working examples of code. OSS is notoriously
bad in this regard (their oficial documentation is still unfinished after
what, at least three years?) ALSA's is considerably better, though I
haven't been able to write working raw MIDI code yet. I've compiled the
sample code in the docs, and although it runs, it doesn't work for me as
advertized. The audio/MIDI C++ lib mentioned a few messages back, with
accompanying code, looks quite helpful and along the lines of what I'm
talking about.
Compilation issues: I have recently tried to compile some of this
alpha-level software and have had less than spectacular results. I'm using
a RH 5.2 system, with as few non-RPM upgrades of libraries as I can. I am
of the opinion that keeping as few versions of libraries in different
places keeps upgrades easy, keeps fewer things from breaking, and keeps
everything (including myself) from getting confused. I recently spent
hours trying to get jMax to run. It didn't because some little throwaway
piece of java software that I installed and forgot about put an early
version of the JRE somewhere in my path, which jMax kept trying to use. If
I had been able to rpm -e the old java package. As a result of my
compilation troubles, I'll post a my developer wish list:
1. Use as few extra libraries as possible. Use even fewer large,
memory-intensive libraries. If you have to use a lot of them, see what
versions other large packages are using (i.e., if you are using gtk+/glib,
see what version the official, compiled version of Gnome uses. You'll save
those folks endless trouble.) I enjoy source code as much as the next guy,
but for the really big stuff, I don't want to spend hours wating for a
compile, see if works, try again if necessary. For example, for the latest
version of aRts, I needed to get and compile mico...twice. As far as I
know, it's still sitting at home recompiling. Good thing I don't have
anything else that I use on the system that needs mico, which would in all
likelihood would have become broken.
2. Avoid development-version libraries if possible. This is especially
true of whatever latest-and-greatest glibc is out there. I'm willing to
test and debug software, but not at the expense of making the rest of my
system flaky. To try to get some of this stuff up and running, I installed
glibc-2.1 from RH6.0 on a machine yesterday, and suddenly xfstt stopped
working, which kept X from opening, and system shutdown didn't unmount
disks properly. Worked okay the next time after a disk check and an xfstt
recompile, but who knows what else is flaky that I didn't test. I remember
the nightmare with Gnome for a while, where this app insisted on
gtk-1.1.5, while the other one insisted on gtk-1.1.7, while the GIMP would
have none of this and wanted 1.0. Personally, it's a real drag to have to
recompile everything that uses a library just because something new I want
to add requires a new version of the library. I enjoy the source trees
that can deal with a >= version of a lib.
3. Sensibility in downloading and compiling. configure;make;make install
is ideal. Even better when the dependencies work flawlessly. A prime
example is quasimodo, which although it's labeled alpha, is still a little
"creative" in its organization. Would it be too much trouble to combine
all three required files into one, as they all need to extract into the
main directory anyway? Having to run the main build from a subdirectory is
also unusual, especially considering there is a root-level Makefile. To
quasimodo's credit, the compilation procedure is at least well documented.
4. Compiler-independence. Avoid compilation options that are known to be
incompatible between egcs-1.0/egcs-1.1/pgcc/gcc-2.8. When in doubt, expect
the earliest-version compiler that will work. If someone could please
explain to me (as I'm not particularly familiar with the differences) the
advantages of requiring a cutting-edge compiler, please let me know. I
personally have been wary of pgcc, as it is know to have some issues with
kernel compilation.
5. The KISS principle. Make something that works and is useful before
adding all sorts of incomplete bits and pieces of your grand killer app. A
plug-in architecture, I think, is a good example of this. It would be one
thing if we had anything to plug them into, but right now it's putting the
cart before the horse. Another example is the heavy interest in
interprocess communication and simultaneous use of soundcards.
These are noble goals, but should be attacked after there's working
software. If you do have a grand plan, I'd recommend instead a
well-organized subdivision of source code. So realtime audio isn't up to
your liking right now, put all the low-level audio in and out code in
separate files that can easily be updated when support improves with a
minimum of changes to the core program code.
One thing I've noticed is that there's very little development of much
Linux audio software. Programs get released at alpha-versions, then they
get debugged, then they get minor updates. What you see on first release
is basically what you're going to get. I haven't seen many major feature
enhancements or interface improvements that would signify a version 2.0.
How many sound editors have we already seen come and go that have
something in the README that goes basically like "I've decided to write
this editor because there are no good ones out there. It's still in alpha
stage right now, but it'll be great. I have it ready for plug-ins and
everything. It'll be the (insert useful application here) of sound..."?
As has already been said, it's easy to criticize but hard to create. My
own GUI and autoconf/automake skill are not up to snuff at this point to
contribute much in the way of code, either. I do also truly appreciate all
the hard work that anyone has put in to create an audio app for Linux, as
it's certainly rocky, uncharted territory. I will also do my best to
continue to try out what's out there. and contribute what I can. Who
knows, I may even take up gtk one of these days, sort through the morass
that is the sound API documentation, or otherwise jump on a project that
shows some promise and that I can contribute to.
Thanks for listening, and flame away!
Adam Zygmunt
azygmun_AT_bgnet.bgsu.edu
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:25:52 EST