Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

4 participants
7502 discussions

by Aurélien Leblond

> And ... > > Checking for 'g++' (c++ compiler) : /usr/bin/g++ > Checking for program pkg-config : /usr/bin/pkg-config > Checking for 'lv2-plugin' >= 1.0.4 : yes > Checking for 'lv2-gui' >= 1.0.4 : not found > The packages are installed and come from one package so if it finds one, it > should also find the other! Hmmm, that's a weird one! My only explanation is that you have the file /usr/lib/pkgconfig/lv2-plugin.pc but not /usr/lib/pkgconfig/lv2-gui.pc... Could you check on your system? Btw, what distribution do you use? >From my side, I'm not even sure I need to check for both libraries in my wscript... As you said, they come from the same lv2-c++-tools package. Thanks for the feedback anyway :) Aurélien

13 years, 6 months

Ardour3 - strange problem

by Fons Adriaensen

Hello all, Trying out Ardour3 but I'm blocked... I deep-copied an existing A2 session, paradiso-2, to /audio/ardour3-sessions. But A3 complains that it can't find the audio files in /audio/ardour3-sessions/paradiso-2/interchange/paradiso-2/audiofiles which is the right place, and the files are there. ??? -- FA Vor uns liegt ein weites Tal, die Sonne scheint - ein Glitzerstrahl.

13 years, 7 months

NASPRO 0.3.0 released

by Stefano D'Angelo

Hi all, I'm glad to announce the release of NASPRO 0.3.0. NASPRO (http://naspro.atheme.org/) is meant to be a cross-platform sound processing software architecture built around the LV2 plugin standard (http://lv2plug.in/). The goal of the project is to develop a series of tools to make it easy and convenient to use LV2 for sound processing on any (relevant) platform and for everybody: end users, host developers, plugin developers, distributors and scientists/researchers. This release introduces a new simple command line effect processor using LV2 plugins called LV2proc, adds experimental translation of DSSI programs to LV2 presets, breaks the API of lower level libraries to make them slimmer and more efficient, and includes as usual bugfixing and improvements here and there. You can find detailed ChangeLogs in the tarballs. It includes: NASPRO core: the portable runtime library at the bottom of the architecture; NASPRO Bridge it: a little helper library to develop insert-your-API-here to LV2 bridges; NASPRO bridges: a collection of bridges to LV2 which, once installed, allow you to use plugins developed for other plugin standards in LV2 hosts; LV2proc: a simple command line effect processor using LV2 plugins. In particular, the NASPRO bridges collection includes two bridges: a LADSPA (http://www.ladspa.org/) 1.1 and a DSSI (http://dssi.sourceforge.net/) 1.0.0/1.1.0 bridge. NASPRO core, NASPRO Bridge it and NASPRO bridges are released under the LGPL 2.1, while LV2proc is released under the GPL 3. Enjoy!

13 years, 7 months

AMS LV2 0.0.4

by Aurélien Leblond

Hello everyone, I just posted a new version of the AMS LV2 plugins: https://sourceforge.net/projects/avwlv2/files/latest/download The main change from the version 0.0.3 is a embeded GUI for the VCO. As a reminder, these LV2 plugins are a porting of the AMS internal modules designed to be used in a modular synths (especially Ingen). At the moment, the Analog Driver, normal and Advanced Envelop, Amp, LFO, Mixer, Noise2, Slew Limiter, VCA (Exponential and Linear), VCF and VCO2 have been ported. This should be enough to be able to create basic patches, and two presets for Ingen are available in the package. Testers, comments, feedback....everything is more than welcome! For the ones who wants to create LV2 plugins, the code is written in C++, using Lv2-C++-Tools and GTKMM (the GUI designed with Glade). The code is quite simple, making them examples on how to mix all these things together and be able to design LV2 plugins quickly... Aurélien

13 years, 7 months

Cue2ddp Release 0.8.3a

by Andreas Ruge

Hi, I'd like to announce version 0.8.3 alpha of some DDP mastering tools I've written for Linux. If you are interested, and especially if you have other software which reads or writes DDP please test! I'm not a professional C programmer, but a recording producer, so I appreciate any input! http://ddp.andreasruge.de Cue2ddp converts cue/wav CD images into DDP 2.0 images, the format that plants often use internally to drive their glass mastering process. So when using DDP instead of an audio CD plants will usually not mess around with your project anymore, but just press what you send them. (Which can be a good thing.) Aside from the software mentioned I'd like to find out what people think is the best workflow for final CD mastering including DDP. By having cue2ddp as a stand-alone program, it can be used with all programs which can export cue/wav. Is that flexible enough, would you want other input formats? Or would you rather want to see an interface which can be more tighlty integrated into ofther software? Let's say cue2ddp would accept cue sheet *and* audio data from stdin, then any software could simply pipe into it. Very low tech, I know, but reading the DDP license I'm not sure if I can release a proper DDP library as open source (let me know if you think atherwise: www.dcainc.com). Also while we are at it, is there any need for other (proprietary) CD image formats, like .pmi (Pyramix Workstation), or JAM on OSX? Regards, Andreas -- Andreas Ruge recording producer/balance engineer Germany

13 years, 7 months

for samplecat's dev

by Renato

Hello, is the samplecat dev on the list or does someone have his mail? The feedback form on http://samplecat.orford.org/ is broken and I leaved a comment some days ago, which is still waiting moderation, and I fear it got lost. best wishes, renato

13 years, 7 months

Re: [LAD] Linux Audio Documentaion Effort : (Was "Question 0")

by thijs van severen

Documenting (code) is always a good idea. Its hard enoug to find and motivate people that have good coding skills, so the last thing you need is for those people to get frustrated while trying to find out where/how they should start. Transparent, error-free documentation, website and active mailing list are key here! I dont have coding skills, but if you need someone to help with the documentation as such, i'm willing to help. Grtz Thijs On 28 Nov 2011 11:19, "Sebastian Moors" <mauser(a)smoors.de> wrote: Am 28.11.2011 03:46, schrieb Iain Duncan: > > I also think it's a much needed idea. I'd be happy to do some contributing too, but like Harry,... Hi, a great idea! I'm sure that you will see valuable feedback from this list if you publish your tutorial, imho this ensures a good quality. Do not discuss to long over question like the correct toolkit. Those can lead away too easily from the core problem. Take the one your familiar with! - Sebastian _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists....

13 years, 7 months

Linux Audio Documentaion Effort : (Was "Question 0")

by Harry van Haaren

Following recent emails on list about documentation and learning "Linux Audio Programming", I've been thinking about an effort to help people get started with Linux Audio Coding. I think some "beginner" coding documentation on Linux Audio would be a great asset to the community, and I'm willing to contribute to such an effort. As Robin Gareus mentioned in another thread, a "FLOSS" manual is probably the best way to go for a community effort on documenting. I've been doing some "tutorial" style programming articles on my blog harryhaaren.blogspot.com and I'd have no problem sharing the examples there (some basic GTK stuff, some small JACK apps, combining the GUI / JACK stuff ). Problem is that I was learning as I was going along, and there are some *fundamental* issues with some of the tutorials (especially with regards to thread safe code & more advanced programming concepts) Personally I'd be even more enthusiastic about such an effort if some of the veteran Linux audio guys were to get on board and ensure the content is of a high quality. (As I'm a self though programmer, there are some big gaps in my knowledge, and I'd not like to provide bad sample code, or share bad concepts.) Of course some issues will arise in choosing how to document Linux Audio, and some typical "flame" topics like GUI toolkits, libraries etc will arise. I have no idea how we can best avoid that issue, except by following the "if you think it should be thought that way write the tutorial"... the downside of this is that if one tutorial uses toolkit <X> and the next toolkit <Y>, the average beginning coder is going to get lost in implementation details and that defeats the purpose of documentation :D -Harry

13 years, 7 months

Another call for brave testers: new Guitarix LADSPA plugins

by Andreas Degert

Hi, we'd like to ask those who are interested in the new Guitarix LADSPA plugins to run them on their systems and give us some feedback. They do fine on our own machines and seem to be fit for wider testing. The plugins "Guitarix Amp" and "Guitarix Stereo Fx" wrap all of the entire sound engine of Guitarix. You can load a preset that you defined with the Guitarix program, and even define some parameters for DAW automation. It's explained in our wiki: https://sourceforge.net/apps/mediawiki/guitarix/index.php?title=How_to_use_… Our SVN: svn co http://guitarix.svn.sourceforge.net/svnroot/guitarix/trunk guitarix After checkout, build with ./waf configure && ./waf && sudo ./waf install for an installation to /usr/local. Our tracker: http://sourceforge.net/tracker/?group_id=236234 Your feedback will be welcome here or there or anywhere.. Or in our forum: http://sourceforge.net/apps/phpbb/guitarix/ so please, don't be shy and tell us your test results or if you think the concept is usable / unusable :-) ciao Andreas

13 years, 7 months

Re: [LAD] Pipes vs. Message Queues

by Kjetil Matheussen

David Robillard: > On Fri, 2011-11-25 at 15:21 +0100, Nick Copeland wrote: > [...] >> >> So if the pipe() is replaced with >> >> socketpair(PF_UNIX, SOCK_STREAM, PF_UNSPEC, pipe_fd); >> >> Then the issue I was seeing goes away. Perhaps the pipe() code has not >> been >> optimised since sockets were developed to replace them when IPC suddenly >> needed to be between hosts rather than processes? Pure conjecture. > > Added sockets: > > Normal scheduling: > > $ ./ipc 4096 1000000 > Sending a 4096 byte message 1000000 times. > Pipe recv time: 7.048740 > Pipe send time: 7.048648 > Socket send time: 2.365210 > Socket recv time: 2.365292 > Queue recv time: 2.072530 > Queue send time: 2.072494 > > SCHED_FIFO: > > $ ./ipc 4096 1000000 > Sending a 4096 byte message 1000000 times. > Pipe send time: 5.279210 > Pipe recv time: 5.279508 > Socket send time: 2.709628 > Socket recv time: 2.709645 > Queue send time: 5.228892 > Queue recv time: 5.228980 > > Interesting. I find sockets being significantly faster than the much > simpler pipes quite counter-intuitive. > > Code at the same location: > > http://drobilla.net/files/ipc.c > On my computer, sockets are sometimes slower than both pipes and queues. However, by making sure the two processes doesn't change CPU during runtime, sockets are always the fastest, and I get consistent results: Realtime, same CPU: [kjetil@ttleon c]$ ./ipc 4096 2000000 Sending a 4096 byte message 2000000 times. Pipe send time: 7.762312 Pipe recv time: 7.762423 Socket send time: 4.607025 Socket recv time: 4.607103 Queue send time: 7.278029 Queue recv time: 7.278052 Realtime, different CPUs: [kjetil@ttleon c]$ ./ipc 4096 2000000 Sending a 4096 byte message 2000000 times. Pipe recv time: 5.520099 Pipe send time: 5.519875 Socket send time: 2.856027 Socket recv time: 2.856136 Queue recv time: 3.049226 Queue send time: 3.049159 Non-realtime, same CPU: [kjetil@ttleon c]$ ./ipc 4096 2000000 Sending a 4096 byte message 2000000 times. Pipe send time: 7.331822 Pipe recv time: 7.332272 Socket send time: 4.520883 Socket recv time: 4.520959 Queue send time: 7.103408 Queue recv time: 7.103448 Non-realtime, different CPUs: [kjetil@ttleon c]$ ./ipc 4096 2000000 Sending a 4096 byte message 2000000 times. Pipe recv time: 4.305804 Pipe send time: 4.305587 Socket send time: 2.899696 Socket recv time: 2.899806 Queue recv time: 3.028210 Queue send time: 3.028151 [kjetil@ttleon c]$ diff -u ipc.c~ ipc.c --- ipc.c~ 2011-11-26 00:55:38.000000000 +0100 +++ ipc.c 2011-11-26 14:51:44.003407960 +0100 @@ -41,9 +41,10 @@ // Comment out this line to disable RT scheduling //#define SET_RT_SCHED 1 -#ifdef SET_RT_SCHED +#define _GNU_SOURCE +#define __USE_GNU #include <sched.h> -#endif +#include <pthread.h> static inline double elapsed_s(const struct timespec* start, const struct timespec* end) @@ -177,6 +178,14 @@ return time; } +static void bound_thread_to_cpu(int cpu){ + cpu_set_t set; + CPU_ZERO(&set); + CPU_SET(cpu,&set); + pthread_setaffinity_np(pthread_self(), sizeof(cpu_set_t), &set); +} + int main(int argc, char** argv) { @@ -218,6 +227,11 @@ return 1; } + if (child_pid ==0) + bound_thread_to_cpu(0); + else + bound_thread_to_cpu(1); // set to 0 to run both on the same CPU + #ifdef SET_RT_SCHED struct sched_param param; param.sched_priority = 90;

13 years, 7 months

Jump to page:

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