Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

7516 discussions

[linux-audio-dev] LADSPA plugin parameters realtime control

by Artemio

Hello all! I am here to ask you one thing. If I want sample-precise realtime control for the plugin, should I be getting all the parameters inside the cycle which travels through the buffer contents? E.g., should the code that looks like this: fParameter = *(psMyPlugin->m_pfSomeParameter); pfInput = psXShaper->m_pfInputBuffer1; pfOutput = psXShaper->m_pfOutputBuffer1; for(lSampleIndex = 0; lSampleIndex < SampleCount; lSampleIndex++){ /* do something with the data */ } be replaced by this: pfInput = psXShaper->m_pfInputBuffer1; pfOutput = psXShaper->m_pfOutputBuffer1; for(lSampleIndex = 0; lSampleIndex < SampleCount; lSampleIndex++){ fParameter = *(psMyPlugin->m_pfSomeParameter); /* do something with the data */ } I believe the answer is yes... But maybe I'm wrong? Thanks! Artemiy.

20 years, 3 months

[linux-audio-dev] [ANN] Specimen v0.5.0 and PHAT v0.3.0

by Pete Bessman

Ladies, gents, and those in between, I got back into the hacking thing a couple days ago, and I'm pleased to announce new versions of both the Specimen sampler and the Phat Audio Toolkit. As always, the real tip can be had at www.gazuga.net. The stuff that I remember changing follows: Specimen -------- * Fixed CPU hogging * Added keyboard for setting MIDI parameters * Made patch list auto sorting * Made volume logarithmic PHAT ---- * Added a new widget, the PhatKeyboard Stay tuned for more! Peace out, -Pete

20 years, 3 months

[linux-audio-dev] desktop audio resumed

by Maarten de Boer

Hello, I just did some rereading of some parts of the "What Parts of Linux Audio Simply Work Great?" thread, that talk about the problems with soundcards that do not support multiple streams, and thought it would be good if we could actually come up with an advice to the desktop developers (Gnome and KDE mainly), distribution developers, and audio application developers in general. This document should contain a detailed description of the current situation, of how we got there (i.e. how the desktop "sound daemons" actually created bigger problem than a solution, and why alsa does not do mixing in software by default), of how different user requirements lead to different solutions that are not always compatible (i.e. the "professional audio" vs "normal" users), and of all the different solutions currently available (and interfering with eachother). I believe such an overview is essential. I think most people on this mailing list have a pretty good idea about his, but do others? For example, I get the impression that there is a lot of misunderstanding or ignorance about alsa and dmix. Then it should propose an ad-hoc solution, and some guidelines of how to work towards a future in which everybody (including jwz ;-) ) is happy with linux audio that "just works". (I found jwz rant unjustified and unpleasant, but we can use it in our advantage if we give the right response, which, with a bit of luck (?) will get the same attention from the slashdot hords as jwz's blog) The ad-hoc solution, I believe, is something that should work "right now", or at least, as good as possible, with as little as possible changes to existing applications. For one, this would mean: making sure that dmix is being used when necesary, that no applications use the hw: devices explicitely, but the "default", that OSS applications use libaoss (If I understand correctly, libaoss can be told the use the dmix plugin, while alsa oss emulation will always use the hw device, or am I wrong here?). This is mainly a thing of the distro's. The remaining problem here is what to do with jackd. When the "professional" user runs jackd, and jackd complains that it is not using the hw: device directly, the solution should be obvious for him, and the non-jack apps should continue to work like before (but should be restarted, I suppose). Could anyone comment on this? The "occasional" jackd user can just run jack through the dmix plugin, which, if I understand correctly, would cause higher latency, but we are not talking about the "professional" user here. Proposing a roadmap for the future is much harder, but I think we can talk about that later. For now, I would like your opinion on the issue. Do you agree that such a document would be feasible and useful, and that the proposed structure/contents make sense? I am not sure that the mailinglist is the best way to write this document, maybe we could use a Wiki. I guess the first step would be to look for the relevant messages in the "What Parts of Linux Audio Simply Work Great?" thread, and write a short overview of those. maarten

20 years, 3 months

[linux-audio-dev] Pointer: IETF RTSP stage and studio I-D ...

by lazzaro

Hi everyone, This may be of interest to standards-oriented LAD-folk: http://www1.ietf.org/mail-archive/web/mmusic/current/msg03497.html And the initial discussions: http://www1.ietf.org/mail-archive/web/mmusic/current/msg03498.html http://www1.ietf.org/mail-archive/web/mmusic/current/msg03499.html http://www1.ietf.org/mail-archive/web/mmusic/current/msg03501.html http://www1.ietf.org/mail-archive/web/mmusic/current/msg03503.html Feel free to join MMUSIC and discuss standards-oriented issues, or discuss here for LAD-specific issues. --- John Lazzaro http://www.cs.berkeley.edu/~lazzaro lazzaro [at] cs [dot] berkeley [dot] edu ---

20 years, 3 months

[linux-audio-dev] best LL kernel options with ingo molnar's patch

by Maarten de Boer

hello, any advice on what would be the best kernel options when using ingo molnar's patch for an audio setup? CONFIG_PREEMPT_DESKTOP: Preemptible Kernel (Low-Latency Desktop) or CONFIG_PREEMPT_RT: Complete Preemption (Real-Time) CONFIG_PREEMPT_SOFTIRQS: Thread Softirqs CONFIG_PREEMPT_HARDIRQS: Thread Hardirqs yes or no? right now i am building with CONFIG_PREEMPT_DESKTOP, CONFIG_PREEMPT_SOFTIRQS and CONFIG_PREEMPT_HARDIRQS maarten

20 years, 4 months

Re: [linux-audio-dev] All things LADSPA, your input please

by peter

at some point in the past, Thorsten Wilms did write: > While ladspa control dialogs tend to be ugly, and things like having > sliders for boolean values sucks, I can't say i miss plugin GUIs like > I got to know while using Cubase VST much. Inconsistent eye-candy > nonsense and useless big marketing labels everywhere ... surely you forgot poor contrast? keke ;) Pete.

20 years, 4 months

[linux-audio-dev] FM, Phase Modulation and The Wiki

by Jens M Andreasen

Hi! I am trying to correct some factual errors in wikipedia regarding FM synthesis (aka phase modulation.) The page in qustion is here: http://en.wikipedia.org/wiki/Frequency_modulation_synthesis My current corrections are in italics. Further corrections appreciated I am currently looking at the Casio section near the end (regarding phase distortion.) Wasn't this technique developed way back in the 60's by french academics? mvh // Jens M Andreasen (and yes, somebody ought to rewrite the whole page from scratch :)) --

20 years, 4 months

[linux-audio-dev] [WIP] hdsposc

by Mario Lang

Hi. Since I finally ordered my Multiface, I also started to write a small program which I am going to need since hdspconf and hdspmixer are both GUI only. The idea: hdsposc will offer the RME mixer and the metering functionality via OSC. Why do I write this mail? I'd like to know if someone else could also make use of this tool. If so, I'd like to hear your input what you'd want to exactly do with it. If no one responds, I'll save coding time by ONLY implementing the Multiface (since thats what I can test) and probably not polish it much, since what I need is probably very basic. Oh, and BTW, during coding of hdsposc a question arose: Is it recommended practice to immediately close a hwdep device again after performing a single operation, or would it be OK to leave the hwdep handle open during runtime and only close it again on program shutdown? -- CYa, Mario

20 years, 4 months

[linux-audio-dev] my first LADSPA plugins

by Artemio

Hello all! I am happy to tell you that I've finished my very first plugins. I would like to thank all those who helped me over here to get started and to Tim who kindly provided free plugin IDs. There are four plugins, each with mono and stereo variant: - Clipping Booster - boosts/clips the signal after a non-linear amp - Noisifier - applies AM to the signal with a variable noise source - Non-linear Amplifier - amp with 6 transmission curve types (round/parabolic/sine/etc.) - Variable Noise - generates white/stepped/shot noise Download plugins/docs: http://artemiolabs.com/software/wasp/ Online docs: http://artemiolabs.com/software/wasp/docs/WASP.html Comments and suggestions are very welcome. But please don't be cruel because this is my first serious C coding and very first DSP experience! I've tested the plugins thoroughly in many hosts, I hope they work for you too and will be useful. Artemiy.

20 years, 4 months

[linux-audio-dev] linking multiple .o plugins into a single .so library

by Artemio

Hello all! I have a question regarding linking multiple plugins into a single library. if I do: $ ld -shared -o plugins.so plugins/*.o - then ld complains that g_psStereoDescriptor and g_psMonoDescriptor as well as _init and _fini functions are duplicate and does nothing. If I try: $ ld -shared -z muldefs -o plugins.so plugins/*.o - this does some wizardry on changing the duplicate functions names (_init and _fini) and in the host only the last plugin in the .o files list is seen. As I understand I cannot change the names of _init and _fini because these are standard for libraries (or not?) and names of g_psStereoDescriptor and g_psMonoDescriptor are standard for a LADSPA plgin (or not?)... But what should I do? Or is is better to keep the plugins in separate .so files? Thanks very much! Artemiy.

20 years, 4 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