Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

2 participants
7534 discussions

[linux-audio-dev] Re: [Jackit-devel] hangs with 2.4.20, jack and clients... one tiny patch latter

by Fernando Pablo Lopez-Lezcano

> > >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

23 years

[linux-audio-dev] ecamegapedal 0.4.0 released

by Kai Vehmanen

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.cx http://www.eca.cx/ecamegapedal http://jackit.sourceforge.net Source and binary packages: http://ecasound.seul.org/download http://ecasound.seul.org/download/ecamegapedal-0.4.0.tar.gz -- http://www.eca.cx Audio software for Linux!

23 years

[linux-audio-dev] determining pitch of audio

by Lance Blisters

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

23 years

[linux-audio-dev] Additional LADSPA hints

by robbins jacob

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

23 years

[linux-audio-dev] [ANN] JACK TimeMachine 0.0.2

by Steve Harris

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

23 years

[linux-audio-dev] BU FIRSATTAN RARARLANIN.

by MARAMARA Erotik Market

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..

23 years

[linux-audio-dev] [OT] Linux Music & Sound Software site updated

by Dave Phillips

Greetings: As of January 19 2003 the Linux Music & Sound Applications pages have been updated. The site may be reached here: http://sound.condorow.net (USA) Here: http://www.linuxsound.at (Europe) And here: http://www.ymo.org/linuxsound/ (Japan) The Japanese site will not update until January 20. Enjoy ! Best regards, == Dave Phillips The Book Of Linux Music & Sound at http://www.nostarch.com/lms.htm The Linux Soundapps Site at http://linux-sound.org

23 years

[linux-audio-dev] ecawave development stopped

by Kai Vehmanen

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&section=projects My thanks to all who have participated in ecawave development! -- http://www.eca.cx Audio software for Linux!

23 years

[linux-audio-dev] XAP: Cookies and Event Actions

by David Olofson

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 ---

23 years

[linux-audio-dev] this morning's cvs: via82xx build error?

by Fernando Pablo Lopez-Lezcano

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

23 years

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Linux-audio-dev