Audiality 0.1.0 Alpha Release
-----------------------------
Audiality is an audio engine originally designed for playing
music and sound effects in games. Scalability has been a major
priority; the current version will run on very low end Pentium
systems, but also scales to audio quality comparable to that of
"real" hardware synths. (That is not to say that Audiality can
compete with the feature set of those synths... Yet.)
The engine builds as a shared or static library, or both if
possible. (Not sure if it builds for Win32, but it did not
long ago...) Two simple test programs (one for the scripting
engine and one for the whole thing) and a bunch of demo sounds
and songs are included.
That minimalistic plugin API, and the timestamped event system
are in there. Should be easy enough to extract for anyone who
wants either or both for something else. Both are LGPL, just
like *most* of the rest of the engine. (Read on...)
Licensing terms:
I intend to release all of the code under the LGPL.
However, there are still traces of the GPL code that
"inspired" the creation of this engine. (I didn't
really mean to turn those four little files it this
beast... *heh*) That code was written by Masanao
Izumo (maintainer of Timidity++), whom I have not
been able to contact.
Therefore, the engine as a whole has to be considered
GPLed, until this issue can be resolved one way or
another. Feel free to find Masanao for me, contribute
LGPLed versions of the offending files, or whatever.
This might all sound silly to you, but I can't say
for sure how much of Masanao's code and design is
still in there, and I don't feel like stealing and
sublicensing stuff - be it 5 lines of code.
No big deal - it's still Free, and I'm not planning
on making money on Audiality as a product anyway.
The motivation for LGPL is just that I want people
to also be able to use Audiality for what it was
originally intended: Game audio.
The files (temporary location):
http://www.seaside.se/~sea1154a/audiality-0.1.0.tar.bz2 (359 kB)
http://www.seaside.se/~sea1154a/audiality-0.1.0.tar.gz (467 kB)
To install:
* Unpack into whatever place you want sources
* In the top dir:
* ./configure
* make
* As root: (or add options for user install)
* make install
* In the test subdir:
* ./configure
* make
* ./eeltest (does the output make sense? ;-)
* ./atest (enjoy! :-)
If the lib won't compile for reasons related to ALSA, I'm afraid
you have to './configure --disable-alsa', since the ALSA rawmidi
support is for 0.5 only... Sorry. (I'd happily accept a patch -
including audio support, as I'm using ALSA 0.9 myself now! ;-)
Requirements:
* SDL 1.2 (http://www.libsdl.org)
* Autoconf 2.55
* Automake 1.7.1
* Libtool 1.4.3
(Though you can probably build with slightly older
versions of autotools. I just grabbed the latest
tarballs from the GNU site.)
Some working features (or so I hope!):
* Voice mixer with
* 2 stereo sends with independent bus selection
* Smooth ramping of sends - no zipper noise
* Scalable resampling quality:
* Nearest sample
* Linear interpolation
* Adaptive oversampling
* Cubic interpolation
* Native support for multiple waveform formats:
* 8 bit integer
* 16 bit integer
* Mono as well as stereo
* Internal mixer with
* Up to 16 busses
* Up to 8 insert effects per bus
* Full send array...
* ...that can send to other busses
* ...before the first insert
* ...after each insert
* Two way kewl insert effects (not really):
* Feedback delay "reverb"
* Basic limiter
* Off-line waveform rendering package:
* Driven by a simple scripting language
* Can be driven through a handy C API.
* Supports various sample formats:
* 8 bit integer
* 16 bit integer
* 32 bit float
* Mono as well as stereo
* 7 modulation targets, each with:
* 1 envelope generator
* 1 LFO
* Oscillator operator with:
* 6 mixing/combination modes:
* ADD
* MUL
* FM
* FM_ADD
* SYNC
* SYNC_ADD
* 13 waveforms/tone synthesisers
* SINE (with FM if you like)
* HALFSINE (half wave rectified)
* RECTSINE (full wave rectified)
* PULSE (PWM capable)
* TRIANGLE (mod => saw-tri-saw)
* SINEMORPH (recursive FM)
* BLMORPH (sin, saw, square)
* BLCROSS (sin, saw, square)
* NOISE (SID style; NG + S&H)
* SPECTRUM (additive Df)
* ASPECTRUM (multiplicative Df)
* HSPECTRUM (harmonic)
* AHSPECTRUM (pseudo harmonic)
* Basic filters:
* Low pass, 6 dB/oct
* High pass, 6 dB/oct
* Basic resonant filters (oversampled):
* Low pass, 12 dB/oct
* High pass, 12 dB/oct
* Band pass, 12 dB/oct
* Band reject/notch, 12 dB/oct
* Band boost/peak, 12 dB/oct
* Real time MIDI input (ALSA 0.5 or OSS)
* MIDI file loader/player
* Audio output through
* SDL (and whatever that supports)
* OSS
* OSS/polling (only for broken debuggers...)
* WAV and "RAW" audio file loading. (SDL)
The main goal for the future is to extend the scalability of
Audiality well into the range of serious home and professional
studio use. The idea is to provide total control, a multitude
of *useful* features, tools for fast and effective creation of
original sounds, and excellent audio quality. I'm serious about
music, and I'm not going back to programming hardware synths
with little LCD displays or crappy editor software. Audiality
is meant to replace the hardware synths I have, and eliminate
the need for future purchases in that area. (I'd much rather
spend the $$$ on audio interfaces, CPU power and perhaps, good
sample libraries.)
It's a tough goal, but I have been known to produce hundreds of
lines of working code a day (*), when strongly motivated. :-)
(*) Calculated from Audiality statistics during the period when
most of it was written. Around 300 lines/day, IIRC.
Some TODOs:
* Separate audio/MIDI drivers from the core!
* Implement a serious API for the engine library!
* Audio I/O through JACK, ALSA and possibly LADSPA.
* ALSA sequencer support.
* OSC? DMIDI? Whatever works.
* Hosting LADSPA plugins as inserts.
* Support multichannel I/O directly through the mixer.
* Make the FX plugin API use the event system.
* Add support for float32 processing and plugins.
* Direct-from-disk waveform playback. (EVO?)
* Switch from interpreter to compiler + VM.
* Support scripting in the real time engine.
* Script editor with GUI panels for known constructs.
* Full GUI editor that generats scripts from scratch.
* Integrate the off-line and RT synths totally.
* Split voice mixers into "resampler" and "send unit"
* Support voice insert plugins? Maybe, maybe not...
* Implement better resampling in the voice mixers
Have fun!
//David Olofson - Programmer, Composer, Open Source Advocate
.- Coming soon from VaporWare Inc...------------------------.
| The Return of Audiality! Real, working software. Really! |
| Real time and off-line synthesis, scripting, MIDI, LGPL...|
`-----------------------------------> (Public Release RSN) -'
.- M A I A -------------------------------------------------.
| The Multimedia Application Integration Architecture |
`----------------------------> http://www.linuxdj.com/maia -'
--- http://olofson.net --- http://www.reologica.se ---
Sorry, to release again so soon, but I f**ked up and forgot to commit the
fix for the duplicate UID. Erk! Thanks to Nathaniel Virgo for noticing,
and reporting a bug in the chebstortion: for some input (eg. pure
sinewaves) it produces odd clicks in the output, I've seen this elsewhere,
but for the life of me I can't remeber where, or what caused it.
Someone else reported a bug in the multiband EQ: freqeuncy dependent
wideband distortion, but I cant reproduce it, so more reports about this
would be good.
To make up for it, I've just added a "Bode frequency shifter", an
interesting synthesis tool, as requested by Matthias. I've wanted one for
years, and didn't think they would be so simple to implement digitally.
It produces some aliasing with wideband input, I can fix it later if
enough people request it.
Anyway, http://plugin.org.uk/releases/0.3.2/
- Steve
Hello, all.
This is perhaps totally OT, but with all of the recent conversations
about amp-modeling, I was wondering if anyone had any pointers to how
to build a physical, analog, amp-modeling stompbox or similar (or would
it just be cheaper to buy a SansAmp?) Any direction to get started in
this arena would be helpful.
thanks,
wb
--
Will Benton
http://www.cs.wisc.edu/~willb
"YOW!! That was one of my BEST NIGHTMARES!!"
hello,
I am writing a audio recording app for linux pdas, of the zaurus sort. I am
running into a problem with switching sampling rates on the target device,
and need some help to find a work around for a buggy driver, which I have no
control over, as it's shipped with the device, and is not a kernel module.
When testing on my x86 desktop, and various audio cards, everything works as
planned.
But when running on the device (arm based processor, tc35143 audio chip - heh
for whatever its worth), when I request a new sampling rate, the
driver/device seems to change, no errors are reported. I can ask the driver
what the rate is and it reports what I requested, but the actual amount of
data received is at the previous rate. I can close the app and get the actual
intended rate.
I have tried doing a fork, in hopes maybe the driver was holding process
information. No joy.
I don't want to have to resample the input, as it seems a waste of cpu, and as
a musician... blasphamy.
Any hints, or suggestions would be welcomed.
thanks,
ljp
--
My cat's a debugger....
Potter, Lorn, "ljp"
core member / Web Administrator
Project OPIE- the Open Palmtop Integrated Environment
http://opie.handhelds.org | http://www.opie.info (german) |
http://www.opie.us
IRC: irc.freenode.net #opie #opie.de
llornkcor(a)handhelds.org
>I will check the effect of sse on my plugins as they are generally less
>ram hungry, but I dont have a gcc3 machine around at the moment.
Just FYI, the redhat gcc3 rpm installs the executable as gcc3 so it
happily coexists with older gcc versions. You just edit the makefile
to use gcc or gcc3.
http://plugin.org.uk/releases/0.3.1/
Includes a fix for a serious problem where two plugins ended up with the
same UID, 0.3.0 users should upgrade.
One new plugin, "chebstortion" a synthetic distortion effect that came out
of the amp modelling discussions. It doesn't really bear any resemblance
to any analogue effect living or dead, but its interesting anyway.
Bugfix to the analogue osc, it now doesn't (shouldn't) distort horribly.
Bugfix to the chorus, it now uses less CPU and its load is constant, so it
will work OK in RT systems.
Now builds on Linux PPC (though still not OSX).
Installs RDF metadata describing the plugins.
Now has freshmeat entry, http://freshmeat.net/projects/swh-plugins/
(someone requested this, sorry, can't remeber who).
- Steve
For a couple of projects I need to be able to find out information about
the sound cards installed on the system, but as I need to run on lots of
different systems I need it to be fairly portable. Before I start
writing something to do it, I figured I'd check to see if there's
anything already in progress that can do the same.
What I need is to be able to get a list of sound cards on the system,
and information about them (like the names), and then to get a list of
the channels each sound card has and information on them (current level,
name (if it has one), if it's a record source etc), and finally to be
able to control the channels, change the level, change if it's the
current record source.
Is there a library that can do this all available anywhere, or will I
have to write it myself? Would it be a useful thing to have in a
library?
iain
--
"The 'developed' nations gave to the 'free market' the status of a god,
sacrificing to it their farmers, farmlands, and communities, their
forests, wetlands and praries, their ecosystems and watersheds. They had
accepted universal pollution and global warming as normal costs of doing
buisness." - Wendell Berry
Hello all!
A new version of RTMix is available at the same old place:
http://meowing.ccm.uc.edu/~ico/
(use html entrance for low-bandwith version -> cpu's -> rtmix download)
New improvements include:
*Fixed networking seg-faults in Qt3
*Finished network code
*Removed all kde-libs dependencies (I overlooked a couple in the
configure script itself, sorry about this)
*Several minor bug-fixes
*Fixed all other known seg-faulting bugs
*Added a couple of networking tutorials
Enjoy!
Ivica Ico Bukvic, composer, multimedia sculptor,
programmer, webmaster & computer consultant
http://meowing.ccm.uc.edu/~ico/
============================
"To be or not to be" - Shakespeare
"To be is to do" - Socrates
"To do is to be" - Sartre
"Do be do be do" - Sinatra
"2b || ! 2b" - ?
"I am" - God
Hi People,
This is the first announcement of Secret Rabbit Code:
http://www.mega-nerd.com/SRC/
Secret Rabbit Code is a library for doing Sample Rate Conversion on
audio. The web page has the full spiel of what it does.
The source code tarball has two demo programs:
sndfile-resample -
A program which can perfrom sample rate conversion on a
given sound file.
varispeed-play -
A program which plays a given sound file in a loop. During
play, the speed of the playback is continuously varied.
Lots of fun on drum loops and full mixes. This currently
runs only on Linux/OSS (probably also ALSA OSS emulation).
Work is being done on ports to MacOSX, Solaris and Win32.
At the moment the rabbit code is known to compile on Linux and
MacOSX. Win32 and Solaris support is coming RealSoonNow (tm).
Enjoy,
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo nospam(a)mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
Everyone seems to assume that the current system in America is capitalism.
I beg to differ. True capitalism does not involve false advertising,
distribution cartels, or political lobbying for special advantages in the
market. How can you call Microsoft or the RIAA capitalist, when their main
business is interfering with a free market? Some of us would like to see a
*return* to capitalism in this country. - Jim Flynn on Linuxtoday.com
Hi all --
I'm making my first forays into OSS DSP programming with an eye to
improving the standard linuxaudiodev module included with Python. (And,
of course, to using that module for my own ends!)
I'm rather confused by the semantics of write() in blocking and
non-blocking mode. Specifically, in the default mode (blocking, no
SNDCTL_DSP_NONBLOCK ioctl() call), it appears that write() will happily
write the entire buffer passed to it, and not return until almost all of
the data has been played. (I assume the last dribble is in a
lower-level [hardware?] buffer, so when write() returns there's still a
little bit of sound to be heard.)
However, in non-blocking mode, write() plays roughly 64k or 128k
(depending on the hardware device used) and returns immediately. This
is more like what I was expecting -- I guess the behaviour in blocking
mode is a bit surprising. Is it supposed to be like this? More
importantly, can I *rely* on write() in blocking mode always consuming
the entire buffer passed to it?
BTW, this is with Linux 2.4.20-rc1; the two audio devices are a
SoundBlaster Live using the OSS emu10k1 driver, and a Stereo-Link
external USB audio device using, you guessed it, the USB audio driver.
Thanks --
Greg
--
Greg Ward <gward(a)python.net> http://www.gerg.ca/
I hope something GOOD came in the mail today so I have a REASON to live!!