Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

3 participants
7440 discussions

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

by Juhana Sadeharju

>From: Tim Hockin <thockin(a)hockin.org> > >> Quick question: disk thread may suspend if there are no disk use. >> How the disk thread is woken up to read the lock-free buffer? > >Semaphore. Every time you put something into the buffer, up() the So, one thread for RT-audio, one thread to watch and suspend on semaphores, and one thread to select() on FDs (for communication from the application and from the semaphore watcher). Which one is better? (1) RT-audio thread ---> pipe ---> select() thread (2) RT-audio thread ---> semaphore --> semaphore watcher thread --> pipe --> select() thread Of course, better for RT-audio thread. While the case (2) is more complex, it could be better for RT-audio thread. How this all is done in Ardour? I browsed the source but there are a lot of stuff there. How about LinuxSampler? Juhana

20 years, 3 months

[linux-audio-dev] [ANN] Specimen 0.4.0 "Smooth"

by Pete Bessman

Specimen is a MIDI controllable SoftSampler for GNU/Linux systems. Features added since 0.3.0 include: * Portamento * Per-parameter LFOs with delay and attack * LFOs may be "global" (voice independent) or per-voice * LFOs may be constrained to oscillate between 0 and 1 instead of -1 and 1 * ADSRs have gained delay and hold phases * Most parameters can be velocity sensitive to a user-specified degree * LFO/ADSR amounts for pitch are now entered in half-steps * A sample's pitch may be adjusted within a user-definable range You can download the latest tarball (some assembly requried) from www.gazuga.net, or directly below: http://www.gazuga.net/files/specimen-0.4.0.tar.gz The focus of the 0.4.x series is the GUI, so if you've got a gripe or a wish about that, now's the time to pipe up. As always, my inbox is wide open to suggestions and bug reports. -Pete

20 years, 3 months

[linux-audio-dev] pitch-shift library

by Florin Andrei

Anyone knows a library (or an algorithm or something) for CPU efficient pitch-shifting? Essentially, i want to take arbitrary audio input and pitch shift it just a little bit, indeed very little - the shift should be so small as it would not even qualify as out-of-tune for most practical purposes (provided that the original sound is perfectly in-tune). A shift not bigger than the usual tuning error of ordinary unplugged instruments. I also need to vary the shift, not too fast (the pitch shifting modulator will change the shift up and down a couple times per second or less), but still change it dynamically. The algorythm should be efficient enough to allow real-time processing of at least 16 sound channels simultaneously, and still leave some CPU power untouched. All this should be incorporated into a LADSPA plugin that i plan to build (and it's only a part of the functionality). -- Florin Andrei http://florin.myip.org/

20 years, 3 months

[linux-audio-dev] [ANN] New releases of Aeolus and Jaaa

by Fons Adriaensen

New releases of Aeolus and Jaaa are now available at <http://users.skynet.be/solaris/linuxaudio> Aeolus-0.2.0 ------------ - bugfixes, - some new stops, - added tuning and temperament controls, - added controls for tremulant speed and intensity. Still no manual :-( but it's coming... This will be a stable release for some time. The next major step is to add the 'chiff' generators, and this will require a lot a research and work. First step is to make recordings of real pipes and analyse them to find the noise spectra. I'll probably be making recordings of the Metzler organ in the Antwerp cathedral during the coming months. Then it's back to the drawing board. The target is to make this work for LADconf 3... Jaaa-0.1.0 ---------- Some bugfixes, no new features. Adapted to the new shared libs, see below. There's a minimal manual in the README. Shared libraries ---------------- libalsadrv.so used by earlier releases is replaced by clalsadrv-0.0.1, libclthreads and libclxclient have been are upgraded to 0.0.2. Please delete all earlier versions of these libs, they are now useless. The so-names are now correct, and Aeolus and Jaaa will link with the *.so.0 files. I had this completely wrong in the first release (thanks to Fernando for complaining about this :-). -- Fons

20 years, 3 months

[linux-audio-dev] [ANN] BLOP LADSPA Plugins 0.2.8

by Mike Rawes

Hi After way too long, a new release of the BLOP LADSPA Plugin set. Orginally named Bandlimited LADSPA Oscillator Plugins, but there's more than oscillators... they're more useful in a modular host, such as Spiral Synth Modular, gAlan, Alsa Modular Synth etc. Plugins in the set: New since last release: * Quantiser (quantise to arbitrary values in a range) * Signal Tracker (envelope follower, sample+hold, track+hold, ...) * DAHDSR envelope generator * Difference and Ratio utility plugins Existing ones, with less bugs I hope: * Bandlimited DCOs (wavetable based): - Sawtooth - Square - Pulse with variable width - Triangle with variable slope (Saw->Triangle) * Analogue-style step sequencer * Fast'n'Dirty Moog 4 Pole implementation * Two ADSR envelope generators * Random wave generator * A mono amplifier * Non-bandlimited square and pulse clock oscillators * 1V / Octave CV to Frequency converter * Control rate to Audio rate interpolator * Sum and Product utility plugins Some plugins come in control and audio rate variations. RDF metadata is also included if your host supports it. All plugins pass the demolition test: http://www.ecs.soton.ac.uk/~njl98r/code/ladspa/demolition.html Website: http://blop.sourceforge.net - Myk

20 years, 3 months

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

by Juhana Sadeharju

>From: Joshua Haberman <joshua(a)reverberate.org> > >Also, I have a strategy in mind for gracefully degrading when the GUI >thread can't pull data from the FIFO fast enough (again, for VU meters One could use plain variables for the VU values. Engine updates them. And GUI reads them. GUI may not get all values, but the most important temporary max level changes so slowly that GUI does not skip on that. Another choise is to resample the VU signals to low enough rate in the engine. If 30 frames per second is the display refresh rate, then using rate 20 Hz for VU signals allows GUI to catch up if VU freezes. >that the loads and stores are observed in the required order, you have >to use memory barriers (again, in theory). See: > >http://en.wikipedia.org/wiki/Memory_barrier What it means practically? Any code? (Cannot check wikipedia now.) One could write some ID numbers to the buffer next to the buffer pointers. If the ID number is not what it should, then the problem has been recognized. What to do in this situation? If it is a non-realtime thread (disk thread), the disk thread could idle a bit or do something else. But if it is the realtime audio thread, then what? Any this kind of trickery could be slower than any memory barriers, guess. Quick question: disk thread may suspend if there are no disk use. How the disk thread is woken up to read the lock-free buffer? Are the following yes or no? (1) audio thread sends SIGCONT signal to disk thread, (2) audio thread sends sys/msg.h message to disk thread, (3) audio thread sends one byte via a pipe to disk thread, (4) disk thread uses timer to wake up itself. Something else? Audio thread sends the wake up relatively rarely. So, if pipe has a small buffer, then pipe could be practically lock-free. How it is? Juhana

20 years, 3 months

[linux-audio-dev] Knobs, the reply

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

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

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

20 years, 3 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/

20 years, 3 months

Jump to page:

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