> > >The hang is not happening in any of these processes, as far as I can
> > >tell. It is not always in exactly the same place, although it happens
> > >always around the same area. I can see time suddenly jumping up, there
> > >are xruns printed (huge underruns, not the usual stuff - I assume this
> > >is before rt_monitor degrades the priorities and things return to
> > >normal). This usually is right after ardour's process function returns.
> > >So I have to see which process is actually interrupting all of this and
> > >hanging the whole thing.
> > >
> > >Very confused at this point.
> >
> > can you check the signalled/awake/complete timestamps in the client
> > struct/debug output? these tell you whether/when:
> >
> > (1) jackd woke the client with write()
> > (2) the client woke up from poll
> > (3) the client wrote to the next fifo
> >
> > these are 3 critical steps that tell you whether or not the hang
> > happens between the two processes, or within one of them. each
> > situation is drastically different from the other and we need to know
> > which it is.
>
> If I understand things correctly the problem seems to be happening in
> the alsa_driver_process function (or in alsa itself). Here a list of
> what happens just before the hang with some comments, please correct me
> if I'm wrong:
[very long printout of trace deleted]
Just by chance I stumbled on this message:
http://www.redhat.com/mailing-lists/ext3-users/msg08990.html
(I was looking at latency issues on a 3ware controller - no matter what
I do I get 12-18 mSec hits - google for vm.bdflush and look at the
second link)
"This patch fixes an inefficiency and potential system lockup in the 2.4
kernel's ext3 filesystem. The problem has been present since
2.4.20-pre5."
Aha!! pre5 is when I started having problems!
Latter Andrew tells us:
"Unless task A and task B happen to both have realtime scheduling policy
- if they do then kjournald will never run. The state is never cleared
and your box locks up."
The problem always happens with realtime scheduling :-)
So, I patched the kernel and I've been running jack+ardour SCHED_FIFO
for more than an hour (previously it would die at most in a couple of
minutes). Even stressing the disk with a nice tar. I would hate to have
to post in 1/2 hour saying that it locked again, so this time I will
_not_ say the problem is solved :-)
Try it out.
-- Fernando
1. A short summary of changes
Sliders for parameter control and text inputs for
lower and upper bounds have been added as well as
support for LADSPA-1.1 and ecasound effect parameter
hints. There has been some user interface improvements
and a native JACK support has been added. Updated to
use the new ecasound-2.2 libraries.
---
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. Changes since the last stable release
* Added native JACK support. If compiled with JACK support
enabled, ecamegapedal will upon startup fetch the
current engine parameters from the JACK server, and
initialize the ecamegapedal configuration to work
with JACK. In practice this means that you don't
have to manually set the buffersize and sample rate
parameters to use ecamegapedal with JACK.
* Support for LADSPA-1.1 and ecasound effect parameter
hints.
* Text inputs for overriding default upper and lower
bounds for parameter values.
* Sliders for controlling parameter values.
* Pixmaps for transport control buttons.
* Takes advantage of the newly released ecasound 2.2.0
libraries (does not work with older ecasound releases).
* Should work with all released Qt2 and Qt3 versions.
Tested with qt-2.3.2, qt-3.0.5 and qt-3.1.1.
---
4. Contributors
Patches
Kai Vehmanen
Arto Hamara
Bug Hunting
Jaakko Prattala
Justin Rosander
Junichi Uekawa
Feature proposals
Dan Lyons
---
5. Links and files
Web sites:
http://www.eca.cxhttp://www.eca.cx/ecamegapedalhttp://jackit.sourceforge.net
Source and binary packages:
http://ecasound.seul.org/downloadhttp://ecasound.seul.org/download/ecamegapedal-0.4.0.tar.gz
--
http://www.eca.cx
Audio software for Linux!
is there free software which will, when fed
audio, tell me a precise number for the primary
frequency component? i need to sort/tune some
samples, I want a software solution which is as
good as a human ear. preferrably in the form of
a ladspa "guitar tuner" plugin, so i can employ
in my favorite host.
-geoff
To my own surprise I have to object to the suggestion:
/*
AUDIO_RATE_CONTROL. Hints than an audio control should/could be controlled
by a high time res. slider or control data, but shouldn't be connected to
the next audio signal by default. I can't think of any simple examples off
hand, but combined with MOMENTARY it could be used for sample accurate tempo
tapping.
*/
As is see it, this declares that an audio port should be used for control
data. I oppose because it is ugly to declare a port one thing in its
PortDescriptor only to reverse this in the PortRangeHint. Furthermore, this
ugliness is likely to cause problems in hosts that do not parse this hint
value*. I believe that the true intention here was to undo the requirement
that data ports can only have one value per run() block, but the author
realized that undoing that requirement has significant implications. The
primary problem occurs when the plugin assumes a particular control is
continuous but the host abides by ladspa.h v1.1 which does not allow more
than one control value per block. The plugin will treat that control port's
data pointer as if it pointed to an array of the blocksize passed to run(),
but the host will have only allocated a single value so there is a memory
error.
(*)I argue that turning audio ports into data ports will cause enough host
incompatibility problems that you might as well do it correctly IF you
really feel it's worth it to add this feature. Here are some
incompatibilities which arise from using audio ports as continuous control
ports:
-the host doesn't parse the hint and sends audio to the control resulting in
caucophonous output.
-the host does realize it shouldn't send audio to the "audio" port but
doesn't have a facility for sending control data arrays to audio ports, so
the user is unable to manipulate some of the controls on the plugin. Plugin
writers are more likely to use continuous controls for important plugin
features which warrant the extra detail, so unmodified hosts will be unable
to accomodate very useful plugins that do who-knows-what.
Basically, introducing arrays of control data will force ALL reasonable
hosts to adapt to handle that ability. So I believe we are better off
keeping ladspa.h straightforward and self consistent by eliminating the
strict single control value requirement and dealing with the issues
involved, as opposed to maintaining a false veneer of backwards
compatibility by allowing use of audio ports for control data.
What are the issues involved with eliminating one control value per block?
I think that all you need to do is remove it and add a data port hint
CONTINUOUS which means the host _must_ attach that control port to a whole
block's worth of data for each run. As i said before, this kills backwards
compatibility of hosts, but you are going to do that for the majority of
hosts anyway if you reappropriate audio ports for control data and
reappropriating audio ports is ugly.
As to whether I support adding CONTINUOUS data ports and breaking host
compatibility; i haven't written my host yet so yes i support it because it
will be easy enough to implement (or so i think :)
--jacob robbins.................
_________________________________________________________________
The new MSN 8: smart spam protection and 2 months FREE*
http://join.msn.com/?page=features/junkmail
I've fixed some build issues and theoretically made it slightly more
efficient. If you managed to build 0.0.1 theres no real point in you
upgrading.
Theres also now a webpage of sorts, with a screenshot ;)
http://plugin.org.uk/timemachine/
- Steve
DIKKAT
VIDEO CD :
Iddia ediyoruz.. Hic bir yerden temin edemeyeceginiz ses ve g�runtu kalitesi ile
yuzlerce porno video CD. arSivimiz yenilenmistir. istemis oldugunuz video CD.ler
bire bir yollanir kesinlikle isteginiz harici alakasiz baSka video CD.ler yollanmaz.
Anal. Oral. Vajinal. Grup. Zenci. FethiS. Ayak fethiS. Gay. Zenci gay. Trans. Transexual.
Lezbiyen ve daha bircok ceSit .... <http://www.erotik.sites.cc/>
ZENGIN URUN CESITLERIMIZ :
Sisme Bebekler ..... (Erkek & Bayan) Kesinlikle size hayir demeyecek.
Vibrat�rler ........ Istediginiz boy ve ebatlarda (Vajinal/Anal/catal.Pilli.Motorlu.TitreSimli)
Suni Vajinalar ..... Asla gerceginden ayirt edemeyeceksiniz (Gercek ten hassasiyetinde)
Reailistik Penisler. Gercek ten hassasiyetinde ve dokusunda (Vantuzlu/Deri kemer kilotlu)
Vakum Pompalari .... Ereksiyonu kolaylastirici ve duzenli kullanimlarda peniste irilesme saglar.
Geciktiriciler ..... Erken boSalmayi dert etmeyin (Sprey ceSitleri/Kremler)
Kremler ............ Anal ve Vajinal iliSkilerde kullanabileceginiz kayganlaStirici krem ceSitleri
Uyandiricilar ...... Cinsel istek uyandirici haplar ve damlalar.
Yapmaniz gereken tek Sey <http://www.erotik.sites.cc/> TIKLAMAK ..
NOT : BU MAIL REKLAM AMAcLI OLUP HIcBIR SEKILDE TARAFIMIZDA KAYDINIZ BULUNMAMAKTADIR.
ILGI ALANINIZIN DISINDA ISE EGER LUTFEN DIKKATE ALMAYINIZ TESEKKURLER..
Ecawave will no longer be actively developed. The Linux audio application
scene has changed drastically since January of 2000 when the first version
of ecawave was released. Nowadays there are many FOSS (free and open
source software) audio file editors available for you to choose from. As
replacements to ecawave I recommend:
- Audacity
- GLAME
- GNUsound
- Sweep
- ... check the list at:
http://freshmeat.net/search/?q=audio%20file%20editor§ion=projects
My thanks to all who have participated in ecawave
development!
--
http://www.eca.cx
Audio software for Linux!
While hacking a more uniform control event type into Audiality, I
realized something: The event action *might* be better off as a part
of the cookie.
The voice mixers in Audiality have two types of controls; ramped
controls and controls without ramping. As it is, they're implemented
in different ways, use different arrays, different events and
different event handling code. You use SET for the non-ramped
controls, and ISET, IRAMP and ISTOP for the ramped controls. Same
index means one control for SET, and another for ISET.
Fine; no problem with that so far, since the Patch Plugins (that
drive the voices, implementing mono/poly, envelopes and whatnot) have
intimate knowledge of the voice controls. Everything's hardcoded,
basically.
However, when applied to "real" plugins, this scheme has a problem:
There are two kinds of controls, and they're not compatible in any
way. If you have ramped output, you need a ramped input, and vice
versa.
Now, the idea I had was to drop the event action/type field, and have
receivers encode that part as well, into the cookie. That way, if you
don't have ramping for some controls, you can just encode a different
action field into your cookies, so that when you get those events,
you end up in a different case in the decoding switch(), where you
"fake" the response in a suitable way. Taking some Audiality code as
an example:
switch(ev->type)
{
case VE_START:
voice_start(v, ev->arg1);
...
break;
case VE_STOP:
voice_kill(v);
aev_free(ev);
return; /* Back in the voice pool! --> */
case VE_SET:
v->c[ev->index] = ev->arg1;
if(VC_PITCH == ev->index)
v->step = calc_step(v);
break;
case VE_ISET:
v->ic[ev->index].v = ev->arg1 << RAMP_BITS;
v->ic[ev->index].dv = 0;
break;
case VE_IRAMP:
v->ic[ev->index].dv = ev->arg1 << RAMP_BITS;
v->ic[ev->index].dv -= v->ic[ev->index].v;
v->ic[ev->index].dv /= ev->arg2;
break;
case VE_ISTOP:
v->ic[ev->index].dv = 0;
break;
}
(which requires senders to special-case normal and ramped controls)
becomes:
switch(ev->cookie & 0xf)
{
case VE_START:
voice_start(v, ev->arg1);
...
break;
case VE_STOP:
voice_kill(v);
aev_free(ev);
return; /* Back in the voice pool! --> */
case VE_SET:
v->c[ev->index] = ev->arg1;
break;
case VE_SET_PITCH:
v->step = calc_step(v);
v->c[ev->index] = ev->arg1;
break;
case VE_RAMP:
v->c[ev->index] = ev->arg1 << RAMP_BITS;
case VE_STOP:
break;
case VE_ISET:
v->ic[ev->index].v = ev->arg1 << RAMP_BITS;
v->ic[ev->index].dv = 0;
break;
case VE_IRAMP:
v->ic[ev->index].dv = ev->arg1 << RAMP_BITS;
v->ic[ev->index].dv -= v->ic[ev->index].v;
v->ic[ev->index].dv /= ev->arg2;
break;
case VE_ISTOP:
v->ic[ev->index].dv = 0;
break;
}
Notice the new VE_RAMP and VE_STOP actions? Those are where ramping
events go if you send them to a non-ramped control. Also note that
VE_SET_PITCH no longer needs an extra conditional to run (the rather
expensive) calc_step() for the pitch control.
Just encode whatever action you want into the cookie for each control
connected. A full control target now looks like this:
struct AEV_target
{
AEV_queue *queue;
Uint32 set_cookie;
Uint32 ramp_cookie;
Uint32 stop_cookie;
} AEV_target;
One cookie for each type of action there is for a control. This way,
you can encode *all* aspects of control handling into the cookie,
without adding any significant complexity or overhead to senders. You
could have only one set of control event handlers, or you could have
one set of cases for *each control*! You decide.
I'm definitely switching to this system internally in Audiality.
(And if it's a bad idea, you'll find out...! :-)
(Note that STOP is just to deal with the limited accuracy of the
integer math in Audiality - and that might actually have been a
"false fix" for another bug I found later. Will try without STOP
again, and/or tweak the ramping code. Or just ditch the bl**dy
integer code! :-)
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
Very strange:
I'm seeing this while trying to compile the alsa drivers:
gcc -D__KERNEL__ -DMODULE=1
-I/usr/src/redhat/BUILD/alsa-driver-0.9.0/include
-I/lib/modules/2.4.19-1.llsmp/build/include -O2
-mpreferred-stack-boundary=2 -march=i686 -D__SMP__ -DCONFIG_SMP -DLINUX
-Wall -Wstrict-prototypes -fomit-frame-pointer -pipe -DALSA_BUILD
-DKBUILD_BASENAME=via82xx -c -o via82xx.o via82xx.c
In file included from via82xx.c:1:
../alsa-kernel/pci/via82xx.c: In function `snd_via82xx_create':
../alsa-kernel/pci/via82xx.c:1588: structure has no member named
`rate_lock'
make[1]: *** [via82xx.o] Error 1
The error happens when compiling in an SMP host with gcc2.96, but the
same tarfile compiles fine on a UP host with gcc2.96 (same kernel) and
on another UP host with gcc3.2...
-- Fernando