Greetings:
I've prepared a brief report on LAC 2005 for the Linux Journal, it's
ready for submission but I need an outside photo of ZKM + the Kubus. Did
anyone take a nice shot of the buildings that they'd like to see in LJ ?
If so, let me know asap. A TIFF is preferred, but high-resolution JPG
will probably do. TIA!
Best,
dp
Hello!
Sorry if I'm starting in the wrong place, but after several months
of thinking and two weeks of working, I have a couple of questions.
1.) can FreeBSD 5.4-RELEASE operate without a sound card such that the
Network Audio Server allows applications running on it to have sound
heard on other speakers on the network?
a.) I have "device sound" compiled into the custom kernel
b.) the NASD gives an error about connecting to a block device
when I try to start NASD.
2.) is arts the way to go with ALSA? When KDE starts on my 2.6 kernel
Gentoo system the sound suddenly get louder, as if a new mixer takes
over and bumps the master volume as KDE 3.3 loads.
3.) What is the preferred method to have multiple x86 computers
playing the same stream of sound simultaneously? (within a few dozen
milliseconds)
a.) all the servers have NTP capability and mplayer/xine
4.) How do I have several x86 FreeBSD/linux machines all synchronize
video also? Is that simply XF86 Forwarding?
Yours Truly,
Christopher
Hi,
        I'm looking for a mentor for Google's summer coding project for
students. Â In a nut-shell, a student pairs with a mentor from an established
open source project in order to complete a modestly sized project. Â The
benefits to open source developers are that you get to have someone work on
some code or functionality that otherwise might have been dismissed for a
while. Â Furthermore, you will gain a developer with a long term interest in
Linux audio to contribute to development further down the road. Â Of course,
there are benefits to myself, including money (which students always need),
but I am really looking to get established with some open source software and
gain experience with the development process before I consider moving into
the workforce (unless I stay on to do my PhD ;) and this seems like the
perfect motivation.
        If anyone here is interested in taking this on, please check
http://code.google.com/summerofcode.html and specifically the mentoring
organization FAQ at http://code.google.com/mentfaq.html. Â There is some
misinformation about the need for more mentoring organisations but I've been
in contact and they are still accepting groups.
Thank you for your time,
Kevin Sookocheff
Hello,
Yesterday, we gave a Tutorial called "Linux for Audio" at the AES
Convention, which took place here in Barcelona. To quote the abstract:
"It is obvious that Linux is becoming a real alternative to other
well-known operating systems. But, is Linux ready to support all the
requirements of the audio industry? In this tutorial, the Linux audio
infrastructure will be introduced showing how it compares to and
competes with other operating systems, with emphasis on low latency,
application interconnectivity, and modularity. In addition, various
aspects of this audio infrastructure will be demonstrated, using several
promising applications in the Linux audio arena."
The tutorial was 2 hours long, and consisted of two parts: a talk and a
demo. During the talk we gave several smaller demonstrations. This
worked out really well, because it made the final demo much more agile,
as we already explained many basic features and operations before.
The talk consisted of the following parts: The Linux Operation System
(history, distributions, latency), ALSA, Interapplication connectivity
(jack, alsaseq), Plugins (LADSPA, DSSI, VST), and the final demo.
This demo mimicked a real-life studio situation, with Ardour as the main
application. We had some prerecorded material, but also recorded a new
bass guitar track on site. We demonstrated basic editting with Ardour,
the use of plugins (LADSPA, VST and Jack application inserts), mixing
with multiple output channels, automation with an motorized console
(Behringer BCF2000), synchronization with Hydrogen and with Rosegarden
(connected to fluidsynth), and bouncing the output back to Ardour. We
planned to show Jamin as well, but we ran out of time.
About 80 people assisted the tutorial, which can be considered quite a
lot, taking into consideration that the AES audience seems rather
Windows and Mac OS X centered. A quick "raise your hand" survey showed
that about 40 percent of our audience were developers.
We have the feeling that the tutorial went very well, and that the
audience got a good impression of the possibilities of Linux for audio.
No real technical problems happened during the demo.
We would like to thank all of you who made this possible. That means of
course all of the developers, but also the entire community. We had a
good time giving this Tutorial, and we hope to have generated some
interest in the AES crowd, and given them a good idea of the current
state of Linux audio applications.
We put the slides at http://iua-share.upf.es/wikis/aes/ and tomorrow we
will add some photos. Of course suggestions are welcome!
Pau Arumi
Maarten de Boer
Hi,
Assembling piezo microphones, cardboard, foam, wood and a cymbal stand,
I have just made my first DIY electronic pads. Actually it's electronic
percussions, because I will play these mostly with hands.
I've found a few sites about DIY "edrums" (1), as well as some detailed
documentation about how to build a trigger-to-midi hardware controller
(2). But since I started this little project, I've been thinking about
plugging the piezo mikes directly into my soundcard inputs. My first
tests are very good : the signal is clean, and indicates faithfully how
hard the pads get hit.
I am now about to code a software controller to :
1 - either interprete the signal and produce midi (or OSC) events
2 - or interprete the signal, and play samples by itself, in a
standalone manner (no midi)
I tend to prefer the second option, for the following reasons (criticism
welcome) :
- I want to reduce latency _as_much_as_possible_ (keeping the rythm is
hard enough ;-). To me, the midi layer introduces useless buffers
- I'd like the whole thing to use minimal resources, so that I can run
it on old hardware (simple boxes to be carried in studios and on stage).
In this regard, a small tool built upon Alsa, which run without any
sound server or midi layer, looks to me as the lightest solution
- I don't want to use harware expanders, such as the one that is built
into my soundcard. I want to play samples. With midi, I would then need
a such tool as Timidity, which is pretty heavy according to my latest
tests. Jtrigger seems lighter (http://sparked.zadzmo.org/jtrigger), but
it relies on Jack : I like Jack, but it seems too heavy to me, for this
specific job.
- In regard to clicks and other noises, I believe a lightweight
application running on a dedicated barebone Linux system is more
reliable than a realtime thread with a complex layer as Jack, especially
on slow hardware.
Are these good/coherent reasons to you ? Do you have any other advice ?
Is there already some software that could help me, or some pieces I
could reuse, to achieve any part of this process ?
Best regards
References :
(1) http://edrum.for.free.fr
(2) http://www.midibox.org/edrum
--
og
qjackLaM is a Latency Meter for jack.
There are 2 JackClients now: 1 only outputs, the other only reveives.
This should cause 0 impact on Jacks graphordering concerning the other clients.
Also new: qjacklam measures ALL possible ways by itself and displays the results in a table.
Get the source, cvs and fc3-binary via
http://developer.berlios.de/projects/qjacklam
.
have fun
Karsten
___________________________________________________________
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
Version 0.2.1 of the Oscilloscope DSSI plugin is now available here:
http://www.student.nada.kth.se/~d00-llu/music_dssi.php?lang=en
It has fixes for some bugs spotted by Sean Bolton:
- The GUI will now actually quit when it receives a /quit command from
the plugin host
- There will be no /tmp/dssi_shm_tmpfile_* files left behind when the
plugin and GUI exits
- The Makefile uses pkg-config to get the compiler flags for DSSI, so
it should work now even if your DSSI header is installed in a
non-standard directory
Thanks to feedback from Sean Bolton and Chris Cannam on the DSSI
mailing list I know also know that the plugin works with
ghostess-20050516 and the latest CVS version of Rosegarden (but not
with any releases of Rosegarden).
--
Lars Luthman
PGP key: http://www.d.kth.se/~d00-llu/pgp_key.php
Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E
Hi!
I guess everybody of you know that allocating memory on the heap at runtime in
RT threads is not a good idea. This can easily prevented by user space /
application managed memory pools.
But whatabout the stack? Even if you try to use the heap for local variables
as well, you (usually) won't be able to prevent usage of the stack due to ABI
definitions; e.g. on most platforms function arguments will be delivered
through the stack. So what can you do to prevent physical pages to be
allocated for the stack at RT critical time? Because this would lead to the
same problems as calling malloc(), new and co.
I read: "Although it is possible to give memory back to the system and shrink
a process's address space, this is almost never done." [1] That sounds to me
as once physical memory pages were assigned to the virtual stack range (due
to stack growth), those physical pages were not be freed even if the virtual
stack shrinks (that is the stack pointer increments). Is that true? And what
does "almost" mean in this manner? Unfortunately I'm not into the mm
internals of Linux yet.
If the above claim is true, then we could simply increase the stack for a
short time at the beginning of a RT application, e.g. by calling alloca()
(maybe not good - dangerous and not portable) or by defining a big array on
the stack in a helper function and/or by making that helper function recurse
to a certain level to solve the danger of the stack.
Anybody with deep Linux mm knowledge around?
CU
Christian
[1] http://www.informit.com/articles/article.asp?p=173438