Hello,
i want to grab some external sources (cdplayer) with jack. i run a jack
instance with 48000 Hz and it works perfectly with my cd player and ardour.
but if i take a cheaper cdplayer, the signal will only be came in with 44100,
because there seems no resample and sync between the master (soundcard) and
slave (cheapoCD) . so, the signal will always being played to slow. i found a
workaround with a small external box, which resamples the incoming signal
before it get into the soundcard.
Since a while, i think about a software solution, which puzzles me a bit. if i
doing the process without the external resampler, what must be done with the
signal.
If the original source is 44100 Hz, the incoming signal is 48000 (because of
jack). if i try to resample it, the current buffer get shorter, because the
signal need to be decreased.
How can a correct resampling process be done?
Thanks c~
Hi everyone,
got nothing to do during the Easter holidays ? I don't think so...
The second edition of ____The LAC Times____ is online:
http://lac.linuxaudio.org/2010/LAC_Times_2010_04_02.pdf
Subjects in this edition:
* A first glimpse of the LAC 2010 programme
* The 150-Years-of-Music-Technology Composition Competition
* A short history of recording sound [part 2]
No longer do you need to worry what to do at Easter. Now you'll worry what to do first:
study the programme to decide which day(s) you're gonna visit the Linux Audio Conference,
work on your composition or read Than's second history lesson.
Enjoy !
Marc
I'll put a printer-friendly version under the News tab of the LAC site soon.
At Grame, we started working on JACK (jack1 at that time) in 2003 and our first commitment was to port the C code base on OSX. Even if the result was working, we rapidly felt that the C code base was not flexible enough to evolve in the direction we wanted to explore: multi-platforms support, SMP and glitch-free connections (among other ideas we had...) . Around 2004-2005 we had a new C++ based code base that was first developed on OSX, later ported in Linux (2005), on Windows (summer 2006) and Solaris (summer 2008 as a result of funding coming from RTL french radio). In 2004 we also found the way to better "integrate" JACK in the CoreAudio architecture on OSX (the JackRouter JACK/CoreAudio bridge) that allowed any CoreAudio application to become a JACK client, thus participating in the success we had on OSX with the JackOSX package.
I think the "about 3 years ago, the JACK mini-summit in Berlin" Paul told about, was actually during LAC 2008 in Kohn. It was my impression that most of the JACK community was interested to see jackdmp (renamed jack2 at that moment) become the future of JACK, and late 2008 and 2009 was an intense period of work to reach this goal. Nedko (mostly but some other) did a huge job of improving the build system, implement the so-called "JACK Control API" (or at least the server side of it) and helped in other areas. The D-Bus based server control code (Nedko) was also integrated at that time.
In spring 2009 started this "D-Bus war" and after endless discussion with people with strong opinions (Fons, Nedko...) it appeared that no agreement could be found. The best that we could achieve (in my view) was to clearly define the "JACK Control API" as the "frontier" between the external world that wants to control the JACK server, and the server code itself, and report all more sophisticated control mechanism outside. At about the same time, some developers (Torben, Paul ...) started to rebirth the jack1 codebase, and it appeared more and more clear that the "jack2 become the official code base" idea start to become a vanishing goal.
I must say that I still don't have a clear understanding of why this happened. I still don't understand the sentence "Like Torben, there are some design decisions there that I have questions about." and I think explaining it in more details would really help. The fact that jack1 and jack2 are almost indistinguishable in everyday use is quite satisfactory, but at the same time the subtle difference that stay continue to cause some endless comments from users about the "real" advantages of each of the two implementations. I still see reports from "more xruns" here or a "bit less CPU use" there, but with no real data and clear "step by step way to reproduce issues" that would help to fix remaining bugs in jack2 codebase (for example jack2 still probably has issue with multi-cards support compared to jack1, but AFAICS this is in ALSA backend, and I cannot progress on that without the help of people with multi-cards and knowledge in ALSA backend code).
Concerning session management added in JACK codebase, I did not followed the discussion in details. I said to Paul in a private mail that I though it was not a good idea (but maybe I am completely wrong...) but I would certainly not oppose to a implementation for jack2. I remember someone volunteered to work on that ??
I have to say that I become quite tired of all that mess, since I don't see any clear way to solve the situation. After about 5 years of real commitment in JACK project, I decided to move back a bit and work on some other stuff. I still try to follow bug reports and jack1 changes, release a package from time to time and maintain JackOSX project. I still think some interesting ideas (like the "pipelining" mode that currently stay in a jack2 branch...) are of interest (especially since we now see with those "4 cores/threads" model in new laptops...) and should be pushed in mainline.
Stéphane
hi folks,
I just saw an interesting line over at opensuse.org (
http://news.opensuse.org/2010/04/14/opensuse-11-3-milestone-5-the-community…)
regarding the installation of JACK2 as default in the upcoming opensuse 11.3
release. That wasn't the interesting part. This is:
The JACK team is coordinating with openSUSE, Ubuntu, and Debian, among
> others, to upgrade to jack 1.9.5 (JACK2) during the spring/summer release
> cycle.
>
This seems to imply that there is quite a large move happening across
multiple distros, and that move is being coordinated with JACK developers.
I'm not a dev and I'm not really comfortable commenting on dev issues, but
is this really accurate? Personally I'd be glad if there were such a move as
JACK2 is what I use, but my understanding is that no announcements have been
made by JACK devs regarding an official obsoletion of JACK1. The reference
provided with that statement is a very short email correspondence on the
opensuse-factory mailing list about the topic that references an unmentioned
debian-multimedia contact.
Are any interested or invested parties willing to provide some clarification
on this? I know distros are fully welcome to package whatever they wish. I
also am pretty sure that whatever happens will happen regardless of my
opinion on the matter. There have, however, been some colorful exchanges
between packagers and devs regarding JACK in the past so in the interest of
transparency and openness I was hoping involved parties might have something
to say about this.
-Michael
This domain has expired
It will be deleted in the next few days. If you are the owner of this
domain, you still have a chance to renew it.
Domain Name
Expires
alsa-project.org
16-APR-10
To renew this domain or to request further information please contact us
at domain(a)forpsi.com.
hermann wrote: [snip ... because it's off-list, but I guess the thread
shouldn't be closed, pardon]
There are several reasons why people like to switch between versions of
JACK and it isn't that easy to do. Not every musician has knowledge
about technique. Comparison to other OS are irrelevant.
So for Debian there are good news, but there are other distros and it's
significant for Linux, that if someone is willing to solve what belongs
to him, than the thread should be closed. But how e.g. will the Suse
package managers handle this?
Users ask to have the choice. I don't need the choice, I only need
JACK2, so from now on I'll be quiet. Anyway, it's not good, if clueless
users don't have the choice.
Ralf
Dear fellow FOSS/Pd/Linux audio enthusiasts,
It is my pleasure to announce the upcoming April 17th (Saturday) spring L2Ork / DISIS event that will feature the debut of the Boys & Girls Club of Roanoke, VA satellite laptop orchestra, as well as several guest artists, including:
Ron Coulter (SIUC, percussion, composition, computer music)
Mark Engebretson (UNCG, composition, computer music, saxophone), and
Matthew Burtner (UVA, composition, computer music, saxophone)
The evening event will be split into:
. 7pm children's showcase designed primarily with children and parents in mind, and
. 8pm benefit concert of experimental music. Funds raised at this event will benefit the Boys & Girls Club of Roanoke, VA, a non-profit organization that offers critical afterschool programs for children. Apart from L2Ork numbers, the 8pm program will also offer compositions involving innovative creative technologies, including musical robots.
The admission to both events is free.
For more information, software goodies, audio and video preview please visit L2Ork's website at http://l2ork.music.vt.edu or find us on the Facebook event page at http://www.facebook.com/group.php?gid=117918141555131 (event page http://www.facebook.com/event.php?eid=112324945463877)
Additional media coverage can be found at:
http://www.linuxjournal.com/magazine (issue #193)
http://www.vt.edu/spotlight/achievement/2010-04-12-laptop/laptop-orchestra.… (Virginia Tech spotlight with audio and video footage)
Following the April 17th performance, L2Ork is embarking on its maiden tour with performances at the College-Conservatory of Music in Cincinnati, OH (April 20th 7:30pm), Southern Illinois University Carbondale, IL (April 22nd 6pm), and IUPUI, Indiana as part of the Intermedia Festival (April 25th 2pm).
So, if you happen to be in the area we'd love to see you there!
Ivica Ico Bukvic, D.M.A.
Composition, Music Technology
Director, DISIS Interactive Sound & Intermedia Studio
Director, L2Ork Linux Laptop Orchestra
Assistant Co-Director, CCTAD
CHCI, CS, and Art (by courtesy)
Virginia Tech
Dept. of Music - 0240
Blacksburg, VA 24061
(540) 231-6139
(540) 231-5034 (fax)
ico(a)vt.edu
http://www.music.vt.edu/faculty/bukvic/
Announcing the latest release of ghostess, a lightweight
GTK+ host for DSSI plugins:
http://smbolton.com/linux/ghostess-20100326.tar.bz2
New in this release:
- support for JACK session management, when compiled
against a recent JACK SVN version (thanks to Torben
Hohn.)
- some small code and compilation clean-ups.
ghostess is written by Sean Bolton, and copyright (c)2010 under
the GNU General Public License, version 2 or later.
DSSI is an audio plugin API for software instruments and effects,
based on LADSPA, the ALSA sequencer event types, and OSC (Open
Sound Control) communications. Learn more about it here:
http://dssi.sourceforge.net/
Enjoy!
-Sean
> A string of note-ons following each other all for the same pitch n without
> any intervening note-offs for pitch n, IS PERFECTLY ACCEPTABLE provided
> they are INTENTIONAL and NOT accidental.
No.
MIDI note-on represents a key press. Note-OFF - key release.
There is no logical way a key can be pressed a second time without first
releasing it.
It might be *technically* possible for a MIDI stream to contain two note-ons
(for the same key)...but it's SEMATICALLY incorrect to launch two voices
because you have no unambiguous way to turn just one instance off.
Back to your question.
a) Nothing, the note is already on.
b) Re-trigger, the voice is reset and the note gets played from the top.
c) Trigger, a new voice is assigned and will play simultaneously to previous
voices.
Given that it does happen accidentally. 'a' and 'b' are reasonable. 'c' is
wrong because with MIDI a key is either 'ON' or 'OFF', it can't be 'ON'
twice.
Anyone deliberately wanting the same key on twice must resort to using two
MIDI channels. Anyone wanting the same pitch twice must either resort to
multiple MIDI channels or to MIDI microtuning commands.
Best Regards,
Jeff
