Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

3 participants
7537 discussions

[LAD] Finding Deadlock causes in multithreaded C++ using gdb

by Harry Van Haaren

Hey guys, I'm working on a mulithreaded version of my pet project, and I've now managed to deadlock one thread, which in turn makes the GUI thread wait for a mutex lock, and then finally segfaults the whole program :-) So I'm looking for pointers on how best to find a deadlock's cause using gdb? Other advice / good articles on the topic etc welcome! Thanks for reading, -Harry

14 years, 11 months

[LAD] Litmus RT kernel

by michael noble

hi all, I just came across this: http://www.cs.unc.edu/~anderson/litmus-rt/index.html. From the site: The LITMUSRT project is a soft real-time extension of the Linux kernel with > focus on multiprocessor real-time scheduling and synchronization. The Linux > kernel is modified to support the sporadic task model and modular scheduler > plugins. Both partitioned and global scheduling is supported. > It seems their latest patch is against 2.6.36. I realize this is not a plug and play alternative to Ingo's work by any means, but I was wondering if anyone more knowledgeable has some insight into what exactly the Litmus kernel may offer... -michael

14 years, 11 months

Re: [LAD] Linux-audio-dev Digest, Vol 49, Issue 6

by Jeff McClintock

> From: Sean Bolton <musound(a)jps.net> > if the GUI is in another process, its really absurdly hard for the > host to add its own controls to the window. not impossible, but a > level of hard that doesn't actually buy the user (or developer) > anything. this means that the kinds of generic "every plugin" controls > like "bypass" or "preset" that ardour adds to LADSPA and AU windows > would vanish. not a huge cost, but a real one. Not very hard, but think more in terms of functionality, not implementation. e.g. my plugin API can provide the GUI a string "Commands for Parameter 23:" - "MIDI Learn, Unlearn, Edit...". The user can right-click any knob on the GUI and get a menu of functions the *HOST* provides for that parameter... With ZERO dependence on the type of GUI. I really like that the feature works with ANY GUI toolkit. The host is free to provide as few or as many options as it needs. That one example of thinking in a platform independent way, without being absurdly hard to implement, in fact real easy. Jeff McClintock

14 years, 11 months

[LAD] engine, validation, ui separation,

by James Morris

Hi, Just a quick question, where does validation of parameters belong? Invalid params might crash the engine, so some validation should go there. But if the job of validation is down to the UI, the engine can be more efficient. But if multiple UIs are possible, validation effort is duplicated. How should I approach? Cheers, James. -- _ : http://jwm-art.net/ -audio/image/text/code/

14 years, 11 months

Re: [LAD] Portable user interfaces for LV2 plugins.

by Jeff McClintock

> From: Paul Davis <paul(a)linuxaudiosystems.com> > Subject: Re: [LAD] Portable user interfaces for LV2 plugins. > VST3 allows the GUI to run in a different process? " The design of VST 3 suggests a complete separation of processor and edit controller by implementing two components. Splitting up an effect into these two parts requires some extra efforts for an implementation of course. But this separation enables the host to run each component in a different context. It can even run them on different computers. Another benefit is that parameter changes can be separated when it comes to automation. While for processing these changes need to be transmitted in a sample accurate way, the GUI part can be updated with a much lower frequency and it can be shifted by the amount that results from any delay compensation or other processing offset." > > The host needs to see every parameter tweak. It needs to be between the > GUI > > and the DSP to arbitrate clashes between conflicting control surfaces. > It's > > the only way to do automation and state recall right. > > well, almost. as i mentioned, AU doesn't really route parameter > changes via the host, it just makes sure that the host can find out > about them. the nicest part of the AU system is the highly > configurable listener system, which can be used to set up things like > "i need to hear about parameter changes but i don't want to be told > more than once every 100msec" and more. It's pretty cool. Yeah. It's important to realise that at any instant 3 entities hold a parameter's value: -The audio processer part of the plugin. -The GUI Part. -The Host. A parameter change can come from several sources: - The GUI. - The Host's automation playback. - A MIDI controller. - Sometimes the Audio processor (e.g. VU Meter). If several of these are happening at once, some central entity needs to give one priority. For example if a parameter/knob is moving due to automation and you click that control - the automation needs to relinquish control until you release the mouse. The host is the best place for this logic. Think of the host as holding the parameter, the GUI and Audio processor as 'listeners'. Or the host's copy of the parameter as the 'model' and the GUI and audio processor as 'views' (Model-View-Controller pattern). Best Regards!, Jeff

14 years, 11 months

Re: [LAD] Portable user interfaces for LV2 plugins.

by Jeff McClintock

> AU, which is the only other plugin API to explicitly support > plugin<->GUI separation. AND VST 3.0, AND GMPI/SynthEdit... The host needs to see every parameter tweak. It needs to be between the GUI and the DSP to arbitrate clashes between conflicting control surfaces. It's the only way to do automation and state recall right. Best Regards, Jeff McClintock.

14 years, 11 months

[LAD] lv2config - packager feedback needed

by David Robillard

Hi all, The upcoming LV2r4 has a new extension header #include scheme, and a tool to enable it, named lv2config. Rather than type everything all over again, see here: http://lv2plug.in/docs/index.php?title=Using_Extensions_in_Code lv2config can be used (like ldconfig) to set up system-installed extension includes, or can be used by an individual project to bundle extensions. Packagers would use it to generate the include hierarchy when building a package for an LV2 extension. This is the part I need feedback on, e.g. someone pointed out the need for DESTDIR, so that is there now. Before release, any other things that need doing to enable packaging of LV2 extensions (a new ability) should be aired out. lv2config is part of core.lv2 which can be had from SVN here: http://lv2plug.in/repo/trunk/core.lv2/ I wrote the C version late last night, but it seems to work for all the cases I can think of. Thanks, -dr P.S. There has already been a lot of back-and-forth on the #include format and use for a tool. This is how it needs to be. Feedback is needed on the /implementation/.

14 years, 11 months

[LAD] C1X

by James Morris

Just stumbled across this and thought some might find it interesting: http://en.wikipedia.org/wiki/C1X "The October 2010 draft includes several changes to the C99 language and library specifications, such as: Alignment specification (_Alignas specifier, alignof operator, aligned_alloc function, <stdalign.h> header file) ... Multithreading support (_Thread_local storage-class specifier, <threads.h> header including thread creation/management functions, mutex, condition variable and thread-specific storage functionality, as well as the _Atomic type qualifier and <stdatomic.h> for uninterruptible object access) ... More macros for querying the characteristic of floating point types, concerning subnormal floating point numbers, and the number of decimal digits the type is able to store. ..." james. -- _ : http://jwm-art.net/ -audio/image/text/code/

14 years, 11 months

Re: [LAD] [patch] Re: autogroup: sched_setscheduler() fails

by torbenh

sorry... i cced the old ML addresses :S fixing the CC now. On Mon, Feb 28, 2011 at 07:29:54PM +0100, Mike Galbraith wrote: > On Mon, 2011-02-28 at 18:53 +0100, torbenh wrote: > > > > On Tue, Feb 22, 2011 at 03:47:53PM +0100, Mike Galbraith wrote: > > > On Tue, 2011-02-22 at 13:24 +0100, torbenh wrote: > > > > On Fri, Feb 18, 2011 at 01:50:12PM +0100, Mike Galbraith wrote: > > > > > > > Sounds like you just want to turn CONFIG_RT_GROUP_SCHED off. > > > > > > > > but distros turn it on. > > > > we could prevent debian from turning it on. > > > > now opensuse 11.4 has turned it on. > > > > > > If you or anyone else turns on RT_GROUP_SCHED, you will count your > > > beans, and pay up front, or you will not play. That's a very sensible > > > policy for realtime. > > > > this probably means that generic computer distros should not turn this > > option on ? > > Yeah, agreed, not for a great default config, but only because > newfangled automation thingies can't (possibly?) deal with it sanely. but this is excactly the reason, why i would advocate rt_runtime to be in a separate cgroups system. any admin who wants to limit RT runtime could still do it. people who dont care, and just want their cfs slices configured, can still do it. > > > > If systemd deals with it at all, seems to me it can only make a mess of > > > it. But who knows, maybe they made a clever allocator. If they didn't, > > > they'll need an escape hatch methinks. > > > > the problem is that audio applications can not really pre allocate their > > cpu needs. user can add processing plugins until he pushes his machine > > to the limit. (or the cgroup where his process is running in) > > > > we dont really have a mechanism for plugins to publish their needed > > cycles. > > I can't see how it could matter what any individual group of arbitrary > groups N (who can appear/disappear in the blink of an eye) advertises as > it's wish of the instant. "Hard" + "Arbitrary" doesn't compute for me. i dont really understnad this statement. > > -Mike > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo(a)vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- torben Hohn

14 years, 11 months

[LAD] [ANN] IR: LV2 Convolution Reverb

by Tom Szilagyi

Hi all, Standing on the shoulders of giants[*], I am pleased to announce the public release of IR, a convolution reverb in the LV2 plugin format. Released as free software under the GNU GPL, this easy to use plugin has been created to open the fascinating world of convolution reverb to Linux-based audio engineers. If you use Ardour to create, mix & produce music, you will most probably want to check out this plugin. Assorted features: * Zero-latency operation * Support for mono, stereo and 'True Stereo' (4-channel) impulses * Realtime operation * Very reasonable CPU consumption * Maximum impulse length: 1M samples (~22 seconds @ 48kHz) * Loads a large number of audio file formats * High quality sample rate conversion of impulse responses * Stretch control (via high quality SRC in one step integrated with impulse loading) * Pre-delay control (0-2000 ms) * Stereo width control of input signal & impulse response (0-150%) * Envelope alteration with immediate visual feedback: Attack time/percent, Envelope, Length * Reverse impulse response * Autogain: change impulses without having to adjust 'Wet gain' * Impulse response visualization (linear/logarithmic scale, peak & RMS) * Easy interface for fast browsing and loading impulse responses IR should work on Linux with Ardour 2.8.x (x >= 11) and 3. For further info and source code download, please visit the plugin's homepage: http://factorial.hu/plugins/lv2/ir Thanks, Tom [*] Fons Adriaensen (zita-convolver), Erik de Castro Lopo (libsndfile, libsamplerate)

14 years, 11 months

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