Re: [LAD] RAUL or other libraries for real this time? ;-)
> Thanks Tim, I'll def check it out. What's the difference to a newbie like > myself between yours and the one in Jack? > > Congrats btw, that's awesome that your work will be in boost! the main difference is prbly that the jack ringbuffer is plain c and prbly needs libjack, while boost.lockfree is a c++ library and header-only. cheers, tim > On Thu, Nov 17, 2011 at 2:09 AM, Tim Blechmann wrote: > > > part I need library help with is likely synchronization and > > > interprocess/interthread communication. ( ie do I use the jack > > > > ringbuffer? > > > > > Do I look at boost queue implementations? does RAUL have a higher > > > level > > > convenience ring buffer? > > > > my boost.lockfree library has been accepted and will be shipped with > > future boost releases. it contains an mpmc-stack, an mpmc-queue and a > > wait-free spsc > > ringbuffer (same algorithm as the jack/kernel/supercollider ringbuffer). > > > > git repo: http://tim.klingt.org/git?p=boost_lockfree.git;a=summary > > (note that the addressing_reviews branch will be the one that will go > > into boost) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] RAUL or other libraries for real this time? ;-)
> part I need library help with is likely synchronization and > interprocess/interthread communication. ( ie do I use the jack ringbuffer? > Do I look at boost queue implementations? does RAUL have a higher level > convenience ring buffer? my boost.lockfree library has been accepted and will be shipped with future boost releases. it contains an mpmc-stack, an mpmc-queue and a wait-free spsc ringbuffer (same algorithm as the jack/kernel/supercollider ringbuffer). git repo: http://tim.klingt.org/git?p=boost_lockfree.git;a=summary (note that the addressing_reviews branch will be the one that will go into boost) cheers, tim ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] a *simple* ring buffer, comments pls?
>> no one can write a test case which fails when >> memory barriers are missing in a ringbuffer implementation. > > That's an interesting assertion. It's kind of tempting to write some > buggy circular buffers and test that assumption on common hardware. in fact, testing is not the best approach for verifying lock-free data structures: an implementation may work for years, if a certain condition is never triggered. the only reasonable way to ensure the correctness is a formal proof. unfortunately, most publications assume a sequencially consistent memory model and sometimes even avoid dealing with the ABA problem. fortunately the atomics of c++0x/c1x will make it much clearer (and more robust as the memory order argument to the atomic functions defaults to sequencial consistency) cheers, tim ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] a *simple* ring buffer, comments pls?
>> using preempt_rt, the scheduling latency can be very low (like 10 >> microseconds), if cpu frequency scaling is applied or smt/hyperthreading is >> enabled it can be as high as 250 microseconds (which is already quite >> significant, if one is using small signal vector sizes). > > That's interesting. We're actually benchmarking scheduling latency at the > moment. btw, i have discussed this briefly in my master thesis, section 4.1 [1]. the effect of the scheduling latency can also be observed in the benchmarks given in section 5. and it would be great, if you can share your results, i'd be curious to see them! cheers, tim [1] http://tim.klingt.org/publications/tim_blechmann_supernova.pdf ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] a *simple* ring buffer, comments pls?
>> OTOH, if you have a number of threads at the same priority >> as Jack's and doing audio work (e.g. to use all the CPUs of >> an SMP machine) then using locks between them (but no other >> threads) should be OK - depending a bit on how they are used. > > So, you can use locks as long as that's only meant to synchronize realtime > threads with each other? Should some master thread (could be the JACK process > thread) have a realtime priority slightly higher than the other (worker) > realtime threads? What are the caveats in general? yes and no: it is perfectly fine to use locks to use multiple real-time threads, but the thread A fails to acquire a lock, it will be suspended and woken up once thread B releases the lock. the time between `B releases the lock' and `A resumes its execution' is the scheduling latency, which is both os and hardware related. using preempt_rt, the scheduling latency can be very low (like 10 microseconds), if cpu frequency scaling is applied or smt/hyperthreading is enabled it can be as high as 250 microseconds (which is already quite significant, if one is using small signal vector sizes). however one can avoid the scheduling latency by using spinlocks if one can ensure that none of the synchronized threads can be preempted. personally i achieve this by (a) using real-time scheduling, (b) using not more real-time threads than physical cores and (c) pinning the rt threads to separate cores. tim ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] a *simple* ring buffer, comments pls?
>> and the NPTL code in glibc *seems* to perform a memory barrier only on >> sem_post(). > > Wouldn't that seem quite natural ? Semas provide one-way communication. > It's the sem_post() that means there is an event to be seen by some > other thread. So it has to make sure that any data related to it is > visible to the receiver. The receiver taking the event (returning > from sem_wait()), or checking for it (calling sem_wait()), is not > meant to be an event for the other side. You need a second sema if > events have to go both ways. from my understanding, sem_post() implies a write barrier (stores have been executed before sem_post()) and sem_wait() a read barrier (loads have to be executed after sem_wait()). tim ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] a *simple* ring buffer, comments pls?
> >> > the main problem is the lack of a memory model for multi-threaded > >> > applications at the level of the language (c or c++). fortunately this > >> > is about to change with c++0x and probably c1x. > >> > >> So in 10 years we will be able to rely on a conformant compiler being > >> available on all relevant platforms :) > > > > http://www.chaoticmind.net/~hcb/projects/boost.atomic/ > > if it all works ... very nice. > > but note that its only been tested on a couple of versions of gcc on a > couple of *nix-ish platforms. the number of supported compilers in the documentation is outdated. it supports the most commonly used compilers and multiple architectures. if a compiler is not supported natively, it uses a fallback implementation based on a pool of spinlocks, which of course is not lock-free, but c++0x doesn't guarantee lock-freedom either ... i've been using it for quite some time in boost.lockfree (in a slightly modified version). tim signature.asc Description: This is a digitally signed message part. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] a *simple* ring buffer, comments pls?
> > the main problem is the lack of a memory model for multi-threaded > > applications at the level of the language (c or c++). fortunately this > > is about to change with c++0x and probably c1x. > > So in 10 years we will be able to rely on a conformant compiler being > available on all relevant platforms :) http://www.chaoticmind.net/~hcb/projects/boost.atomic/ signature.asc Description: This is a digitally signed message part. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] a *simple* ring buffer, comments pls?
> Ah. pthread_mutex_lock() / unlock(), as EXTERNAL functions, will never > be optimized away or inlined. Now, being all sequence points, if you > simply do > > pthread_mutex_lock(); > xval = x; > pthread_mutex_unlock(); > > the compiler is not allowed to move statements out the locked section > or reorder them in any way (without need for any volatile qualifiers). the hardware would be allowed to reorder them ... this is the reason why mutex implementations involve memory barriers ... the main problem is the lack of a memory model for multi-threaded applications at the level of the language (c or c++). fortunately this is about to change with c++0x and probably c1x. tim ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] a *simple* ring buffer, comments pls?
>> > I thought a "lock-free" ring buffer was supposed to be >> > the easy solution! >> >> It is... when you re-use one that's already been written and >> debugged. ;-) >> >> Why not copy/paste the JACK ringbuffer (C) or even Ardours >> (C++ Container)? > > Here's another C++ one, for the record: > > http://svn.drobilla.net/lad/trunk/raul/raul/RingBuffer.hpp the linux kernel and supercollider have their own implementations of this algorithm as well ... iirc it is also described in the book `the art of multiprocessor programming' by maurice herlihy and nir shavit. and i would like to do some self-advertising: i have submitted some of my lock- free data structures to boost, and they will be reviewed in the end of july (18th-27th). source and docs are online [1, 2] and i'd like to invite everybody with an interest in lock-free programming to take part in the review. all the provided data structures (wait-free spsc ringbuffer, lock-free mpmc fifo and lock-free mpmc lifo) are potentially interesting for audio applications and i heavily use them for my multiprocessor-aware supercollider server ... the review itself will take place on the boost-dev mailinglist [3] cheers, tim [1] http://tim.klingt.org/boost_lockfree [2] http://tim.klingt.org/git?p=boost_lockfree.git;a=summary [3] http://www.boost.org/community/groups.html#main ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] [ann] nova-simd
hi all, for some time, i have been working on nova-simd, a cross-platform SIMD library library written in c++. it abstracts the platform-specific APIs and provides a `vec' class, which maps to a SIMD floating-point vector on the target machines and which can be used to formulate more complex algorithms. for some commonly used vector functionality, helper functions are provided, which are built using the vec class. features: - same interface for different SIMD architectures - supported backends: sse-family, avx, altivec, arm/neon - some backends include vectorized implementations of libm functions - extensively used in supercollider - header-only c++ (no runtime dependencies, composable), no dependencies canveats: - little documentations/examples - no release, no tarball, just a git repository [1] and a web interface [2] - header-only c++ (no c support) maybe it is useful for other people as well... cheers, tim [1] git://tim.klingt.org/nova-simd.git [2] http://tim.klingt.org/git?p=nova-simd.git;a=summary -- t...@klingt.org http://tim.klingt.org Art is either a complaint or do something else John Cage quoting Jasper Johns ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Basic Audio Mixing Subroutines
> Does anyone know of (or is there interest in creating) a > library of basic, low-level, audio mixing subroutines? This > would be analag to the BLAS[1], but for audio. > > What I'm thinking is something like Ardour's SSE-optimized > mixing subroutines... and updating it for later > optimizations (SSE2, SSE3, ...). i've got some c++ headers, that provide simd-fied simple mixing functions, but also some other vectorized functions, sse-based libm functions and so on ... it is based on a generic vec class, that can simply be reimplemented for different types/architectures, but for now only suports float/sseX tim [1] http://tim.klingt.org/git?p=nova-simd.git;a=summary -- t...@klingt.org http://tim.klingt.org Music is the can opener of the soul. It makes you terribly quiet inside, makes you aware that there's a roof to your being. Henry Miller ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] any improvement on S3 suspend-resuming driver snd-hdsp ?
>> Is there any improvement in recent driver iterations ? I would really >> like to be able to suspend / resume my PC sometimes. > > Add a rmmod/modprobe to your suspend/resume scripts. ... this won't work if the hdsp is used by any application, or am i missing something? cheers, tim -- t...@klingt.org http://tim.klingt.org You don't have to call it music if the term shocks you. John Cage ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] gcc and pointer aliasing... missing optimizations in some cases
>>> Thus telling the compiler that `this` is not an alias when >>> process() is called. >> >> On second thought... since those didn't work for me, perhaps part of >> the problem is that osc_block is a global variable, and thus there's >> no way to prove __restrict__ on it. >> >> -gabriel > > fields of structs are not unaliased, even when the pointer to the struct > is __restrict__ did you check http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14187? tim -- t...@klingt.org http://tim.klingt.org You can play a shoestring if you're sincere John Coltrane ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Atomic Operations
> +#if defined(__APPLE__) > +#include > +#define MEMORY_BARRIER() OSMemoryBarrier() > +#elif (__GNUC__ > 4) || (__GNUC__ == 4 && __GNUC_MINOR__ >= 1) > +#define MEMORY_BARRIER() __sync_synchronize() > +#else > +#warning SMP Danger: memory barriers are not supported on this system > +#endif there was a buggy gcc version, that didn't implement __sync_synchronize() correctly on x86, causing errors on nehalem machines (which don't have a shared cache). if sse is enabled, _mm_mfence() can be used to work around this compiler bug ... tim -- t...@klingt.org http://tim.klingt.org /"\ ASCII Ribbon Campaign \ / no HTML in email & vCards X no proprietary attachments / \ use open standards signature.asc Description: OpenPGP digital signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Atomic Operations
> this was discussed at some considerable length on jack-devel last > year, IIRC. > for single reader/single writer ringbuffers, i believe that we > concluded that memory barriers are not necessary. No, to me the conclusion was: we can't programmatically prove that memory barriers are needed (even on the most vulnerable architectures), but the theory say that they are, and they should be added for correctness. >>> My understanding matches Olivier's. Intel processors have strong memory >>> ordering, and so on them the jack ringbuffer is safe without memory >>> barriers. However, some PPC processors, and SPARC V9s under linux >>> (but not >>> Solaris), use weak memory ordering, and on them, the jack ringbuffer >>> code >>> can theoretically fail. >> >> exactly, the issue may not appear on x86, because of its memory >> consistency, weakly-ordered machines will need some barriers ... > > The point is, I wrote ringbuffer stress tests, and someone reported on this > list > that they succeeded on a weakly-ordered (PowerPC SMP) system, even without > memory barriers. Anyway... unfortunately stress tests won't necessarily show the race condition >>> See the "ring buffer memory barriers" discussion on jack-devel back in >>> October of last year for more information; in particular, this article >>> by Paul E. McKenney is very helpful: >>> >>> http://www.linuxjournal.com/article/8211 >> >> memory-barriers.txt of the linux kernel documentation is interesting as >> well ... > > The portaudio ringbuffer is also a good source of inspiration I think: > http://portaudio.com/trac/browser/portaudio/trunk/src/common/pa_ringbuffer.c > > In short, they use memory barriers at only three places, especially: > > - "to ensure that previous writes are seen before we update the write index" > - "to ensure that previous writes are always seen before updating the (read) > index." the kfifo doesn't look too different, either ... tim [1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=kernel/kfifo.c;hb=HEAD -- t...@klingt.org http://tim.klingt.org You can play a shoestring if you're sincere John Coltrane signature.asc Description: OpenPGP digital signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Atomic Operations
>> Actually, his implementation is similar to ringbuffer.c in >> libjack... and assumes that reading and writing can happen >> atomically (as was pointed out by someone else) -- which can >> be managed with single reader / single writer >> requirement.[a] >> Unless I've misunderstood the code, ringbuffer.c is /not/ >> using special atomic operations. > > Why should a single-reader-single-writer ring-buffer need atomic operations? > > The reader increments the read-pointer (which doesn't have to be a pointer) > last when its finished, how do you ensure, that the read pointer is incremented _after_ the data has been written to the output? > the writer increments the write-pointer last when it > has written. likewise, how do you ensure, that the write pointer is incremented _after_ the data has been written to the ringbuffer? also, when reading the read/write pointers, you need to ensure, that they are loaded, before you touch the ringbuffer. > All other access is read-only. No problems. (At least in my app.) your code may work on x86, not necessarily on ppc, ia64 ... and then there is alpha ... we are not in a world, where assembler instructions are executed one after the other, but we have out-of-order cpus with speculation and multi-processor systems with non-shared caches ... hth, tim -- t...@klingt.org http://tim.klingt.org Which is more musical, a truck passing by a factory or a truck passing by a music school? John Cage signature.asc Description: OpenPGP digital signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Atomic Operations
>>> this was discussed at some considerable length on jack-devel last >>> year, IIRC. >>> for single reader/single writer ringbuffers, i believe that we >>> concluded that memory barriers are not necessary. >> >> No, to me the conclusion was: we can't programmatically prove that >> memory >> barriers are needed (even on the most vulnerable architectures), >> but the theory >> say that they are, and they should be added for correctness. > > My understanding matches Olivier's. Intel processors have strong memory > ordering, and so on them the jack ringbuffer is safe without memory > barriers. However, some PPC processors, and SPARC V9s under linux > (but not > Solaris), use weak memory ordering, and on them, the jack ringbuffer > code > can theoretically fail. exactly, the issue may not appear on x86, because of its memory consistency, weakly-ordered machines will need some barriers ... > See the "ring buffer memory barriers" discussion on jack-devel back in > October of last year for more information; in particular, this article > by Paul E. McKenney is very helpful: > > http://www.linuxjournal.com/article/8211 memory-barriers.txt of the linux kernel documentation is interesting as well ... cheers, tim -- t...@klingt.org http://tim.klingt.org Contrary to general belief, an artist is never ahead of his time but most people are far behind theirs. Edgar Varèse signature.asc Description: OpenPGP digital signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Atomic Operations
>>> http://github.com/radarsat1/dimple/blob/master/src/CircBuffer.h >> >> you should add memory barriers, when reading or writing to the reader or > > Actually, his implementation is similar to ringbuffer.c in > libjack... and assumes that reading and writing can happen > atomically (as was pointed out by someone else) -- which can > be managed with single reader / single writer > requirement.[a] > > Unless I've misunderstood the code, ringbuffer.c is /not/ > using special atomic operations. the jack ringbuffer code is not multiprocessor safe then ... it is prbly not an issue for jack1, but maybe for jack2, if it is used there ... >> writer indices ... my implementation (without size limitation to a power >> of two) can be found at [1] >> >> [1] >> http://tim.klingt.org/git?p=boost_lockfree.git;a=blob;f=boost/lockfree/ringbuffer.hpp;h=139f79869f610c61b0d117d2836a3c8c4949db02;hb=03d4e397a74f2b85c87f6b54b4755428956ff63a > > This looks nice, too. Have you considered trying to give it > an interface like the existing boost::circular_buffer? > The distinguishing feature of your implementation is that is > lock-free... but it's otherwise the same concept (and > already in Boost). i actually tried to match the interface to boost::lockfree::fifo, which provides a multi-producer/multi-consumer queue. > Also, does yours have a single reader / single writer > requirement? yes > I tried to clone the git repos, but hit ^C when it was > 20% and 40MB (!!). :-) it includes the full source tree of boost (160mb on my machine) cheers, tim -- t...@klingt.org http://tim.klingt.org Happiness is a byproduct of function, purpose, and conflict; those who seek happiness for itself seek victory without war. William S. Burroughs signature.asc Description: OpenPGP digital signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Atomic Operations
> For one of my projects I once ported the kfifo implementation in the > Linux kernel to a C++ class. Feel free to use it if you'd find it > useful. (GPL) > > http://github.com/radarsat1/dimple/blob/master/src/CircBuffer.h you should add memory barriers, when reading or writing to the reader or writer indices ... my implementation (without size limitation to a power of two) can be found at [1] hth, tim [1] http://tim.klingt.org/git?p=boost_lockfree.git;a=blob;f=boost/lockfree/ringbuffer.hpp;h=139f79869f610c61b0d117d2836a3c8c4949db02;hb=03d4e397a74f2b85c87f6b54b4755428956ff63a -- t...@klingt.org http://tim.klingt.org art is short - life is long Jack Kerouac signature.asc Description: OpenPGP digital signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Atomic Operations
On 12/15/2009 02:58 PM, Paul Davis wrote: > On Tue, Dec 15, 2009 at 8:54 AM, Paul Davis > wrote: >> these concepts have been around in this community (and others) for >> years. i suspect that it is more than a decade since the folks at >> GRAME published their paper on lock free data structures (used in >> MidiShare), and its probably a decade or more since LAD first >> discussed lock free (single-read/single-writer) ringbuffers. there's >> nothing wrong with having new eyes and new ideas but i couldn't see >> anything from a casual glance in that paper that hasn't been >> documented and used by people on this list for a long time. > > i should perhaps note that there tends to be less use of generic lock > free data structures because of the absence of nice libraries. maybe > effo can be a useful addition there. its not as if its the first one, > however. fyi, i am working on boost-style c++ implementations of some lockfree data structures ... the library is on the boost review queue, however counting the number of libs in the queue and review processes per year, it may take some time, until it is an official part of boost .. http://tim.klingt.org/git?p=boost_lockfree.git http://tim.klingt.org/boost_lockfree/ suggestions/thoughts/criticism is welcome ... tim -- t...@klingt.org http://tim.klingt.org I had nothing to offer anybody except my own confusion Jack Kerouac signature.asc Description: OpenPGP digital signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Atomic Operations
> + At the moment, there is no built-in support in >C/C++ for atomic operations. You will need to use >a library, compiler extension, or write your own >in assembly code. c++0x will contain support for atomic operations, a boost-style library, implementing the upcoming std::atomic template is currently being worked on: http://git.chaoticmind.net/cgi-bin/cgit.cgi/boost.atomic/ hth, tim -- t...@klingt.org http://tim.klingt.org After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs signature.asc Description: OpenPGP digital signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] kernel 2.6.29 rc6 no working rme multiface 1
hi dmitry and michael, i was experiencing a similar issue myself ... > 2.6.24 works, 2.6.28 doesn't (tried 2.6.8-ARCH and 2.6.28.7-1-ARCH). > I reported the problem to alsa-devel list, but they said I have hw > problems (I think I do not). could you try the patch i posted a few days ago on alsa-devel? it solved the issue for me ... http://article.gmane.org/gmane.linux.alsa.devel/60411 it would be very odd, if several people experience the same hardware problem starting with recent kernel versions :) best, tim -- t...@klingt.org http://tim.klingt.org Desperation is the raw material of drastic change. Only those who can leave behind everything they have ever believed in can hope to escape. William S. Burroughs signature.asc Description: OpenPGP digital signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Regarding the linux-audio lists announcing policy
>> Now regarding the fact that not everyone knows they should post on the >> 3 lists, I don't really think that's the case. most announces I see are >> posted at least on 2 lists. LAA is nearly always one of them. Some >> people choose to add LAD and LAU, some choose to add also their project >> list. >> > I just ran the script again: as of July 8 2008 there are 1760 unique > subscribers @linuxaudio.org's 4 lists (laa,lau,lad,consortium). The > majority of users is subscribed to ONE list only. being subscribed to a list and reading a list are two different things ... some people (including me) are reading the lists via gmane ... besides ... if it is made clear that announcements are sent to the laa- list only, people, who are interested in announcements can subscribe there ... no need to force people to read mails several times, or even read mails one is not interested in (if someone doesn't care about announcements) imho, double/triple-posting should be considered as `bad style' and should be avoided ... best, tim -- [EMAIL PROTECTED] http://tim.klingt.org After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: A common plugin repository (WAS:Re: [LAD] ladspa qa?)
On Thu, 2007-09-06 at 11:27 +0200, N. Gey wrote: > Georg Holzmann schrieb: > > yep. maybe the gstreamer way is a possible solutions, or something > > similar. they have three categories: good, bad and ugly (which are > > also different packages): > > > > ---8< > > gst-plugins-good: a set of good-quality plug-ins under our preferred > > license, LGPL > > gst-plugins-ugly: a set of good-quality plug-ins that might pose > > distribution problems > > gst-plugins-bad: a set of plug-ins that need more quality > > 8< > > (http://gstreamer.freedesktop.org/modules/) > > SVN is one (good) thing, but pre-packaging is very bad. Who will decide > whats good and whats not? There is no indipendent way for all styles of > music. Whats good for electro is bad for classical and so on. So > prefiltering is not the right way. Reviewing afterwards regarding to > cases of use is a more fair system. well, there are some points, that can be used to judge the quality of plugins. if a filter is unstable, it is neither good for electro nor for classical, as you don't hear anything from NANs. tim -- [EMAIL PROTECTED]ICQ: 96771783 http://tim.klingt.org Avoid the world, it's just a lot of dust and drag and means nothing in the end. Jack Kerouac signature.asc Description: This is a digitally signed message part ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev
Re: A common plugin repository (WAS:Re: [LAD] ladspa qa?)
> > I don't think it's a particularly great idea myself, it makes it > > harder for package maintainers to track plugins if they move from one > > package to another. If they stay in both then that's also tricky. > > I assume you're imagining that the plugins would be copied to the common > repositories as-is; please correct me if I'm wrong. > > In my mind this new codebase, although built upon existing code, would be > like > any other new plugin collection with new, individual names and everything > else that goes with it. Many of the existing plugin collections would become > abandoned by necessity, as work would be focused towards a common project, > but none of the new plugins would conflict with the old ones. So package > managers (myself included) wouldn't really have to worry. > > Some older plugin sets would of course become redundant as the new common > collection would initially introduce much of the same stuff in new clothes. > But I want to stress the word _initially_ here, because from there on the > efforts would be much better concentrated than before. well, it is mainly a packaging problem ... however, i don't really like the idea of starting a new codebase, mainly because of the development overhead ... but there should be a way for people to find out, which plugins are high quality plugins and which are low quality ... imho it is somehow insane, that ubuntustudio-audio-plugins, which provides ladspa plugins for ubuntu studio (a distribution that should work out of the box) depends on vcf-plugins, which is an unmaintained collection of filters, that will most probably blow your speakers, when you try to change the parameters ... if developers could mark unmaintained plugins as deprecated (to keep backwards compatibility) and would try to convince distributors to ship only plugin packages, which match a certain quality, the overall quality of linux audio plugins would probably increase ... cheers, tim -- [EMAIL PROTECTED]ICQ: 96771783 http://tim.klingt.org The price an artist pays for doing what he wants is that he has to do it. William S. Burroughs signature.asc Description: This is a digitally signed message part ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev
Re: [LAD] ladspa qa?
> > have there been some thoughts of introducing some kind of ladspa qa? > > Not that I know of, but it's a brilliant idea. > > I've been meaning to setup some kind of wiki based thing where users > can share problems/experiences, but just never had the time. a wiki is probably a good starting point ... this may also lead to less duplicate plugins if people collaborate ... like, there is not really the need for 5 different lowpass filters, especially, if only 2 implementations are stable ... :/ cheers, tim -- [EMAIL PROTECTED]ICQ: 96771783 http://tim.klingt.org Question: Then what is the purpose of this "experimental" music? Answer: No purposes. Sounds. John Cage signature.asc Description: This is a digitally signed message part ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev
[LAD] ladspa qa?
hi all, i'm not really familiar with the ladspa development process, but is there any quality assurance for ladspa plugins? i have been implementing some of my filters as ladspa plugins, but when trying to compare them with others, i found, that some of the plugins did not do, what i expected them to do (a white noise generator did not generate white noise, a shelf filter was highly unstable when changing parameters) ... of course, all plugins are free (as in speech), without any warranty, but i still think, that there should be a certain amount of quality assurance, if we want people to use the ladspa plugins ... have there been some thoughts of introducing some kind of ladspa qa? best, tim -- [EMAIL PROTECTED]ICQ: 96771783 http://tim.klingt.org Desperation is the raw material of drastic change. Only those who can leave behind everything they have ever believed in can hope to escape. William S. Burroughs signature.asc Description: This is a digitally signed message part ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev
Re: [LAD] Ardour session archiver (Was: new lossless/lossy audio compressor)
On Tue, 2007-07-31 at 16:37 -0400, Paul Winkler wrote: > On Tue, Jul 31, 2007 at 10:25:34PM +0200, Marc-Olivier Barre wrote: > > I been thinking of the same thing... can't ardour handle FLAC files > > natively ? > > Nope. well, it is possible to manually convert the session audio data to flac and change the filenames in the session files ... this works fine as long as libsndfile supports flac ... i'm usually doing this hack in order to avoid hard disc space when archiving recordings ... i'd like to see a proper 'native' support in ardour, though ... tim -- [EMAIL PROTECTED]ICQ: 96771783 http://tim.klingt.org Linux is like a wigwam: no windows, no gates, apache inside, stable. signature.asc Description: This is a digitally signed message part ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev
Re: [LAD] [ANN] pyliblo 0.5
> For example, liblo (and thus pyliblo) takes care of things like finding a > free port, matching argument types, type coercion, or running the OSC > server in its own thread, so that the main thread can continue doing GUI > stuff or something. > With pyliblo, all this requires very little effort from the programmer. > And IMHO it has a cleaner and more pythonic API than any of the > alternatives :) i see, thanks for the insights ... tim -- [EMAIL PROTECTED]ICQ: 96771783 http://tim.klingt.org Desperation is the raw material of drastic change. Only those who can leave behind everything they have ever believed in can hope to escape. William S. Burroughs signature.asc Description: This is a digitally signed message part ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev
Re: [LAD] [ANN] pyliblo 0.5
hi dominic On Thu, 2007-04-26 at 15:17 +0200, Dominic Sacré wrote: > pyliblo is a Python wrapper for the liblo OSC library. It does not yet > wrap all of liblo's functionality, but includes everything you need to > send and receive almost any kind of OSC message, using a nice and simple > Python API. OSC can hardly get any easier :) i'm curious, what's the advantage of pyliblo over these native python implementations of osc? http://space.k-hornz.de/space/uploads/OSC.py http://www.ixi-software.net/content/body_backyard_osc.html best, tim -- [EMAIL PROTECTED]ICQ: 96771783 http://tim.klingt.org Desperation is the raw material of drastic change. Only those who can leave behind everything they have ever believed in can hope to escape. William S. Burroughs signature.asc Description: This is a digitally signed message part ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev
