I'm starting jack via jackstart like this:
jackstart -v -R -d alsa -d ice1712 -r 44100 -p 64 -n 2
I can run ecasound in many ways (different chain settups, via ecaplay,
wav or ogg input, etc.) one time only. If I try to run another ecasound
session without restarting jack the second ecasound exits like this:
audiobox:~$ ecaplay /mnt/audio/in_progress/guitar_mix/s2004-0217-2242.ogg
***********************************************************************
* Message from libecasoundc:
*
* 'ECASOUND' environment variable not set. Using the default value
* value 'ECASOUND=ecasound'.
***********************************************************************
(ecaplay) Playing file
'/mnt/audio/in_progress/guitar_mix/s2004-0217-2242.ogg'.
exiting...
It doesn't return ... just hangs like that until I ctrl-c it. If I
strace the ecaplay it's waiting for ecasound:
audiobox:~# strace -p 450
Process 450 attached - interrupt to quit
waitpid(451, <unfinished ...>
Process 450 detached
which is stuck in a futex():
audiobox:~# strace -p 451
Process 451 attached - interrupt to quit
futex(0x413e6bf8, FUTEX_WAIT, 453, NULL
Once I kill the ecaplay w/ctrl-c the "ecasound -c -D" remains until I
use kill -9 on it.
Anything else I can do to help debug this?
System details below.
Thanks,
Eric Rz.
asus a7v8x-x
athlon XP 2800+ (2071.203 MHz)
1.5GB PC2700 RAM
12GB / /dev/hda2 ext2 (actually a 40G disk)
160GB /mnt/audio/ /dev/hdc1 ext2
2GB swap /dev/hda1
(onboard via8235 -- disabled)
ice1712 M-Audio Delta-66 w/omni i/o
ymfpci guillemot maxisound fortissimo -- midi only
debian testing (sarge)
2.6.2 (pre-empt on, drives tuned -- kernel.org sources compiled via
debian's make-kpkg)
realtime-0.0.2 lsm (insmod'ed since make install screws up all
other
modules)
alsa-1.0.2 (lib, envy24control, tools)
alsa-1.0.2c drivers:
./configure --with-isapnp=no --with-sequencer=yes --with-oss=no \
--with-cards=dummy,virmidi,ice1712,ymfpci,via82xx
libsndfile-1.0.6
from tar.gz
jack-0.94.0
./configure --enable-capabilities --enable-optimize \
--with-default-tmpdir=/dev/shm --disable-portaudio
ecasound-2.3.2
./configure --enable-pyecasound --disable-oss --disable-arts \
--with-largefile
ams-1.7.3
simsam-0.1.7 was released. Changes include:
- multiple instruments
- multiple outputs (JACK only)
- config loading (at last)
- some fixes & cleanups
- some new bugs ;-)
Source tarball and i386 .deb for Debian/unstable are available at simsam's SourceForge download page.
http://sourceforge.net/project/showfiles.php?group_id=65022http://simsam.sourceforge.net/
cheers,
Christian Henz
Anybody know what's the minimum latency that can be achieved passing MIDI
notes from one computer to another?
I'm wondering if it's possible in theory to set up an audio generation
cluster to be used as a realtime instrument. Basically, have a network
aware synthesis app running on all machines, administer the
setup/modification of the signal flow architecture from one master machine
in non-rt over sockets, and then pass notes to the appropriate machines
using midi interfaces. Naturally this depends on a signal path separable
into big chunks. I have a hunch that midi over ip has latency too high and
unpredictable for this.
-jacob
Hi,
Gungirl Sequencer is an easy to use Audiosequencer.
It includes a simple Filemanager and uses Drag & Drop to
arrange Audiosamples.
This is the new Release 0.2.0 of Gungirl Sequencer, it comes with a
bunch of new Features, and for your convinience is provided in the
preferred standard Distribution Formats for both Linux and MS Windows:
- Statically Linked (all dependencies included) RPM-Package
- Autoconfified (./configure, make and make install) Source Package
- Executable ( .exe) Installer for MS Windows
The new features in this Release are:
* A simple Ruler
* Select Samples with rubber-frame
* MiniPlayer for Pre-Listening
* Customizable Snap-Value
* Track Mute and Volume
* Master Volume
* Snapless Sample-Positing
* Info-Box for Sample-Files
* Progress-Bars for File loading
* uncountable Bug-Fixes
Check it out at:
http://ggseq.sourceforge.net/
-Richard Spindler
Hi,
Gungirl Sequencer is an easy to use Audiosequencer.
It includes a simple Filemanager and uses Drag & Drop to
arrange Audiosamples.
This is the new Release 0.2.0 of Gungirl Sequencer, it comes with a
bunch of new Features, and for your convinience is provided in the
preferred standard Distribution Formats for both Linux and MS Windows:
- Statically Linked (all dependencies included) RPM-Package
- Autoconfified (./configure, make and make install) Source Package
- Executable ( .exe) Installer for MS Windows
The new features in this Release are:
* A simple Ruler
* Select Samples with rubber-frame
* MiniPlayer for Pre-Listening
* Customizable Snap-Value
* Track Mute and Volume
* Master Volume
* Snapless Sample-Positing
* Info-Box for Sample-Files
* Progress-Bars for File loading
* uncountable Bug-Fixes
Check it out at:
http://ggseq.sourceforge.net/
-Richard Spindler
pleased to announce the initial release of the caps audio plugin
suite under the GNU public license.
quoting http://quitte.de/dsp/caps.html :
caps, the C* Audio Plugin Suite, is a collection of refined LADSPA
units including instrument amplifier emulation, stomp-box classics,
versatile 'virtual analog' oscillators, fractal oscillation, reverb,
equalization and others.
some of caps is an improvement over previous efforts (the rewritten
amplifier emulation plugins for example do 8x oversampling using
polyphase filters, for much cleaner sound) but most of the plugins are
ex nihilo creations.
for those with an interest in DSP effects but no time or opportunity
to run the plugins, the data sheets provided through the above
document may be interesting.
enjoy,
tim
Paul Winkler wrote:
> Hi folks, and Tom if you're listening,
>
> The description of the TAP Scaling Limiter is
> very interesting - http://tap-plugins.sourceforge.net/#limiter
> I'm just curious, having done no real DSP coding -
> it must do some internal buffering, right?
Right, i have to admit it does :)
That's why the plugin has to have latency.
> So how does it deal with half-cycles that fall on the edge of a
> buffer? It seems to me that you can't process the final
> half-cycle without refilling the buffer, but you can't refill the
> buffer until you've processed all its data - or can you?
Yes you can. No, you can't actually, but you can eliminate the problem
so you don't have to solve it. There is a ringbuffer, with a length
chosen so it is capable of containing a whole half-cycle even at low
frequencies (40 Hz is the limit in my implementation, which means
varying number of samples at varying samplerates). Incoming audio is
streamed into the ringbuffer (which actually works like a FIFO), and
the half-cycles are being scanned starting from the other end of the
buffer (that is, where output falls out).
Now let's say the buffer is just full of audio. The host calls run(),
and the plugin starts scanning backwards (from the oldest sample, that
is, the one just about to fall out of the FIFO, towards the newest one),
and marks zero-crosses and scales the marked individual zero-crosses. It
keeps track of the half-cycle boundaries, and when it reaches (or more
likely, overgoes) the N samples the plugin was asked to process in this
run() call, it pushes out the N samples, but that of course will be in
no relation with the half-cycle boundaries. Some piece of the last
half-cycle will remain, and at the next run(), the plugin will continue
the zero-cross scan from that point, not from the buffer boundary. But
it counts the N samples needed to be pushed out from the buffer
boundary, of course. I'm afraid i can't explain it very clearly, but i
hope you get the feeling.
Tom
ps. stay tuned, more plugins are about to arrive... expect them
in a week or two. :)
[Sorry for cross-posting - feel free to forward around]
Dear all,
I'm sending this e-mail to all mailing lists/persons I think (often
with a less-than-optimal inductive process) could be interested in the
future of what's currently know as the "AGNULA Newsletter". If you
receive multiple copies of this e-mail or if you are not interested at
all in the subject, please excuse me and drop everything to the
bitbucket.
First, a bit of history. The AGNULA newsletter was born in Nov 2003
(more or less) as a service to our users who could be informed of new
software releases, events, research achievements in the field of music
& sound, with specific preference given to topics related to Libre
Software. You can see some more information here:
http://www.agnula.org/documentation/newsletter/
(you can find the past issues archive at the same URL).
The AGNULA Newsletter was never meant to be AGNULA-centric (although,
as was recently pointed out on our mailing lists, the naming we chose
could suggest that) but rather as a way to spread information about
the above mentioned topics - and of course to talk about AGNULA news,
if relevant.
Over the time we managed to send around 12 weekly issues of the
newsletter to our `newsletter-dist' mailing list subscribers, who
currently amount to 70. Honestly, given the young age of the
newsletter and the amount of manpower we've been able to put into it,
I'm not too dissatisfied with these numbers.
However, as the AGNULA project is reaching the end of its funded
lifetime I think it's high time that we think whether the AGNULA
Newsletter should become something bigger and better organized. What
does this mean?
Basically, I'd like to understand whether the wider GNU/Linux audio
(and video?) community is interested in turning the newsletter into a
"community project". What we would basically need is:
(a) that Libre Software project maintainers add the newsletter contact
address (currently newsletter-collect(a)lists.agnula.org, but this is
not cut in stone) so that when they send announcements about new
releases the newsletter team is notified more quickly;
(b) a (team of) editor(s) for the newsletter. I've been doing that
for the past months, but time pressure is growing and since my
position as AGNULA technical manager will end in April, I forecast I
won't have the same amount of time to dedicate to this project. A
native english speaker would be preferred, of course;
(c) a (team of) news pieces collectors/writers. The AGNULA project
can give (or try to give :) all the necessary instruments needed by
the newsletter team to coordinate their work - that means CVS, bug
tracking system, mailing lists, whatever;
(d) [optional] a (team of) translators to create nationalized versions
of the newsletter. This is of course a long-term goal and can be put
aside for the moment.
So, the question is: do you think this - turning the AGNULA Newsletter
into the "AGNULA Newsletter on Sound & Video" or even the "Newsletter
on Sound & Video", although I'd like the AGNULA name to remain
somewhere in the newsletter, if anything for sentimental reasons :) -
is a good idea?
If any of you think it is, I would encourage all of you to discuss the
topic on:
users(a)lists.agnula.org
http://lists.agnula.org/mailman/listinfo/users
If you are not subscribed to the mailing list, don't worry - I'll
authorize your messages as they arrive. Please put a clear sign that
you want to be put in Cc: for replies.
Thanks for your time and attention,
Andrea Glorioso
AGNULA Technical Manager
The second major of version of Specimen has been released today. The
main change is the new sample editor that allows you to fine tune the
way your samples are being played. I've also created some
documentation, and added ping-pong and reverse play modes.
Download it from www.gazuga.net, and read up on it at
www.gazuga.net/guide.
[pb]
Hi folks, and Tom if you're listening,
The description of the TAP Scaling Limiter is
very interesting - http://tap-plugins.sourceforge.net/#limiter
I'm just curious, having done no real DSP coding -
it must do some internal buffering, right?
So how does it deal with half-cycles that fall on the edge of a
buffer? It seems to me that you can't process the final
half-cycle without refilling the buffer, but you can't refill the
buffer until you've processed all its data - or can you?
--
Paul Winkler
http://www.slinkp.com
Look! Up in the sky! It's FIGHTER CARBOHYDRATE!
(random hero from isometric.spaceninja.com)