I think I know the answer to this, but I was wondering if it's
possible to mix two separate audio sources in software. I'd like to be
able to play announcement-type audio atop the currently playing main
track. An example might be when driving down the Autobahn and a
traffic report temporarily pre-empts whatever it is you are listening
to. In my case, though, I'd prefer to keep the main audio playing, but
at a very low volume level compared to the short announcement..
My setup is a roll-your-own embedded Linux distro with kernel 2.6.28.
I'm using Alsa SoC audio driving an I2S output on my Marvell processor
(which is now working just fine, BTW). The I2S signals feed an FM
transmitter chip which is broadcasting audio to a nearby FM receiver.
The FM chip only has the one input so no mixing possible within that
part. Anyhow, considering I only have a single I2S output, seems to me
that I'd need to do the mixing somewhere upstream of that serial port
within the Linux machine. But there is no special hardware for this
and I think the answer is "no, there is no way to mix two separate
audio tracks without a DSP and another device driver". But I thought
I'd ask just the same.
JACK Session managerism...
This might well be ahead of its time. And probably is. JACK session
infrastructure and its promised functionality is still dormant in
subversion source pits. However, good news are, no matter which flavor
you pick, either JACK1 (>= 0.119.2) or JACK2 (>= 1.9.7), both already do
it all to the promise. However still on their respective SVN trunks though.
Maybe this very announcement will get that all loose and out of the dorm
;) At least, I'm trying.
Meanwhile and until that ever happen, QjackCtl will be already here even
though its JACK Session manager(istic) features will be just lurking to
get out of redundancy. Fact is, this new source won't do much better
than that of good old Patchbay, if compiled with existing JACK package
distributions (latest are 0.118.0 and 1.9.6, respectively). Nor even
close. Actually, only when it gets ever compiled and built against a
current JACK Session API it will take off. Fly high or low, you may ask.
Well, may I say, it will only fly as high as many Linux audio
application developers will do to embrace the daunting trouble of adding
a few dozen lines of source code to their creatures. And to their help,
chances are that Torben Hohn already has all the starters ready (ask
torbenh on #jack @ irc.freenode.net; maybe he still has some fresh git
repo/patch on the fridge:). Then again, this very announcement is being
kind of a heads-up. Avast ye LADs!
Anyway, there are a few new tricks this old dog have been taught,
besides putting the carriage before the horses, nevertheless... :)
QjackCtl 0.3.7 has been released!
That's it. Well, the uber-procrastinator sometimes gets over it.
Sometimes :) Maybe there's a fine distinction between elegant
procrastination and being just lazy. Tradition still rules: lazy enough
to procrastinate no more :)
- source tarball:
- source package (openSUSE 11.3):
- binary packages (openSUSE 11.3):
Weblog (upstream support):
QjackCtl is free, open-source software, distributed under the terms of
the GNU General Public License (GPL) version 2 or later.
- Session widget has session save type preserved as well.
- Connections and the new Messages/Status widgets now have their last
open tab preserved across program run-cycles.
- Connections and Patchbay widgets have been finally given up on an old
feature request: an Expand All items button.
- A significant UI layout has been made: the Messages and Status widgets
were merged into one, giving space to the brand new Session wigdet to be
easy accessible from the main panel control window.
- libX11 is now being added explicitly to the build link phase, as seen
necessary on some bleeding-edge distros eg. Fedora 13, Debian 6.
(closing bug #3050915).
- Input/Output latency options were missing but now finally enabled for
the firewire back-end.
- General standard dialog buttons layout is now in place.
- Avoid pre-loading a stalled patchbay definition filename and its
nagging error on startup (fixes bug #3017078).
- Client connection retrial logic scrapped. Being a leftover from early
ages, when machines were slower and JACK server startup times were
longer... now, if it can't connect first time as client, it will tear
down the server whether it's starting up still or not at all. (cf.
Setup/Settings/Start Delay for the rescue).
- Server name is finally part of the server settings presets, thanks to
Fons Adriaensen for the heads-up.
- As a workaround regarding issues switching jack2's backends, Robin
Gareus sends us yet another D-Bus metho slot: "preset", (dbus-send
--system / org.rncbc.qjackctl.preset string:PRESET). Thanks again.
- Another D-Bus interface slot makes it through implementation: "quit"
(eg. usage: dbus-send --system / org.rncbc.qjackctl.quit). Besides,
there's also these new JACK session management actions which were being
overlooked as well: "load", "save", "savequit" and "savetemplate" are
also available as D-Bus method slots.
- Make sure that Patchbay socket names are unique when adding or
copying, fixing previous patch by Dominic Sacré.
- JACK version is now being shown on the About box (jack2).
- Slight Connections widget behavioral change: (dis)connecting a client
(from) to one single port, (dis)connections will be applied in sequence
from (to) all client output ports to (from) as many input ports there
are in below, one by one (satisfying a 5 year old request from Yann
- JACK session support is being introduced.
- Ignore first XRUN occurrence option dropped from statistics.
- Initial widget geometry and visibility persistence logic has been
slightly revised as much to avoid crash failures due to wrong main
widget hidden state.
- Double-quotes are now being added to device names which include blank
characters and were rendering invalid all command line invocation of the
classic JACK server (eg. specially due for Portaudio device names on
- Transport play (rolling) status is now being guarded to avoid
backfiring from extraneous transport state changes.
- General source tree layout and build configuration change.
- Italian (it) translation added (by Sergio Atzori).
- Post-shutdown script invocation logic slightly refactored in attempt
to enforce its execution on application quit.
rncbc aka Rui Nuno Capela
In keeping with the usual Xsynth-DSSI hackery I like to do (since it
makes such an awesome experimental base) I'd like to present my latest
horrible unlistenable noise generator:
Warning: only the voice generation code has been changed. This will
overwrite or otherwise badly affect an existing install of Xsynth-DSSI.
So what's different about it? Well, the minblep band-limited
oscillators have been replaced by Tomisawa sine-feedback oscillators.
These resemble "operator 4" in a DX21 or other four-op FM synth, in that
by applying FM feedback around a sine function it starts to approximate
a sawtooth wave. If you take two sawtooth waves, offset the phases, and
subtract, you get a squarewave. By varying the offset, you vary the
Now here's the clever bit - I've modified things slightly so that the
two Tomisawa generators can run at different speeds. So, by offsetting
the frequencies you get either a deep PWM squarewave or a kind of
"supersaw"-type sound. By varying the amount of modulation (beta) you
can determine the "shape" of the waveform.
So how are the oscillator controls affected? Pitch remains the same.
Waveshapes are Sine (as you'd expect), Tri (saw with not much beta,
really), Saw up and down are both just saw, Square (adjustable
pulsewidth), Square with adjustable drift, and Saw with adjustable
drift. Pitch mod and sync don't currently work. I don't know if sync
can be made to work, without introducing aliasing.
Have a play and let me know how you get on.
I understand that a lot of you develop for free software and are
passionate at what you do. But how do you pay the bills? What do you
do for a living? Are you a student? Do you do software development
just as a hobby, or do you want to make a living doing this kind of work?
The reason I ask this is because I am curious about what kind of
backgrounds a free software developer has. As for me, I am a student
majoring in Music and minoring in Computer Science. I got the idea of
writing this email, actually, because Google had an internship panel at
my school. Google just loooooves open source and those involved. It
sounds like Google has quite a friendly and cooperative working
atmosphere, and they treat their employees very well. Yeah, I'd like to
work for Google, but who doesn't right? :)
I'm writing a synth module on top of jack and I'm starting to contemplate stereo.
I looked up "pan law" and understand that center should be -3 db (or some say -3.5 or 4.5, whatever) given unity at panned hard L or R. It was said that in an ideal room I should be down -6 db in the center. That would mean linearly transitioning from unity gain to completely off as one pans, I *think* (-6 db in the center = .5).
So that's one (very easy) way to go...
There was also mention of "equal power". Since power is proportional to signal squared, this means with parametrized L and R functions
L(t)^^2 + R(t)^^2 = 1, 0 <= t <= 1
We need an f(t) such that f(t) = L(t) and f(1-t) = R(t).
I played around this for awhile and using the sum of the square of sin and cos etc I got an f(t) of
f(t) = cos( pi * t / 2 ) (details available on request)
So L(t) = cos(t * pi / 2) and R(t) = cos((1 - t) * pi / 2)
And that seems to work out correctly.
Is this equal power version worth spending the processing cycles on? I intend to make pan envelope and LFO controllable so it's not going to be the case that the pan value can be thought of as relatively static.
PS now that I know what I'm looking for web search turned up this:
I've began learning about the LADSPA standard, read the comments in the
header, read the ladspa.org info,
but still I wouldnt know where to start with writing my own code to make a
plugin process a buffer.
So my request is as follows, is there a "here's 20 lines of code to process
a buffer" tutorial somewhere?
I've downloaded the SDK, but reading trough the "applyplugin.c" code
confused me more than it helped...
800+ lines is more than I can understand in one go.. :-)
Cheers for any suggestions.. -Harry