Hm. Haven't i already replied to this? I thought so, but the mail is not in my Sent folder, so nevermind, if you already have a reply ;)
Am 31.01.2014 01:34, schrieb Tim E. Real: > On January 27, 2014 01:05:55 AM Florian Jung wrote: >> All data, (also MIDI data), is read from the prefetch thread and written >> into ringbuffers, to be read and played by the audio thread. the audio >> thread does effects etc. > > snip > >> Also, time-stretching is done inside the audio thread, and not inside >> the prefetching thread, to be able to quickly adapt new tempi (-> >> external synchronisation). The prefetcher must prefetch an appropriate >> number of samples, obviously. (We may assume that the external tempo >> does not deviate by more than 10% from the tempo map). > > Yes I figure the ring buffers should store individual samples rather > than blocks, so that we can pull as many or little samples as the > stretcher needs, from the process thread. > Reviewing our prefetch system: > > In WaveTrack::getData(), which is called in the process thread, it calls > _prefetchFifo.get(). > > Not quite sure yet but I think it already allows us to pull an arbitrary > number samples rather than blocks. > Which is good. indeed :) > > ** Now here's a really IRONIC thing I just found out: > > Take a look at our Fifo class (node.h, cpp) which is the class used for > _prefetchFifo. You see a lot of pthread_mutex_lock etc. > > These locks were only supposed to be compiled if *NOT* running an > i386 arch, otherwise it is supposed to use NO locks at all on an i386 arch. > > (I guess that answers my question about built-in atomic operations > on i386 Linux ? Good !) > > However, the macro i386 is old I believe, and is NOT defined here. > I could swear at one time long ago it was. > I believe it was replaced with __i386__ which IS defined here, and > __i386__ IS used elsewhere in MusE. > > So... Here we are worrying about using locks... and ironically locks > *are* already being used here, with no noticeable problems, > inside one of the most critical sections of our process callback... Please don't take this as an excuse for sloppiness. If we want to create a live-capable application, we have to do it properly. If we want to create a studio-only application which might trash the one or other recording, then fine. (I'd probably be okay with that one, too) > > What are you guys seeing on your machines? Are those sections > compiled in or not? Not compiled in, but irrelevant because i have insanely high buffer sizes usually. Cheers, flo > > Thanks. > Tim. > > ------------------------------------------------------------------------------ > WatchGuard Dimension instantly turns raw network data into actionable > security intelligence. It gives you real-time visual feedback on key > security issues and trends. Skip the complicated setup - simply import > a virtual appliance and go from zero to informed in seconds. > http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk > _______________________________________________ > Lmuse-developer mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/lmuse-developer >
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ WatchGuard Dimension instantly turns raw network data into actionable security intelligence. It gives you real-time visual feedback on key security issues and trends. Skip the complicated setup - simply import a virtual appliance and go from zero to informed in seconds. http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
_______________________________________________ Lmuse-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lmuse-developer
