Linux-audio-dev November 2003

linux-audio-dev@lists.linuxaudio.org

84 participants
92 discussions

Re: [linux-audio-dev] Re: linux-audio-dev Digest, Vol 2, Issue 24

by Stefan Nitschke

>But you do have it recompiled for the right CPU architecture >and not only moved? Yes of course. >BTW: There is a prefech bug on AMD processors - try to run it recompiled >with less optimization, newer kernels have workarounds. I will try that... but I get the freezes only with jack. ALSA applikations run just perfect in rt mode. >Another thing to try is to run memtest86 (SuSE has it in Lilo menu) >let it run for a while (full night) I will do... and if nothing helps I will get a new mainboard ;-) - Stefan _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail

20 years, 9 months

Re: [linux-audio-dev] Re: linux-audio-dev Digest, Vol 2, Issue 24

by Roger Larsson

On Tuesday 18 November 2003 20.57, Stefan Nitschke wrote: > >ping is answered = IRQs live. > >Could you please try this. > >Start rt_monitor in a text console CTRL-ALT-F1 > > > >Start your client, return to console - what does rt_monitor print? > > > >(It could be the memory leak and mlockall(FUTURE) problem, > >As I do not check that yet. > >Another alternative is a fast forking client - they are hard to stop) > > OK, I tested it. There is no output at all from rt_monitor. > I used the following: > - starting rt_monitor in a console as root > - ssh login from remote machine > - starting jack > - starting a jack client What client? Any client? > > after a few seconds the machine was froozen and no output > from rt_monitor. Hmm... > I assume its a hardware bug. On my Inspiron 8500 with nearly > the same linux-2.4.19.SuSE kernel (plus patch for speed-step) > I dont have any freezes at all. But you do have it recompiled for the right CPU architecture and not only moved? BTW: There is a prefech bug on AMD processors - try to run it recompiled with less optimization, newer kernels have workarounds. Another thing to try is to run memtest86 (SuSE has it in Lilo menu) let it run for a while (full night) /RogerL -- Roger Larsson Skellefteå Sweden

20 years, 9 months

[linux-audio-dev] ecasound 2.3.1 released

by Kai Vehmanen

1. A short summary of changes Ecasound's emacs mode, ecasound.el, has been updated to version 0.8.3. Due to severe bugs found in the native Python ECI implementation, the C implementation has been again set as the default. Minor interoperability problems with older JACK releases and Ecasound have been fixed. A bug that caused builds against an external libreadline to fail, has been fixed. Also recording problems with the WinTv 401Dbx and other bt878-based devices have been fixed. This release is compatible with the upcoming alsa-lib-1.0 releases. --- 2. What is Ecasound? Ecasound is a software package designed for multitrack audio processing. It can be used for simple tasks like audio playback, recording and format conversions, as well as for multitrack effect processing, mixing, recording and signal recycling. Ecasound supports a wide range of audio inputs, outputs and effect algorithms. Effects and audio objects can be combined in various ways, and their parameters can be controlled by operator objects like oscillators and MIDI-CCs. A versatile console mode user-interface is included in the package. Ecasound is licensed under the GPL. The Ecasound Control Interface (ECI) is licensed under the LGPL. --- 3. Changes since last release Full list of changes is available at <http://www.wakkanet.fi/~kaiv/ecasound/history.html>. --- 4. Interface and configuration file changes None. --- 5. Contributors Patches - Accepted code, documentation and build system changes Mario Lang (ecasound.el updated to 0.8.3, doc typo fixes) Junichi Uekawa (ecasound makefile bug, doc generation using Hevea) Kai Vehmanen (various) Bug Hunting - Reports that led to bugfixes (items closed) Hirendra Hindocha (2) -- recording problems with WinTv 401dbx, ecacontrol.py bugs Stefan Bundt (1) -- ecacontrol.py breaks under heavy load Dave Phillips (1) -- errors in EIAM help Junichi Uekawa (1) -- compability bug with older JACK versions --- 6. Links and files Web sites: http://www.eca.cx http://www.eca.cx/ecasound Source packages: http://ecasound.seul.org/download http://ecasound.seul.org/download/ecasound-2.3.1.tar.gz Distributions with maintained Ecasound support: Agnula - http://www.agnula.org Debian - http://www.debian.org FreeBSD - http://www.freebsd.org/ports/audio.html Gentoo Linux - http://www.gentoo.org PLD Linux - http://www.pld.org.pl SuSE Linux - http://www.suse.de/en Contrib Packages and Add-On Distributions: AudioSlack for Slackware - http://www.audioslack.com PlanetCCRMA for RedHat/Fedora - http://www-ccrma.stanford.edu/planetccrma/software Thac's RPMs for Mandrake - http://rpm.nyvalls.se Apps.kde.com packages for Mandrake/Redhat/SuSE - http://apps.kde.com/rf/2/info/id/2146 Note! Distributors do not necessarily provide packages for the very latest Ecasound version. -- http://www.eca.cx Audio software for Linux!

20 years, 9 months

[linux-audio-dev] [PATCH] oss driver for jack 0.90.0 - the actual patch :)

by Jussi Laako

Looks like I forgot to attach the patch... -- Jussi Laako <jussi.laako(a)pp.inet.fi>

20 years, 9 months

[linux-audio-dev] [PATCH] oss support for jack

by Jussi Laako

Hi, I've written preliminary OSS driver for JACK. Patch for jack 0.80 attached. This is by no means final, this is something pre-alpha, but seems to work at least with alsaplayer. It's likely to contains errors in jack driver implementation. All comments/patches/anything is welcome.. If you are compiling with OSS Lite, please comment out the non-S16 formats. RedHat RPMs and patch available at http://www.sonarnerd.net/linux/ , SuSE 9 packages coming. -- Jussi Laako <jussi.laako(a)pp.inet.fi>

20 years, 9 months

[linux-audio-dev] and just to finalize ...

by Paul Davis

what would all this mean for LADSPA? 1) there would need to be a way to associate plugins+GUIs since we probably don't want them in the same object. - could be done using LRDF or a dir search path combined with the plugin ID. 2) the GUI would have to declare which toolkit it was using so that the host could ensure support for it (i.e. fire up a thread that will run the equivalent of gtk_main or QApplication::exec()) and ask the relevant toolkit thread to call the primary entry point to the GUI. how does it declare this? a well known symbol? is it a char* or a function call? is it in the LRDF entry, or the filename, or what? 3) adopt a standard for how the entry point is to be called. presumably it should get a pointer to the plugin instance, but what (if anything) else? oh yes, a return value that provides a way to terminate the GUI. 4) the names of toolkits would have to be standardized and possibly include version information. "GTK+:2.2" or "Qt:3.1" might work, for example. 5) a small library (which i have more or less started already) to provide simple C functions to offer per-toolkit support. a host would look at the pluginGUI toolkit, call the support function with the .so name, and the right things would happen. the library needs an ancillary function to kill the GUI when the time is right. 6) [ only if we really wanted hosts to have a "real" handle on the plugin GUI window ] the library would need to contain a way to pass in an X "Window", and wrap it up as a native drawing area for each toolkit. i would prefer not to do this for now, if ever. --p

20 years, 9 months

Re: [linux-audio-dev] Re: linux-audio-dev Digest, Vol 2, Issue 24

by Stefan Nitschke

>BUT, I think a userspace daemon that starts at boot time and protects >against lockups (rt_monitor) would be a very good thing to have. > Yes indeed, but on my XP machine which freezes after a few seconds after a client had connected to jack even rt_monitor did not helped, the machine keeped totally locked. Ping is still answered but thats it. - Stefan _________________________________________________________________ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail

20 years, 9 months

[linux-audio-dev] Ann. Vstserver V0.2.8 and Ladspavst V0.1.5

by Kjetil Svalastog Matheussen

These updates makes it possible to use windows vst plugins in linux applications getting very descent realtime performance. I have successfully ran vst plugins in ardour with 2.66 ms latency. Sources: http://www.notam02.no/arkiv/src/ Linux Vst Compatibility Page http://80.61.20.184/vst/ Tutorial: http://www.djcj.org/LAU/quicktoots/toots/vst-plugins/ Mandrake binaries: (not the latest versions (yet)) http://rpm.nyvalls.se/sound9.1.html Vstserver 0.2.7 -> 0.2.8: ------------------------- -Added SCHED_FIFO priority and locking all mem (mlockall) to the processing thread. Can be used without being root by for example using the givertcap program by Tommi Ilmonen http://www.tml.hut.fi/~tilmonen/givertcap/ To turn off realtime priority, start the vstserver with either the "-NRT" or "--nonrealtime" flag. vst ladspa plugin v0.1.5 - stable ---------------------------------- -Fixed the worst nonrealtimeness for the default mode. When using realtime priority on the vstserver, it should not be necesarry to set LADSPAVST_RT to "1". --

20 years, 9 months

[linux-audio-dev] ladspa-1.2 diff

by Taybin Rutkin

Can this get applied? We discussed it in September, and I thought it was going to be applied, but it never was. It includes defines for: LADSPA_HINT_MOMENTARY LADSPA_HINT_RANDOMISIBLE Taybin

20 years, 9 months

[linux-audio-dev] LADSPA: proposition for polyphonic use of plugins

by Alfons Adriaensen

Hello LAD, I'd like to propose an extension of the LADSPA specs, or more correctly, a particular interpretation of the current specs, in order to support the use of plugins in a 'polyphonic' context. The problem to be solved is this: In a host such as AMS, a plugin can be loaded as part of a polyphonic patch. This means that there will be as many instances of the plugin as there are voices, but all of them share the same parameters and user interface. To the user they look as a single module. Now a plugin could have resources that can be shared between voices of a polyphonic instance, but not in general between al instances. For example there could be precomputed (w.r.t. the sample rate code) tables that depend on a control parameter. At the moment there is no mechanism to tell instances of a plugin that they are part of a such a polyphonic group. I propose the following solution, which does not require the definition of new data or functions in the interface. It has been tested with AMS, and works well. It is also backwards compatible. Plugins or hosts that do not care about polyphony can just ignore these requirements. 1. Plugins that contain code that is specific for polyphonic use must implement all four 'lifecycle' functions, i.e. instantiate(), activate(), deactivate() and cleanup(). 2. If a host wants to create a polyphonic instance, it first calls instantiate() for all voices, then activate() for all voices. To remove a polyphonic instance it first calls deactivate() for all voices, and then cleanup() for all voices. To create or remove multiple instances that do not form a polyphonic group, a host always calls both instantiate() and activate() c.q. deactivate() and cleanup(), for each instance before dealing with the next. 3. If a plugin detects that its instantiate() function has been called N > 1 times before the first call to activate(), it knows that some of the recources created by the first activate() can be shared with the other voices. The symmetrical treatment of deactivate() and cleanup() helps to keep the 'destructor' code simple. Comments invited ! -- FA

20 years, 9 months

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

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