On 07/30/2014 02:47 AM, Stian Jørgensrud wrote: > You currently know best how the code and performance of LMMS can be improved, > Vesa, therefore I support you. I too think it will be crucial for LMMS and > make it better, but I can't understand why, other than that it will be RT > safe. Could you try to explain to us non-coders even more why this is so > much better than the old one? If you throw in some comparisons and metaphors > it might brighten our minds.
I can try. Paul could probably explain it better than me though... Basically, the engine is like the heart of LMMS. It consists of the core rendering function which is executed in a loop, once every period. The rendering function, or the engine, handles advancing the song (actually that's a separate function but I'm trying to keep this simple), playing all the notes, rendering the output of instruments, processing all effects, writing the output of instruments+effects to the mixer, then processing the mixer channels (and their effect chains) until we get to the final mixdown which is then output to the soundcard/file by the audio backend. So, roughly speaking, LMMS consists of 3 parts: 1) GUI 2) engine/core 3) backend(s) Now the thing about the engine is, that it's kind of in the middle of everything, taking user input from the GUI, and outputing audio to the backend. Meanwhile it has to render all the sound and do all these other things, and it needs to allow the GUI to modify the song and the instruments/effects while playing, and since we have multiple threads working in all this, this can cause race conditions (eg. thread A writes to object X while thread B is reading it, or thread A destroying object X while thread B is calling a function with object X as a parameter). To prevent race conditions, we need to ensure thread safety. The easiest ways of ensuring thread-safety is using locks. This means that when thread A wants to modify object X, it sets a lock on it that makes thread B unable to modify it until thread A is finished. Unfortunately, this also means that thread B is stuck waiting while thread A works. You can think of these locks as sort of "traffic lights" - they ensure cars (threads) don't cross the intersection at the same time and prevent crashes, but at the same time they can cause massive traffic jams... Our core rendering function has a global lock which is called in approximately 20 places all over the codebase (and that's in the master branch where I just removed a whole bunch of these global lock calls, so 1.1 and 1.0 have even more of them). So why is this a problem? Well, the way I understand it (and I'm not 100% on all the details here) this use of global locks causes the core rendering function to often be stuck waiting in the "traffic lights", which causes it to miss deadlines, meaning that it can't reliably give the audio output to the backend. This means, among other things, that it's pretty much impossible to get the Jack backend to function reliably and correctly, with reasonable latencies. From what I understand, the design of Jack is such that it requires RT-safe code in the audio backends in order to operate properly. It also means flaky live performance, CPU spikes, etc. It means that implementing some functionality is going to be hard/impossible, especially functionality that depends on timing and speed, and it means we have more CPU overhead which also limits the functionality we can implement while still keeping LMMS usable, which means it directly limits how much we can improve LMMS. There's also potentially other stuff in the current engine - and our overall architecture - which can cause problems. The handling of notes might have to be revised - allegedly it's not good to allocate NotePlayHandles dynamically as they are played, although I'm not sure why this is exactly (something to do with memory allocations I guess?). There's even more stuff, but I think I've written enough in one email... > Vesa, it will be you who must instruct the hired dev, the most. You have > time and will? I don't want to loose the best dev for LMMS, but I guess you > would have to concentrate 100% on helping the new dev for a month or so. And > perhaps the most important question, as Tres also asked: Where do you find > the developer? Well, like I've said before, I will be starting school next month which will somewhat limit the time I'll have for coding, however... I think I can safely say I would be available to instruct on the codebase, to the best of my abilities - I can't be on call 24/7 but I think I could manage daily conversations and consultations. As for where to find the developer, that's a trickier question which I don't really have the answer to yet, and one that should probably be figured out before starting the campaign... > You were mentioning JACK support as one very important enhancement? Do you > think that is less coding and would be a nice first goal to pledge money > for? No, see above - (proper, reliable) Jack support is pretty much impossible without a RT-safe engine. As far as I can tell, there isn't actually anything wrong with our Jack backend itself - it's just that the engine can't keep up with it. Fix the engine, then the Jack backend gets pretty much fixed on the side, "for free". This opens up other possibilities: being able to route outputs and inputs via Jack to any part in the chain in LMMS... think if you have an effect that's only available as a standalone Jack app - wouldn't it be cool to just be able to connect it into an LMMS effect chain like it was a plugin? Or maybe you'd like things like Jack transport support - being able to use programs like Ardour and synchronize it with LMMS? These are all things that would be possible with a RT-safe engine. > And at last, I want to brighten up the future of LMMS with this: As I know, > the program has inspired no less than three boys to begin study computer > science, one of them is me, the other guys I were thinking about are at the > same age. In a few years we might be able to contribute code to LMMS. We > want to already :-) Sounds great, then we at least have a backup plan in a few years if all other plans fail ;) ------------------------------------------------------------------------------ Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk _______________________________________________ LMMS-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lmms-devel
