Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

7450 discussions

by Conrad Berhörster

Hello all, i have written an jackified application for a customer. the main application play a couple of audiofiles (wav) with some effects and filters. Everything works fine so far. From time to time, while loading some more files, jack disconnects my application. the loading process is a seperated thread. i use the thread implementation from wxWidgets, which uses pthreads. Neither my app nor jack crashed, they are running but my app tell my "zombified - calling shutdown handler" the output of jack is. --------------- schnipp bash-3.00# /usr/local/bin/jackd --realtime -d alsa jackd 0.100.0 Copyright 2001-2005 Paul Davis and others. jackd comes with ABSOLUTELY NO WARRANTY This is free software, and you are welcome to redistribute it under certain conditions; see the file COPYING for details JACK compiled with System V SHM support. loading driver .. creating alsa driver ... hw:0|hw:0|1024|2|48000|0|0|nomon|swmeter|-|32bit control device hw:0 configuring for 48000Hz, period = 1024 frames, buffer = 2 periods nperiods = 2 for capture nperiods = 2 for playback **** alsa_pcm: xrun of at least 0.662 msecs **** alsa_pcm: xrun of at least 4.624 msecs **** alsa_pcm: xrun of at least 4.950 msecs **** alsa_pcm: xrun of at least 68.566 msecs **** alsa_pcm: xrun of at least 48.265 msecs **** alsa_pcm: xrun of at least 4.413 msecs **** alsa_pcm: xrun of at least 6.883 msecs **** alsa_pcm: xrun of at least 126.050 msecs **** alsa_pcm: xrun of at least 62.059 msecs **** alsa_pcm: xrun of at least 51.514 msecs **** alsa_pcm: xrun of at least 12.643 msecs subgraph starting at soundroom timed out (subgraph_wait_fd=9, status = 0, state = Running) ----------- schnipp the xruns only appear while load sounds. kernelversion is Linux soundroom 2.6.15.6 #7 SMP PREEMPT Fri Jun 16 22:18:26 GMT 2006 i686 unknown unknown GNU/Linux more /proc/asound/cards 0 [Gina3G ]: Echo_Echo3G - Gina3G Gina3G rev.0 (DSP56361) at 0xea000000 irq 50 1 [CK804 ]: NFORCE - NVidia CK804 NVidia CK804 with ALC850 at 0xea105000, irq 217 and i use the gina3G and now the questions; - is there any way, to get more infos out off jack - any way to keep the app connected or a hint to avoid the disconnection - some days ago i testet the jack version 0.103, but jack uses 100% cpu without any app. just starting qjackctl showed that. thanks very much for some hints. c~

17 years, 3 months

Fwd: Re: [LAD] Traverso 0.40.0 Released

by Remon

Hello, > Second, I noticed there's a click > between segments when I split then using < X >. Strange, are you sure you use 0.40.0 ? :D It would be very helpfull if you could tell me how to reproduce it and/or join us in #traverso / traverso-devel ml to look into this. > Also, when I used < E > for > an external command (SoX - can this be changed?), the clip then becomes > silent. I typed "reverse" into the box. It did reverse the clip, but like I > said - silence. The external processing was a feature request from a user, and given the way traverso works, I stated that creating a Command class to implement the functionality was easy. That turned out to be right, but unfortunately, I didn't get much feedback. The external processing as such is still a somewhat experimental feature, and the command has been hardcoded to sox. If there are more people who would like to see this functionality expended, please drop a note, with what exactly you want to accomplish, how, which parameters and so on. > :) Anyways, then I split the reversed clip and could then hear it. Also, no We did have these problems long ago, weird you have them still.... But it could be related to the external processing not fully tested... > JACK transport support? Please add a wish for this in the bug tracker [1] ! Regards, Remon [1] https://savannah.nongnu.org/projects/traverso/

17 years, 3 months

[ann] CAPS 0.4.0

by Tim Goetze

The C* Audio Plugin Suite reincarnates as version 0.4.0. CAPS is a collection of LADSPA plugins enjoying worldwide favour for its instrument amplifier emulation. In addition, it provides a sizeable assortment of acclaimed audio DSP units, sound generators and effects. CAPS is distributed as open source under the terms of the GNU Public License. http://quitte.de/dsp/caps.html http://quitte.de/dsp/caps_0.4.0.tar.gz This release sees the addition of the fine work of David Yeh at CCRMA on the emulation of classic tube amplifier tone stack circuits (more here: http://ccrma.stanford.edu/~dtyeh/tonestack/ ). Three new plugins are building on the tone stack: ToneStack and ToneStackLT offer isolated implementations, while the new AmpVTS unit combines a refined AmpV and a ToneStack circuit. I'm very grateful to David for his brilliant contribution, and I'm quite positive that those who actively use the CAPS Amps will share this sentiment. Also primarily aimed at the discerning guitarist is the new AutoWah plugin, offering a versatile rendition of this classic audio effect. The last new plugin is Eq2x2, a two-channel 10-band graphic equalizer modeled after an analogue design. -*- Beyond the new plugins, this release also brings tons of major improvements "under the hood". All plugins have been hardened to work glitch-free in the face of invalid control input. Much effort has also been spent on further elimination of denormal numbers everywhere. Parameter smoothing (which is performed in order to prevent zipper noise) has been refined never to occur at the start of processing. The build process can now be configured to take advantage of the SSE and SSE3 extensions on the i686 platform, providing slight performance gains and automatic denormal protection. The HTML documentation has been thoroughly updated to reflect all changes. Finally, thanks to Paul Winkler CAPS now comes with an improved RDF file containing plugin categorisation. For the near-complete list of changes please see http://quitte.de/dsp/caps.html#Changelog -*- Don't hesitate to let me know what you think. Enjoy, and thank you for using CAPS, Tim

17 years, 3 months

LADSPA dilemma

by Tim Goetze

Fellow LADSPA developers, I've been investigating curious bug reports concerning the use of some of the CAPS plugins in Ardour. Most notably, the Eq plugin, a 10-band graphic eq, very often consumes an inordinate amount of CPU cycles and more likely than not even produces a silent output signal (or even worse one containing only samples of inf value). [I'm talking about Ardour/GTK 0.99.3 (built using 1.4.1 with libardour 0.908.2 and GCC version 4.1.2 20061007 (prerelease) (Debian 4.1.1-16) and CAPS up to and including 0.3.0] Even after eliminating each and every possible cause of denormal numbers in the Eq plugin, the problem persisted. It turns out that it is quite simply caused by invalid control parameter values. In order to prevent zipper noise, the Eq unit (like most of the CAPS plugins) smoothens control parameter input. This is done by sweeping internal parameters over the duration of an audio block in run() or run_adding(). In order to prevent an involuntary parameter sweep during the first call to the plugin's run() after it has been activate()d, the plugin has to evaluate the current set of control input parameters in activate(). To prevent problems with unconnected ports, in CAPS an unconnected port points to the lower bound of that port's range. Thus, if a host calls activate() before doing connect_port() on all control inputs, an involuntary parameter sweep is very likely, but at least it's not starting from garbage parameters. Now, Ardour will first call connect_port() and then activate(), just as you'd expect from a well-mannered host (and as is recommended by ladspa.h). However, when Ardour calls activate(), the control inputs point at uninitialized memory (ie. garbage data). A plugin with 10 control inputs like Eq thus stands a fair chance of running into a value of nan or inf, causing all sorts of computational mayhem including the problems described above. So what to do about this? ladspa.h says nothing about the value of control inputs at plugin activation time. What it does say is that plugins should be able to operate on invalid input data without a glitch, and I'm working on making CAPS resolve the issue gracefully. But still, if control inputs are unconnected or point to a value out of bounds, nan or inf at activation time, a plugin cannot perform correct parameter smoothing. Which would be a loss, no? So, dear LADSPA host authors, estimated Ardour developers, I'd like to ask you to make sure your implementation provides plugins with valid and useful control input data at activation time, preferably the values intended to be used at run() time. Cheers, Tim PS: It'd be nice to see a recommendation to this effect in ladspa.h, too.

17 years, 3 months

Re: [LAD] LADSPA dilemma

by Jeff McClintock

> Since LADSPA does not specifiy that control values are valid at > activate(), either As a host developer, I'd like to explain why control values are not valid at activate(). Imagine a modular plugin system which allows chaining of control signals. Assume all plugins are activated before any is run... [A]-->[B]-> 'A's control outputs might depend on it's audio input. i.e. 'A' can't send control signals until run() is called. Given that, 'B's input ports can't ever be valid during activate. Best to not access control values during activate. Perhaps helpful if hosts never provide them... to encourage plugin developers to write robust code ;) Jeff

17 years, 3 months

[ANN] Free Music Instrument Tuner 0.97.6 released

by Gilles Degottex

Hi all, * new Statistic module, look at the screenshots page and guess :) http://home.gna.org/fmit/ss.html * bug fix for JACK Website: http://home.gna.org/fmit Download: http://download.gna.org/fmit Donation page: http://home.gna.org/fmit/donation.html Comments, remarks, tests, bug reports and rotten tomatoes are always welcome. Have fun, Best Regards, Gilles

17 years, 3 months

Re: [LAD] Source code for Open Sound System now available under GPLv2 and CDDL 1.0

by Pedro Lopez-Cabanillas

On Thursday, 14 June 2007 00:41, pete shorthose wrote: > On Thu, 2007-06-14 at 00:42 +0300, Hannu Savolainen wrote: > > Hi folks, > > > > Now it has happened. Open Sound System is finally open sourced. > > http://4front-tech.com/hannublog/?p=5 Quote1: "However the ALSA API is still almost completely undocumented (after three years of it’s release) so how can anybody expect that programmers could develop good applications based on it." Quote2: "For the above reasons the benefits of OSS are widely ignored: [...] * It’s fully documented (OTOH some parts of the documentation are still under construction)." Yeah. The ALSA API is also fully documented, but some parts are still in a work in progress state... What happened to MIDI/sequencer? http://4front-tech.com/hannublog/?p=6 Quote3: "The real problems started few months after that when I tried to document the sequencer/music interface. [...] Due to lack of time I gave up but promised to write the documentation later." Quote4: "The bad news is that there is no MIDI support in OSS 4.0. There are few bugs in the MIDI code and we decided to ship OSS 4.0 without it [...] MIDI support will be included in OSS 4.1 (hopefully within this year)." OK, lets talk about MIDI after some months. Regards, Pedro

17 years, 3 months

Traverso 0.40.0 Released

by Remon

Traverso 0.40.0 Release Announcement The Traverso development team is pleased to announce the release of Traverso 0.40.0 Traverso is a cross platform multitrack audio recording and editing suite with a clean and innovative interface targeted for home and professional use. Changes in this release: * Completely revamped User Interface, with many usability enhancements which is fully themeable. * Improved input event handler, with many new options * CD TOC creation, with integrated CD Burning facilities. * Support for LV2 plugins * Reduced memory footprint for large projects * Ported to Windows and Mac OS X * Command Plugin framework: Extend Traverso's functionality by writing new Commands. Source tarball and installers for Linux, Mac OS X and Windows are available at: http://traverso-daw.org/ Enjoy! The Traverso team.

17 years, 3 months

Re: [LAD] Controller images

by pete

Christian <krampenschiesser@email-addr-hidden> wrote: > Thanks! > This is what I meant, but this control is useless for me. > But I found a way to create this in GIMP. > I made a circle and cutted it to a controller. Now I could select > small > parts of it and set all black colors to red( with > scriptfu->colors->color convert ). > It was a lot of work, but worthy! > so this is what I use right now: > http://www.krampenschiesser.de/screenshots/ksdrumgui.jpg just to be clear, phat uses the rendered output of my animated version of Thorsten Wilms' knob mesh. (i had no creative input at all, i just made Thorsten's mesh move) blender creates a sequence of knob sized frames (with an alpha channel, should that be desired) then, the image magick tool "convert" is used (eg "convert +append output.png *.png" to concatenate the frames into a large single image which can be easily loaded and manipulated programatically. (as is done in the phat knob and numerous other pixmap knobs derived from the galan C code) the method is independent of the code you use so there's no reason why it shouldn't be useful to you. in fact, it's so simple that i've duplicated your red knob design. see here for the blender (.blend) file: http://www.zenadsl6252.zen.co.uk/flat-red-100-frames.blend and here for the output: http://www.zenadsl6252.zen.co.uk/flat-red-100-frames.png it's trivial to change the number of frames, the colours used or the frame size and re-render it. you can also adjust the output filter to sharpen or soften the edges. i must admit though, that with a minimal design like this, you might do well to implement it algorithmically with drawing operations. then you can make run time changes to the appearance. if you want something more complex or tactile then you could use Thorsten's knob animation or give me a shout and i'll knock something out to your specs. (although, bear in mind that my blender skills are somewhat limited so it won't be a work of art =) pete.

17 years, 3 months

Source code for Open Sound System now available under GPLv2 and CDDL 1.0

by Hannu Savolainen

Hi folks, Now it has happened. Open Sound System is finally open sourced. Source downloads are available from http://developer.opensound.com/sources The actual announcement follows. Best regards, Hannu ------------------------------------------------------------------ FOR IMMEDIATE RELEASE 4FRONT TECHNOLOGIES RELEASES THE SOURCE CODE FOR OPEN SOUND SYSTEM CULVER CITY, CA, June 14, 2007: 4Front Technologies is proud to announce the release of the source code to Open Sound System (OSS) v4.0. The software currently runs on Linux, Solaris™, SCO UnixWare™ and FreeBSD platforms. OSS is a cross platform API that provides drivers for most consumer and professional audio devices for UNIX® and POSIX based operating systems, including Linux. Owing to its open architecture, applications developed on one supporting operating system platform can be easily recompiled on any other platform. Licensing Models: Open Sound System source code is now available under 3 licenses: · GNU Public License (GPL) version 2 · Common Development and Distribution License (CDDL) for all operating systems that have full source code available under the BSD or CDDL licenses. · 4Front’s commercial license for using Open Sound incompatible with open source licenses listed above. Commercial licenses are also available for entities not wishing to use Open Sound System under any of the above open source licenses What is being open sourced? The source code includes drivers for most consumer PCI and USB audio devices and operating system support, including binary package generation and sample test programs. Complete documentation and API specification is also being made available to the open source community. A device driver kit (DDK) is also available for developers to implement cross platform device drivers for audio hardware. This eliminates lot of redundant work that has traditionally been required to support any hardware under multiple Unix/POSIX operating systems. Reasons for going Open Source: OSS has been an open API specification with multiple implementations by independent developer communities. This has caused problems for application designers because there are minor differences between the implementations. The new open source community development model makes it possible to replace the obsolete and incompatible vendor specific sound subsystems and OSS implementations with a state-of-the-art implementation developed by 4Front Technologies. The goal has always been to standardize audio under POSIX compliant systems and this includes real time operating systems and embedded systems as well. "We are open sourcing OSS because this provides a great opportunity for different communities to work together to provide wider audio hardware support for all operating systems." said Hannu Savolainen, CTO and chief architect of Open Sound System. Industry Reaction: "It's great to see 4Front releasing OSS under the Common Development and Distribution License (CDDL). It's something the OpenSolaris™community welcomes, and it provides an opportunity to improve sound support for all OpenSolaris™ distributions," says Stephen Lau, OpenSolaris™ board member. "Fluendo is excited to see the open source release of 4Front Technologies advanced OSS implementation for UNIX® and Linux. Getting a unified and advanced sound system across all major UNIX® and Linux variants will be a big advantage for developers. We look forward to working together with 4Front Technologies to make sure the GStreamer multimedia framework and the Open Sound System integrates perfectly with each other", says Fluendo Business Development Manager Christian F.K. Schaller. "With a long history of successful collaboration with 4Front, Creative looks forward to working with the Open Sound System community in ensuring that Creative Sound Blaster Live! and Sound Blaster Audigy sound cards have stable and well-supported drivers on Linux, Solaris and BSD. The open source release of Open Sound certainly helps our goal in providing cross-platform support for our products," said George Thorn, director of digital media relations for Creative Labs. Community Portal A new web site with source code, API specs and forums for the developer community has been opened at http://developer.opensound.com <http://developer.opensound.com/>. For more information and to download the binary distributions of Open Sound System, visit 4Front's WWW site at http://www.opensound.com <http://www.opensound.com/>. --- xxx --- All trademarks and copyrights belong to their respective owners. UNIX is a registered trademark in the United States and other countries, exclusively licensed through X/Open Company, Ltd. Sun, Solaris, OpenSolaris, Sun Microsystems and The Network Is The Computer are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. Open Sound System is a trademark of 4Front Technologies. Copyright (C) 1996-2007, 4Front Technologies, All Rights Reserved. Contact: Dev Mazumdar 4Front Technologies 4035 Lafayette Place, Unit F Culver City, CA 90232 USA. Tel: (310) 202 8530 E-mail: info(a)opensound.com <mailto:info@opensound.com> Fax: (310) 202 0486 Web: http://www.opensound.com <http://www.opensound.com/>

17 years, 3 months

Jump to page:

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