Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

2 participants
7534 discussions

by Thorsten Wilms

Oh well, just read through the more than 30 mails ... Thanks to Arnold, Marek, Tim Hockin, Benno, Uwe, Tim Orford for the nice words. Thanks to everyone for the interest. About a standard toolkit: The general desktop toolkits do not adress some special needs of audio apps, that's clear. While an integrated look/feel with other, non-audio apps, would be nice, it can hardly be achieved (think alone of theming). Therefor a somewhat alien look could be of advantage (better clearly different than somewhat alike). Unification advantages: write once, get used to once, allowing usage to become somewhat subconcious (switching between different looks/feels doesn't allow that). It would be great to have all scalable vector guis (especialy interesting options for modular systems, overview vs tuning). Even without scaling, I think I would prefer to deliver plain SVG. Beside implementations in the major toolkits there's also Y at the horizone, with a base collection of widgets that is planned to be extendable with modules. About generating plugin guis from parameter descriptions: don't forget that layout is important. There would have to be some hints for that at least. I'm working on something very general regarding user interfaces, and widgets will be one topic. This should give me a nice foundation for an audio toolkit design from the look and feel side. So how about building a standard for exactly that: look and feel? Who's with me? About the implementation: wouldn't it be possible to wrap things up in enough ways to every capable developers likes? For people like me it would be more interesting to have gui editors / high level descriptions for concentrating on design. (hand writing xml or similar is acceptible for me, fiddling around with c code rather not) To Rtaylor: I'm all for breaking away from analog limitations. But I still think that a little 3d look helps with making clear what is manipulatable and what is not. And I hope it's possible to make both purists and eye-candy freaks happy enough (I'm myself more on the purist side, being german industrial design student, think Bauhaus and all :) And would you say what I presented is not clear/easy to read/decipher? About advanced knob functionality: For resetting knob with center (pan) I would rather replace the simple line mark with an arrow, that can be clicked for reset. Mousewhell should work, of course! Backwards decrease, forwards increase, to match with scrollbars/sliders. When Ctrl is used for finer adjustment, Shift or Alt could boost. Plus/minus buttons could also work. Right-click must be preserved for context menus (knobs could of course have such). For numerical input making use of a text field close to the knob might be better (but in any case only when numerical exactness makes sense). Tim Hockin: please elaborate about velocity sensitve knobs like used by OhmForce. A special fine adjustment accessible by a non-left click or with modifier key is a little problematic, because it breaks the connection between scale/indicator and mouse movement (not that I'm against it, only wanted to point this out). Clicks/modifier keys should not be user options. No need for extra coding, overloaded preferences / layout problems and users fiddling around instead of using the software. Radial? For those who think radial is bad: in that case knobs shouldn't be used at all! (Tim Hockin: it makes no sense to disagree to a half sentence/meaning!) Popping up a slider doesn't help much, the nature of the control should be clear right away. However, I never had problems dealing with radial knobs, but always found linear ones do not feel right. There's no need to move the pointer accurately in circular fashion, a soft bow works perfectly fine. I do not say knobs are perfect / better than sliders or other solutions in all cases, and I'm aware of the problems. Oh, and about linear needing 2 directions, up/down for gain and right left for pan (Uwe): Sure. And the widget has to be clear about that in advance. About releasing the knobs Everybody can have the existing svg, png export or Blender 3d files (just ask). I doubt I will continue with Blender, so future work will be vector or directly bitmap. Like I said, it's not finalized at all. ATM I do not know how to best generate series of bitmaps for rotations. Would be nice if someone could help with a little imagemagick or gimp scripting to do the rotation and combine it with fixed parts. Benno: I think Dave Robillard is right. Only when you're very sure the saved space can be put to better use, knobs ar an option there. And the design would have to be adapted to fit in. --- Thorsten Wilms

21 years, 7 months

[linux-audio-dev] Re: Graph reordering

by Juhana Sadeharju

>From: Paul Davis <paul(a)linuxaudiosystems.com> >>> >>>> you cannot modify the graph in JACK while the graph is being used to >>>> process audio. you do not know how long the graph modification will >>>> take if you try to do it (for example) right after you're done with >>>> one process cycle. the only sure way to do this is to use lock free >>>> parallel programming techniques. >> >>Would anyone please explane details of these techniques? > >No. Google for "herlihy lock free". Dozens of references. Papers range >from about 12 years ago to this year. I did mean the details on the graph modification. Up so far I have not understood what is the problem in modifying the graphs in the engine. It sounded like you solved the problem using lock-free par prog techniques. By reading the solution I could catch up the problem. ;-) Want explane what kind of modifications you mean? Why they take so much time? Juhana

21 years, 7 months

[linux-audio-dev] OT: priority inversion on Mars

by Lee Revell

Apologies if everyone here has seen this, it's not really linux or audio related, but I think people will find it interesting and somewhat relevant: http://research.microsoft.com/~mbj/Mars_Pathfinder/Mars_Pathfinder.html Lee

21 years, 7 months

[linux-audio-dev] lock-free data structures

by Joshua Haberman

Greetings, all. I have not been subscribed to this list for several months now, but someone pointed me to a link to Paul's message that I quote below. I realized that now is a good time to check back in, see what everyone is up to, and let you know what I'm up to. A few days ago Paul posted: > the only sure way to do [live graph modification] is to use lock free > parallel programming techniques. this is still a highly experimental > area of computer science, and i have yet to see more than a glimmer of > a technique that would actually work in a complex real time system > like JACK. Right now I am very interested in lock-free data structures, and I am working with Ross Bencina (of PortAudio and AudioMulch) to implement them in an open source library. See [0] and [1]. It turns out there are several practical algorithms being published in this field, most notably by Maged Michael from IBM research. Ross and I have been in contact with him for advice and clarification about his papers, which are available on his web site [2]. We have some working code, but since all this stuff is highly architecture-specific we need to do more research. A significant part of the library will probably end up being in assembly. For me, this is part of a bigger effort: rewriting Audacity's back-end, and making it a GUI-independent library. We're tentatively calling this library "Mezzo" -- more about Mezzo's goals and basic API is at [3]. Mezzo's data representation scheme is just a refactoring of what Audacity uses now, but the real-time system will be completely redesigned to be similar to JACK's model: several nodes with input ports and output ports that implement callbacks. The whole graph will be run from the audio api's callback. Getting back to lock-free data structures, my intention is not to use locks anywhere in this real-time system. Since I haven't written the whole thing yet I'm not sure if this is completely possible, but here is my general strategy: 1. signal graph is constructed in main thread 2. once audio starts, the audio thread runs the graph once for every callback 3. if the main thread wants to change the graph while it's running, it does any heavy lifting (memory allocation, etc), then sends a message to the audio thread with a lock-free queue (ex: "add this node and connect it to this other node"). 4. buffers are passed between the disk thread and the audio thread using lock-free queues 5. in the real-time thread, buffers are allocated from and returned to a lock-free freelist. For example, if you have a node that generates a sine wave, it needs to allocate a buffer when it runs to put its data in. Instead of calling malloc, it asks for a free buffer from the freelist. The real-time code is still in its beginning stages, but I have gotten it to play data from disk by sending it from a disk thread to an audio thread. You can see the code in our SVN repository. [4] I'm also keeping a log of my activity and my thought process on my web site [5]. I am interested in any reactions people may have to this work. I drew a lot of the inspiration for Mezzo's real-time system from JACK and other things I have read on this list. Regards, Josh Haberman [0] http://www.audiomulch.com/~rossb/code/lockfree/ [1] http://www.audiomulch.com/~rossb/code/lockfree/spec.txt [2] http://www.research.ibm.com/people/m/michael/pubs.htm [3] http://www.audacityteam.org/wiki/index.pl?Mezzo [4] http://mezzo.homelinux.net/svn/ [5] http://www.reverberate.org/log/

21 years, 7 months

[linux-audio-dev] Multithreaded programming for a poll model?

by Mario Lang

Hi. I am currently trying to figure out how to restructure the code of my little yatm tool to be flexible and extensible in the future. Basically, I'd like to be able to become a JACK client at some point in the future. Since JACK uses a poll model, I have to majorly restructure my code. I think what I need is the following: Three threads, one for the UI, one for the MPEG/Vorbis/Speex decoder, and one for audio output (to either libao or JACK). I'll also need a buffer between the decoder and the audio thread, and some way to signal the decoder thread that more audio data is needed. Additionally, I'd like to have the ability to make the buffer in between remember the last n seconds of audio data and make it possible to jump back in time <=n seconds during playback. I've looked at the lock-free ringbuffer of JACK, but I am not sure if this is really what I need here. I am very new to linux audio programming, and especially to pthreads (wrote my first thread using program two days ago). I'd be very happy if some of you experts here could give me a hand here and point me into the right direction. Maybe there is already code out there which does roughly that which I can look at? Or maybe you can suggest which mechanisms of pthreads I should be using for this kind of scenario. -- CYa, Mario | Debian Developer <URL:http://debian.org/> | Get my public key via finger mlang(a)db.debian.org | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44

21 years, 7 months

[linux-audio-dev] Linux soundapps Euro site back on-line

by Dave Phillips

Greetings: The European mirror of the Linux soundapps site is back online with a new address: http://linuxsound.atnet.at Please update your bookmarks. This site is now in sync with the US and Japanese sites. Best regards, dp

21 years, 7 months

[linux-audio-dev] jack in a live situation

by Dave Griffiths

Hi all, A question regarding jack use in a live setting. As far as I can tell the soft mode only works with non realtime jack. What should I do if I want realtime performance, but a really forgiving server, so dropouts never cause the server to timeout. It's more important to me to have continuous rather than glitch free audio (I never ever want everything to shut down) If the answer is ultimately to write better jack clients - thats Ok ;) cheers, dave

21 years, 7 months

[linux-audio-dev] Project Ideas

by michael tewner

OK. I have permission to get one of these programs moving with some constraints (appended). WHich do you guys think would be most useful (publishable :-) )? 1. The OpenGL Spectrogram implemented into Steve Harris's meterbridge 2. A 31-BAND (or more?) graphic EQ These would both be implemented into JACK My advisor requested these specs: 1- This should be run on any platform including PC platform. <Yeah, right. Perhaps I"ll just implement the code, and wrap it with JACK and WIN-API with preprocessor commands....Grrr...> 2- The interface would be build with a Tcl/Tk script which is compatible with SGI/ Aplle and PC platform. <I'm just not sure he knows what he's talking about...Anyway, I think he just wants an interface that will work on linux and windows...again, see #1> 3- The FFT algorithm should be run in parallel and optimize at least for two platforms. <I guess once we're splitting up the spectrum, this shouldn't be a problem...BTW,the advisor teaches an MPI course. This idea probably came from this...I'm not sure what he means by "2 platforms."> 4- We can use a Wavelet Transformation inside of FFT and to parallize it. <*shrug* I'm gonna hafta do some research. wikipedia says it's like a FFT running in O(N) instead of O(N log N): http://en.wikipedia.org/wiki/Wavelet_transform > I can recomend against some of these. I just think he wants me to do some extra work... Granted, without these recomendations, I'm not looking at the suggested 500 Hours of work... This project is starting to look big and clunky: 1. Implementing both windows and linux 2. Parrellizing the code? I don't mind writing multithreaded or MPI... it just looks like overkill.... 3. Can JACK compile on IRIX? That's his OS of choice (Being his only *nix experience...) and, well, SGI's are fun! Perhaps I can convince him to put linux on his old O2. Anyway, bottom line, it'll be fun, and I don't mind spending my time on this, if ANY part of it will be of use.... ...I'de just hate to kill Steve's code, though. Anyway, suggestions? Thanks y'all! -Mike

21 years, 7 months

Re: [linux-audio-dev] Is ladspa actually la-dsp-a? Is JACK the ultimate solution?

by eviltwin69＠cableone.net

Hey, I wouldn't mind working on the graphics, I just don't know where to start or who else is working on it. Jan On Tue, 8 Jun 2004 09:18 , Steve Harris <S.W.Harris(a)ecs.soton.ac.uk> sent: >On Tue, Jun 08, 2004 at 11:45:53 +0200, Marek Peteraj wrote: >> VST plugins tend to be rather complex, offering tons of features and >> eyecandish GUIs, while LADSPAs usually offer limited functionality, no >> GUI at all(hosts usually provide simple ones to control the parameters). >> But what's interesting is that each LADSPA plugin usually implements >> exactly one type of DSP technique, for example, an oscillator, or a >> delay. This basically leads to a situation where a certain DSP technique >> is 'isolated' in a separate plugin. > >I think thats down to two factors (and its not a good thing) > >1) LADSPA developers are few in number and short in time. The basics are a > good place to start. > >2) The lack of a UI standard makes complex plugins a bit pointless. > >There are a few counter examples (e.g. my VyNil plugin wraps a lot of >different bits), and infact if you look in many LADSPA plugins you will >see theres really more going on than there appears to be. > >[OT] - my canned plugin writing experience - all generalisations and IMHO > of course > > Time breakdown: 10% writing code, 10% maths and optimising, 80% tweaking > and tuning. > > Mapping the controls 1:1 with DSP parameters makes plugins crap - people > say they want that if you ask them, but they dont mean it ;) > > Fewer controls is better. > > Affordance, appearance and usability has as much affect on the perceived > sound quality as the DSP code (posivly and negativly). Some of this can > be achieved without a custom UI. > >You mentioned JAMin - true that does use LADSPA plugins - but of the total >ammount of code the LADSPA plugins are a tiny fraction. I just reused them >because I hate fixing bugs in two places :) > >[OOT] I used to think that a UI spec for LADSPA (to make it competetive >with VST) was a technological problem. I now thinks its a manpower issue >(I think Paul Davis pointed this out a couple of years ago :). Games >develpment has moved to the point where the graphics work is more >expensive than the software development, and I bet its not far off in >plugin / eyecandy app development. We have no, or almost no, graphics >people here. > >There are plenty of graphics people working on Free Software projects, but >they all seem to be working on games projects. What a waste. I guess >drawing goblins is more fun than sliders and LEDs. Who knew? ;) >

21 years, 7 months

[linux-audio-dev] Re: Graph reordering

by Juhana Sadeharju

>From: Alfons Adriaensen <fons.adriaensen(a)alcatel.be> > >On Fri, Jun 11, 2004 at 08:37:09AM -0400, Paul Davis wrote: > >> you cannot modify the graph in JACK while the graph is being used to >> process audio. you do not know how long the graph modification will >> take if you try to do it (for example) right after you're done with >> one process cycle. the only sure way to do this is to use lock free >> parallel programming techniques. Would anyone please explane details of these techniques? Maybe it is something I know already but it is not clear. >The 'heavy state' is AFAICS not the real problem. >Heavy things can be put in place before the actual graph reordering >is done or removed after. This does not need to be done in the RT >thread. For speeding up this approach one can also use caches for the items. The engine butler can initialize module structures, delay lines, etc. at its spare time. These initialized items are placed to cache. When the engine needs an initialized item, it gets the item instantly from the cache. (No patent pending.) Juhana

21 years, 7 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