JACK RELEASE 0.80.0
JACK is a low-latency audio server, written primarily for the GNU/Linux
operating system. It can connect a number of different applications to
an audio device, as well as allowing them to share audio between
themselves. Its clients can run in their own processes (ie. as normal
applications), or can they can run within the JACK server (ie. as a
"plugin").
JACK is different from other audio server efforts in that it has been
designed from the ground up to be suitable for professional audio work.
This means that it focuses on two key areas: synchronous execution of
all clients, and low latency operation.
CHANGES:
New transport API (details (of a sort) below).
new example client for control the transport.
ignoring of first xrun on jackd startup.
Much more portable across processors (details below).
jackd -v (--verbose) now prints useful transport state change
information for debugging JACK and clients. Also reports timeout info
in seconds, not microseconds now.
new dummy driver (along side the existing alsa and portaudio drivers).
Removed incomplete Solaris driver.
support for asymmetric soundcards (for example, es1968 chip has
interleaved stereo for playback but non-interleaved stereo for capture).
Now enforces power of two sized buffer lengths.
Many minor bug fixes.
DETAILS:
The new transport API:
It has greatly changed; if you're a developer, please see the
documentation. But as a highlight: jack_set_transport_info() and
jack_engine_takeover_timebase(), (the old timebase master interfaces)
now do nothing. Instead, use jack_set_timebase_callback().
Portability:
<jack/types.h> typedefs are now defined using the C99 standard
fixed-size integer typedefs. These new typedefs are binary compatible
with 32-bit platforms, but not 64-bit machines.
Programs using printf on these values will get GCC compiler
warnings. To suppress the warnings, use the corresponding C99
printf specifications defined in <inttypes.h>. That header is already
implicitly included by <jack/types.h>, but can also be
included explicitly to maintain compatibility with older versions
of JACK without messy #ifdef's. Adding explicit casts will also
work, but may suppress future warnings you might want to see.
jack_get_sample_rate() now returns jack_nframes_t rather than
unsigned long. These are the same on 32-bit machines, but not on
64-bit platforms.
These changes were made to accommodate the increasingly popular 64-bit
platforms; specifically, the new Opteron with it's 32-bit compatibility
mode. 32-bit mode probably won't work, but if all programs are compiled
as 64-bit (which Jack supports), it should work fine.
Taybin Rutkin
Greetings:
I've added some new & updated listings to the pages since posting the
last announcement. Some of the interesting items include Drums++ (a
programming language for percussion), GuitarCodex Plus (excellent
chord/scale utility for guitarists), Pymprovisator (accompaniment
software), and updates for Mixxx and the Music Kit. Just FYI...
Best regards,
== dp
For those who are interested in JACK's transport functionality, the
following message provides a step-by-step example of distributed (as in
multiple independent apps participating in the same session) multitrack
recording, plus some discussion about current limits and usability issues.
Links to the latest snapshot tarballs are available at the very end
of this message. For info about JACK transport, see:
http://www.joq.us/jack/refman/transport-design.htmlhttp://eca.cx/lad/2003/08/0109.html
The Feb'03 mail I refer below can be found at:
http://boudicca.tux.org/hypermail/jackit-devel/2003-Feb/0052.html
It's good to note that I could have used any transport-aware application
in place of the Ecasound instance 'ecafoo' to provide audio tracks to
record against [*]. The application could have been (assuming proper
support is added to them at some point) Alsaplayer, Ardour, SoundTracker,
CheeseTracker, Hydrogen, Gmorgan, etc, etc... you get the picture.
Similarly the recording client 'ecabar' (an Ecasound instance in our
example session) could be replaced by Ardour, Rosegarden, Muse, Audacity
or any other multitrack capable audio recorder.
Sounds good, doesn't it? :) So let's continue with the example:
[*] As we are still developing the transport system and there
are only few apps that follow bleeding edge development,
I had to settle on using Ecasound. :)
---------- Forwarded message ----------
Subject: Re: [Jackit-devel] distributed multitracking
It's more than six months now since I last tried this, time for another
look at this use case:
On Wed, 5 Feb 2003, Kai Vehmanen wrote:
> --------------
> The good news:
[...]
> I just managed to record a piece with three guitar tracks using three
> separate instances of ecasound, each instance handling one guitar take. I
I did the same again with the new transport interface.
Environment:
linux-2.4.19-lowlatency-capabilities-tracepatches
Midiman Delta44 as the soundcard
latest 0.9.6 ALSA drivers
latest JACK and Ecasound from CVS (2003-Aug-25)
I set jackd to use the _maximum_ latency settings for Delta44 (-n 3 -p
1024) to create the worst possible environment for syncing clients.
The test went through unbelievably smoothly. Not a single crash in any app
during the whole testing. Unlike in the test in February, this time I
didn't have to restart all the clients after each and every take and/or
mixdown run. Also, I was now able to seek from any of the Ecasound
sessions or from jack_transport and all the other clients would
correctly follow the changes. Yay! Nice work Jack (J.O'Quin) and JACK! :D
> -------------
> The bad news:
[...]
> Synchronization is a big problem. Let's say you have the following setup:
... and still is.
> alsa_pcm -> ardour
> soundtracker -> alsa_pcm
[...]
> Jackd is run with -p 1024 -n 2, ST is the sync master, hw-monitoring is
> used for the alsa_pcm input. The big problem is that there's no easy way
> for ardour to learn how much non-valid data will come out of alsa_pcm in
> the start. In this distributed recording case ardour should ignore the
> first 2*1024 samples (maximum of ST output and alsa capture latency).
There doesn't seem to be any easy way around this problem. Somehow we need
to provide meta-information concerning how these independent connections
between JACK ports are related (from user POV) to each other.
To solve this for my test case, I added a new option to Ecasound for
specifying explicit multitrack recording offset. The syntax is
"-z:multitrack,XXX", where 'XXX=n*p', 'n' jackd/alsa_pcm period count
and 'p' jackd/alsa_pcm period size in samples. With this meta-info, the
multitrack sync works comparably with a session without JACK.
And finally, a test script for a minimal distributed multitracking
session:
--cut--
# 1. launch jackd and jack_showtime (_very_ useful if something goes wrong)
# 2. test input levels (play something and verify that the meters
# are moving); ctrl-c to exit
ecasignalview jack_alsa
# 3. create the monitor track to play against (15 secs)
sh1> ecasound -i null -o monitor.wav -x -pn:metronome,120 -t:15
# 4. launch the slave client
sh1> ecasound -i monitor.wav -o jack -G:jack,ecafoo,sendrecv -c
ecasound1> engine-launch
# 5. launch the master client (replace 3072 with value corresponding
# to the -n/-p params you run jackd/alsa_pcm with)
sh2> ecasound -a:rec -i jack_alsa -o recorded.wav -a:mon -i jack -o jack_alsa -G:jack,ecabar,sendrecv -z:multitrack,3072 -c
ecasound2> engine-launch
# 6. connect the slave client to the master client
sh3> jack_connect ecafoo:out_1 ecabar:in_3
sh3> jack_connect ecafoo:out_2 ecabar:in_4
# 6. launch jack_transport and control the two multitrack-recorder
# instances
sh3> jack_transport
jack_transport> locate 0
jack_transport> play
# 7. record something against 'monitor.wav' (check jack_showtime output
# if you have problems)
# 8. listen to the result (note! we can let the slave client to run
# all the time)
jack_transport> stop
ecasound2> stop
ecasound2> quit
sh2> ecasound -a:rec -i recorded.wav -a:mon -i jack -a:rec,mon -o jack_alsa -G:jack,ecabar,sendrecv -c
ecasound2> engine-launch
sh4> jack_connect ecafoo:out_1 ecabar:in_1
sh4> jack_connect ecafoo:out_2 ecabar:in_2
jack_transport> locate 0
jack_transport> play
--cut--
... and that's it, the sync should be correct.
If you want to try this, remember to update to latest JACK and ecasound
CVS, or use the following snapshots (note that these are __NOT__ official
releases, so the APIs can still change before the next actual stable
release):
http://ecasound.seul.org/download/other/jack-audio-connection-kit-0.79.2-jo…http://ecasound.seul.org/download/ecasound-2.2.4-snapshot20030826.tar.gz
--
http://www.eca.cx
Audio software for Linux!
Hi,
Announcing Mixxx verison 1.0 for release:
http://mixxx.sourceforge.net/
Mixxx is software for digital DJ'ing, working on Linux, Windows and
Mac OS X. Mixxx is released under the GPL.
New since 0.9.2:
- Waveform displays
- Support for PowerMate controllers on Linux
- Support for joysticks on Linux
- Better MIDI key support
- Better playlist interface with playlists in XML format
- Added support for Ogg Vorbis
- Cue buttons
- New GUI
- Pitch bend buttons
- Fwd/back buttons
- Reverse play button
- Fixes in wavefile and MP3 playback
- Skin support
- Loop and next-track play modes
Thanks to all developers and musicians contributing to the design and
development of Mixxx.
Cheers, Tue
Hello,
Robert Jonsson wrote:
>> So what do you guys think?
>> Does LAD community need an SDK for rapid development of
>> out of process, aseq-to-jack, (plus ladcca ?) synths?
>> Or are there some reasons why this idea is inpractical?
>
> I can't remember the beginning of this thread, though gut feeling is that
> there are already quite a few projects in this vein.
In the beginning of the thread I asked about somthing resembling
"softsynth SDK" (not visual programming environment where I rewire modules,
but the API + libs + headers + etc.)
to create alsaseq->synth->jack (plus ladcca?) synth.
> If you truly want to do rapid synth development you should construct synths in
> Pd or Max,
I was unable to figure out how to connect Pd to alsaseq MIDI.
and found the comment in Pd sources:
" For MIDI, we only offer the OSS API; ALSA has to emulate OSS for us."
I think that there can be a external to catch alsaseq MIDI,
but it stands pretty far from what I would call selfcontained synth.
For the SDK in question I would assume minimum dependacies on external programs.
> or even one of the modular synths, e.g. galan, ssm, ams + probably
Unfortunately ssm seems to be unable to talk to alsaseq too.
I understand that I can use some kind of bridge between OSS and alsa MIDI input
but this is pretty far from the idea too.
> several others, Supercollider comes to mind since it was recently mentioned
> here.
nikodimka
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Hello,
I am Mr. SEGUN AKINTEMI
Assistant General Manager (Information Technology & Operations)
of PRUDENT BANK NIGERIA LIMITED.
On Monday, February 3, 2003, a bomb blast explosion took
place on the Lagos Island, right inside My bank; So far a
total lost of about 35 million us dollars has been
recorded, this includes both cash and property of the
bank. Please View the Link below:
http://www.cnn.com/2003/WORLD/africa/02/03/lagos.explosion/index.html
However as the Assistant General Manager (Information
Technology & Operations) ,I discovered that Most of our Data on accounts has been
lost as well, as there has not been any back up or network trace even
from the HEADQUARTERS;therefore all losseswould be artributed to the
Explosion. The lagos State Government has taken charges to pay for all
losses.
I found out i still have Data's of foreign Customers who are Contractor
in Nigeria and who own accounts with the Branch, Particularly that of
an oil contractor Mr Barry Kelly who was reported Dead in a motor
accident on the 15 of september 2002, who's contract payments has been
Made and would be tranfered to his foreign accounts from the CENTRAL
BANK OF NIGERIA, upon our confirmation of his foreign designated
account as well as a beneficiary to his funds and payments.
Mr Barry Kelly, while our customer never left a trace of his next of
kin, and His contract Payment which is about 10 million US dollars,
would be made to no one as we( the bank) has none of his Data/next of
kin's contact.
my proposal is that I will like you
to stand in as the next of kin to Mr. Barry Kelly so
that the fruits of this old man's labour will not get into
the hands of some corrupt government officials,
I KNOW YOU MIGHT HAVE RECEIVED DIFFERENT PROPOSALS OF SUCH
ASSISTANCE BUT I HAVE ALL INFORMATIONS WITH WHICH YOU CAN
MAKE VERIFICATIONS.BESIDES EVEN THOUGH THE INTERNET IS
FLOODED WITH SCAM I STILL CANNOT AFFORD TO LOOSE THIS
OPPURTUNITY OF A LIFE TIME.
This is simple, I will like you
to provide immediately your bank account information which
you know is suitable to accomodate this funds and your
full names and address so that i can include it in the
next of kin database. You shall be needing the services of
a lawyer, the Lawyer will prepare the necessary documents
and affidavits which will put you in place as the next of
kin. We shall employ the service of the Lawyer for
drafting and notarization of the WILL and to obtain the
necessary documents and letter of probate/administration
in your favor for the transfer. A bank account in any part
of the world which you will provide will then facilitate
the transfer of this money to you as the beneficiary/next
of kin. The money will be paid into your account as claims
by the CENTRAL BANK OF NIGERIA upon the submission of your
information and your application as the next of kin to the
Late Barry Barrington by the Lawyer; Afterwords, the
funds would be tranfered for us to share in the ratio of
70% for me and 30% for you.
There is no risk at all as all the paperwork for this
transaction will be done by the Lawyer and my position as
Assistant General Manager (Information Technology & Operations)
guarantees the successful execution of this
transaction. If you are interested, please reply
immediately to: segunakintemi(a)netster.com
Upon your response, I shall then provide
you with more details that will help you
understand the transaction. Please observe utmost
confidentiality, and be rest assured that this transaction
would be most profitable for both of us because I shall
require your assistance to invest my share in your
country.
Awaiting your urgent reply.
SEGUN AKINTEMI
Assistant General Manager
(Information Technology & Operations)
http://www.prudentbank.net/team-mgt-profile.htm
1. A short summary of changes
Bugs in build process were fixed. Support for transport
functionality in JACK 0.77.0 and newer has been added.
Transport functions are enabeld only if Ecamegapedal is
compiled against Ecasound newer than 2.2.3. Ecamegapedal
was verified to work if compiled against Qt-3.2.
---
2. What is Ecamegapedal?
Ecamegapedal is a real-time effect processor software with
a graphical user interface for controlling the effect
parameters. It is meant to be used as a virtual guitar-fx
or studio effect box. In addition to real-time operation,
ecamegapedal also supports reading from and writing to audio
files. All audio object and effect plugin types provided by the
ecasound libraries are supported. This includes ALSA, JACK,
OSS, aRts, over 20 file formats, over 30 effect types, LADSPA
plugins and multi-operator effect presets. Ecamegapedal's
implementation is based on ecasound and Qt libraries.
Ecamegapedal is licensed under the GPL.
---
3. Contributors
Patches
Junichi Uekawa (1) -- Qt -rpath build optimization
Kai Vehmanen (1) -- JACK transport support
---
4. Links and files
http://www.eca.cx/ecamegapedalhttp://ecasound.seul.org/download/ecamegapedal-0.4.3.tar.gz
--
http://www.eca.cx
Audio software for Linux!
> Frank Barknecht <fbar(a)footils.org> writes:
>
> For a compiled language SFront might be used, where in the end the
> synth description is actually compiled with a C compiler into a synth.
Yes, unfortunately no jack support yet ...
More generally:
http://www.cs.berkeley.edu/~lazzaro/sa/pubs/pdf/wemp01.pdf
sketches out the tricks sfront uses to do the compilation, most
of these would be applicable to specification languages other
than Structured Audio. Doing "audio engine compilation" for an
API or language that has critical mass would be a good project
for someone to do ...
-------------------------------------------------------------------------
John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley
lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro
-------------------------------------------------------------------------
