Linux-audio-dev November 2011

linux-audio-dev@lists.linuxaudio.org

60 participants
38 discussions

Start a nNew thread

Faust MIDI?

by Carlo Capocasa

Hi, is it possible to send and receive MIDI with a FAUST program? Carlo

12 years, 8 months

ALAC codec being added to libsndfile

by Erik de Castro Lopo

Hi all, Just an FYI. I am in the process of adding support for Apple's lossless Audio Codec (ALAC) [0] to libsndfile. Should be done my the end of the weekend. Cheers, Erik [0] http://alac.macosforge.org/ -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

13 years, 1 month

Re: [LAD] "bleeding edge html5" has interesting Audio APIs

by Neil C Smith

David, With the greatest respect to you, and I have a lot of sympathy with your ideas of GUI's using browser / JS technology, your comments on Java are bordering on FUD. I also don't understand the general anti-Java diatribe - it's a library, and it has its uses - why treat it as somehow different to any other library. It's still the best performing VM out there. Once JavaScript allows me to write a single JIT'ed executable that runs cross-platform; links to JACK on Linux, Windows and Mac; allows sub-5ms latency; and lets me drop live-coded fragments into the audio graph - then it gets interesting, but until then JS is still playing catchup! :-) On 21 November 2011 01:15, David Robillard <d(a)drobilla.net> wrote: > * Most Windows computers do not have Java. Source??? Last stats I saw showed Java installs not far behind Flash. And if you take the "link your own VM" option (which is similar to the suggestion re. webkit) it's irrelevant anyway. > * Java is officially deprecated on Mac OS X. hmm .. Java on Mac is actually looking rosier than it has in a long time, now that development is taking place officially as part of OpenJDK. > * Java will never, ever be available by default on any Microsoft > platform That depends - lots of manufacturers install it by default. > * Java is not included in the default installation of the overwhelming > majority of free software operating systems Good! Too many distros install far too much by default. It's a library, it's a dependency, and it's there if it's needed. > * Java requires software installation of some variety (unless you're > seriously going to suggest using Java applets in 2011 with a straight > face...) Applets? God, no! :-) I've no problem with installation though. As I said before, I don't necessarily see web-apps as the ultimate way forward - I personally think the app-store model will hold out because a) app-stores allow certain companies to keep their walled gardens, and b) writing for the browser is always going to be writing to the lowest common denominator. > * Java recently has acquired a lot of legal questions making it not > exactly the wisest investment for new technology. Nothing that affects OpenJDK though. > * There are many cutting edge modern browser implementations, and > activity here is moving at an astonishing pace. Java is a dinosaur. > A dinosaur that the others are still trying to catch up with, mind you! > Regardless, if I may take the liberty of speaking for this community, > making people use Java for something is a sure-fire way of ensuring they > don't use it. And I'll take the liberty of saying I think that's a daft attitude to have! :-) If the application performs a function I need, then I'll consider using it, regardless of what technology underlies it. Best wishes, Neil -- Neil C Smith Artist : Technologist : Adviser http://neilcsmith.net

13 years, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

Pipes vs. Message Queues

by David Robillard

I got curious, so I bashed out a quick program to benchmark pipes vs POSIX message queues. It just pumps a bunch of messages through the pipe/queue in a tight loop. The results were interesting: $ ./ipc 4096 1000000 Sending a 4096 byte message 1000000 times. Pipe recv time: 6.881104 Pipe send time: 6.880998 Queue send time: 1.938512 Queue recv time: 1.938581 Whoah. Which made me wonder what happens with realtime priority (SCHED_FIFO priority 90): $ ./ipc 4096 1000000 Sending a 4096 byte message 1000000 times. Pipe send time: 5.195232 Pipe recv time: 5.195475 Queue send time: 5.224862 Queue recv time: 5.224987 Pipes get a bit faster, and POSIX message queues get dramatically slower. Interesting. I am opening the queues as blocking here, and both sender and receiver are at the same priority, and aggressively pumping the queue as fast as they can, so there is a lot of competition and this is not an especially good model of any reality we care about, but it's interesting nonetheless. The first result really has me thinking how much Jack would benefit from using message queues instead of pipes and sockets. It looks like there's definitely potential here... I might try to write a more scientific benchmark that better emulates the case Jack would care about and measures wakeup latency, unless somebody beats me to it. That test could have the shm + wakeup pattern Jack actually uses and benchmark it vs. actually firing buffer payload over message queues... But I should be doing more pragmatic things, so here's this for now :) Program is here: http://drobilla.net/files/ipc.c Cheers, -dr

13 years, 1 month

Re: [LAD] sliders/fans

by Jeff McClintock

> In other words, you'd expect such a system to behave as if you > had two faders in series. > > Now if the DSP code only sees the sum of the two values (as it > should, having a VCA group is just a user interface issue), Ah, You just contradicted yourself. If you expect the system to behave like two sliders, then the model must represent 2 sliders. The user widgets should not embody decision making, that implies intelligence in the GUI, which is not strictly model-view-controller. Imagine your device supplemented with a 'dumb' pair of MIDI controllers complementing the two GUI sliders, they could not correctly implement the complex interaction between the two gain settings, therefore you need to go back and move that 'intelligence' into the model. Best Regards, Jeff > Message: 18 > Date: Thu, 24 Nov 2011 20:45:09 +0000 > From: Fons Adriaensen <fons(a)linuxaudio.org> > Subject: Re: [LAD] sliders/fans > To: linux-audio-dev(a)lists.linuxaudio.org > Message-ID: <20111124204509.GA14316(a)linuxaudio.org> > Content-Type: text/plain; charset=us-ascii > > On Thu, Nov 24, 2011 at 02:21:25PM -0500, David Robillard wrote: > > > Agreed. Everything here is about the *view*. How that maps to > actual > > parameter values is an underlying model issue. > > Not always. Consider the case of 'VCA' groups for faders. That > is: you have a slider that controls the gain of a group of > channels (without those being mixed). The effective channel > gain (in dB) is the sum of the per channel fader value and > the one from the group fader. The model sees only this sum. > > Now a fader has to go down to zero gain (-inf dB). So you would > map the lowest possible (finite) value of the widget to something > that the model (the DSP code) would translate to 'off'. > > The question is then: is this exception handled by the widget and > the DSP code, or by the DSP code only ? > > Suppose the minimum value of the widget would correspond to say > -100 dB if not handled specially. If you just have a single fader > per channel, you could arrange for the model or the DSP code to > translate that to 'off'. That is no longer the case if you have > 'VCA' faders. > > There are two thing you'd expect from such a system: > > * If either the channel or the group fader is at minimum, then > the channel must be off (zero gain). > > * If the channel fader is at -50 dB, and the group at -60 dB > you don't want zero gain, but -110 dB. Becaus either fader is > still in a position where you'd expect that moving it makes a > difference. > > In other words, you'd expect such a system to behave as if you > had two faders in series. > > Now if the DSP code only sees the sum of the two values (as it > should, having a VCA group is just a user interface issue), then > that implies that the mapping of the minimum fader position (e.g. > -100 dB) to something that would be interpreted as 'off' by the > DSP code (e.g. -9999999 dB) _must be done by each individual > fader_. > > > Ciao, > > > -- > FA > > Vor uns liegt ein weites Tal, die Sonne scheint - ein Glitzerstrahl. > > >

13 years, 1 month

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