Hi All,
I'm trying to develop a custom wav player app using libao - I need to
keep the audio latency as small as possible in this project. I was
wondering if anybody has done any tests to see how latent libao is for
this, or whether I should just throw in the towel now, and move to
jack/libalsa?
Also I was wondering whether reading each sample at a time from a file
is likely to be dropping the real-time ness, or whether people have
found that this isn't really such a limiting factor.
At the moment it seems quite slow, but then I am developing in vmware-
so I guess that adds quite alot of latency!?
Tom
Hi all,
Ok, so I'm playing with osc (currently doing gui->app communication with it)
but all my individual apps still talk midi between them. This is quite
cumbersome, as I want to start having lots of controls that midi doesn't
support - and I don't really "think" in midi these days anyway.
Is there a case now to ditch midi support and go with osc for everything? I
see midi messages are a type within osc anyway - is it fairly straight forward
to be backwards compatible this way?
cheers,
dave
>I have two Audio related projects that need updating.
>Both have existing /dev/dsp style backends at present, which have been working
>fine. But recently (SuSE 9.0 install?) when run under ALSA emulation of
>/dev/dsp they both started producing segfaults - "after program had exited",
>(neither valgrind nor gdb can give any info on the fault).
>So I decided it was time to do a native ALSA backend(s).
>I have rsynth backend working, and perl Audio:: one almost working.
>But before going forward I would like to solicit opinions on what
>is the "right" API to use.
>(please tell me if I missed any):
Portaudio, which gives you macos and windows for free (but of course
you must also port the gui stuff...)
>2. ALSA
>3. JACK
Do the callbacks once and it's trivial to port to all three of the above
in my experience.
Hi everybody,
After the holiday season, and late for the 1st anniversary, here comes
another dot release for QjackCtl, the Qt GUI for the JACK Audio Connection
Kit:
Qjackctl 0.2.10 is out, with some minor enhancements and fixes.
>From the change log:
- New pre-shutdown script setup option, allowing to specify a shell-script
to be run before the JACK server daemon is shutted-down. This overrides
any previous shutdown script setting, which should be now moved onto the
existing post-shutdown script option, as to keep old procedural behaviour.
- Avoid stopping JACK prematurely with QProcess::kill() (oneliner fix);
stopping JACK will now take a little bit longer, but hopefully will take
the time to cleanup properly (thanks to Kjetil Matheussen).
- ALSA driver Duplex mode accepts alternate Input or Output device name.
- Context menu reset option is now always enabled (yet another suggestion
from Sampo Savolainen).
- Main display background gets shinny effect; adjusted system tray
background palette color mode.
- Priority and setup control is now a spinbox ranging from 0..89 (as
suggested by Florian Schmidt). Same for Periods/Buffer.
- Patchbay connection lines are now drawn correctly when items are
scrolled out of view. Additionally, the connection lines can now be
optionally drawn as bezier spline curves (big thanks to Wilfried Huss).
Just head to the homepage:
http://qjackctl.sourceforge.net
or, in case that's not up-to-date yet, to sourceforge's project page:
http://sourceforge.net/projects/qjackctl
Hope you enjoy.
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
hi...
i just wanted to announce this bugfix release of galan-0.3.0
this one was a real show-stopper with complex signal routings.
get it at http://www.sf.net/projects/galan
for those who dont know:
gAlan is a powerful modular synth and effects engine, which allows the
user to build a custom UI for a synth mesh he has created.
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
Greetings:
I wrote to Joerg Anders, the author of NoteEdit, and he confirmed that
he is leaving off development of NoteEdit. Though I disagree with his
assessment of a possible Linux Finale, it's certainly his right to stay
with or go away from the helm of NoteEdit development, and he can use
any reason he prefers.
I have *no* confirmation regarding any Linux development at all from
Coda Music, the manufacturers of Finale. Unless someone knows more, I'd
say it's an unfounded rumor. I've read that some users have run Finale
under Wine: I can get it to open but it doesn't work after that.
There's some discussion whether to keep it in AGNULA and whether
AGNULA members might want to take over the development of NE. I realize
that NE has some possibly irritating dependencies, but I must add that
it is a unique Linux music notation editor with a well-evolved set of
features and an active user base.
I'm uneasy about the implications that mere rumor compelled Joerg to
abandon NE, though as I said, I respect Joerg's wishes and his
accomplishments with regard to NE. I'm confused as to why Finale's
presence might force a developer to consider his own work a closed case.
After all, Finale is expensive, closed-source, and not necessarily
suited to everyone's work methods. NE is free software, open-source, and
works nicely for me. I would hate to see it disappear.
Joerg said that since sources are available anyone can continue with
NE development. I hope that happens.
Best regards,
dp
Hi All,
I am pleased to announce that I finally have an alpha release of a louderbox
that is (hopefully) reasonably fit to show its face in daylight....
What I have is an 8 band compressor/limiter/clipper/pre em thing written as a
jack client. It borrows very heavily from jamin but as fits its intended use
butchers far more of the dynamics then would be acceptable in a mastering
processor.
Excuse the autotools mess, I am still trying to get by head around the horrid
things. I Think the dependency list is correct, but do not depend on it.
The default startup config needs a lot of work and not all the GUI controls
are connected to the DSP core yet.
You can see the screenshots (which for some reason seem to matter more then
what it sounds like to some people!) and get the code here:
http://www.spamblock.demon.co.uk
Ps: Sorry Fred, I decided in the end to go with GTK and OSC for remote
control. Writing a RML to OSC bridge should be almost trivial however.
Like JAMIN (from which it borrows lots of code) this makes heavy use of LADSPA
plugins to do most of the real work.
Comments, Flames, Patches?
Regards, Dan.
--
** The email address *IS* valid, do NOT remove the spamblock
And on the evening of the first day the lord said...........
.... LX 1, GO!; and there was light.
Greetings,
I have released a first version of my LADSPA host Soundtank which
holds instruments for you to play.
The project website is http://nymu.net/soundtank
In this program, you can use any LADSPA plugin with a pitch control as
a softsynth; multiple instances handle polyphony and MIDI control is
handled through user-customizeable Event Maps. As a perk, I have
included a command to automatically create Event Maps, ensuring you
instant gratification.
Soundtank is a shell for audio work. Instead of a directory heirarchy,
Signal Path objects hold other objects in ordered lists. The order
dictates the audio signal flow. There are alternate versions of the
shell commands you are familiar with, such as: ls, cd, rm, mv. This
should make it easy to learn to use.
This is a native ALSA app, with full duplex support in JACK, and an
ALSA Sequencer MIDI port is created for every active object. All audio
generation/filtering is handled by LADSPA plugins. Furthermore,
objects are saved to human readable, flat-file format XML files.
To see more, go to http://nymu.net/soundtank
thanks and best wishes,
--jacob
hi all,
i'm considering to add lock free queue support to packet forth, just to
follow the hype, and maybe also because i like the concept. but i'm
wondering if it would make much sense to go through all the trouble with
fast mutexes being available in 2.6
in other words, how much better (apart from being more elegant) are lock
free structures wrt a mutex approach where there is a minimal system
penalty? (not many collisions) did anyone look into this? or have i not
been lurking properly? ;)
cheers
tom
