Linux Audio Programmers: LMMS needs your help

Programming applications for making music on Linux.

Moderators: MattKingUSA, khz

diizy
Established Member
Posts: 105
Joined: Tue Feb 04, 2014 2:48 am

Re: Linux Audio Programmers: LMMS needs your help

Post by diizy »

Actually, Qt's atomic pointers don't seem very suitable for this task, so I'm instead going to try to just use a local mutex in the MIDI event processing function, so that the global mixer mutex doesn't have to be touched.
diizy
Established Member
Posts: 105
Joined: Tue Feb 04, 2014 2:48 am

Re: Linux Audio Programmers: LMMS needs your help

Post by diizy »

Ok, the crashing with chained MIDI was actually unrelated and a separate bug, so now I've been able to eliminate some global mutex locks from LMMS. It seems there are a few that are simply pointlessly locked, or maybe as a precaution of some sort, where removing the locks doesn't seem to make any difference...
diizy
Established Member
Posts: 105
Joined: Tue Feb 04, 2014 2:48 am

Re: Linux Audio Programmers: LMMS needs your help

Post by diizy »

Hypothetically, if we were able to pay for X work hours to a developer to work on improving the core engine of LMMS... would anyone be interested in such a project?
fundamental
Established Member
Posts: 165
Joined: Thu Nov 07, 2013 1:19 pm
Been thanked: 1 time

Re: Linux Audio Programmers: LMMS needs your help

Post by fundamental »

diizy wrote:Hypothetically, if we were able to pay for X work hours to a developer to work on improving the core engine of LMMS... would anyone be interested in such a project?
I'd image that if a reasonable pay/hours was setup there are people out there who would work as a consultant for the project.
ZynAddSubFX maintainer
diizy
Established Member
Posts: 105
Joined: Tue Feb 04, 2014 2:48 am

Re: Linux Audio Programmers: LMMS needs your help

Post by diizy »

fundamental wrote:
diizy wrote:Hypothetically, if we were able to pay for X work hours to a developer to work on improving the core engine of LMMS... would anyone be interested in such a project?
I'd image that if a reasonable pay/hours was setup there are people out there who would work as a consultant for the project.
We'd need a bit more than consulting... it'd have to be someone who's well-versed in RT-audio, DSP- and systems coding. We have a halfway-finished engine developed by Paul Giblock which could be used as basis for the work. The job would involve developing the new audio engine in an RT-safe way, then integrating that into the current LMMS codebase.

This is, again, all just hypothetical at this point. We're looking at options for possibly raising funds for an endeavour such as this (possibly with a crowdfunding campaign). So I wanted to gauge if there's anyone who'd be interested in such work.
diizy
Established Member
Posts: 105
Joined: Tue Feb 04, 2014 2:48 am

Re: Linux Audio Programmers: LMMS needs your help

Post by diizy »

Latest developments in the LMMS saga:

I'm currently working on a memory manager for LMMS, which should somewhat improve RT-safety by cutting down heap allocations. It's still a long way to go to make LMMS RT-safe, but it's a step forward.


On another note: FalkTX, what's the status on the LMMS/Carla plugin? Are you still working on it? I'd love to see it in LMMS 1.2...
diizy
Established Member
Posts: 105
Joined: Tue Feb 04, 2014 2:48 am

Re: Linux Audio Programmers: LMMS needs your help

Post by diizy »

falkTX wrote:
diizy wrote:On another note: FalkTX, what's the status on the LMMS/Carla plugin? Are you still working on it? I'd love to see it in LMMS 1.2...
How is 1.1 coming? :wink:
We're at the final RC... I think we can do a release very soon - there may be small issues but nothing that would be a showstopper and couldn't be left to a later bugfix...
I haven't done anything on carla-lmms since I posted the picture, but Carla2 is now at beta2 and a lot more stable.
One thing that would really help me (and I guess other devs) was having a null plugin that did nothing, maybe prints midi notes.
I've considered the same thing - writing a well-documented example/reference plugin. The problem is, that the API is sort of a messy hodgepodge of different kinds of instruments - we have multistream instruments, which render each note in their own thread, then we have two kinds of single-stream instruments, ones using MIDIevents and ones using the native note handles... so it's kind of hard to write a single example plugin that would show all that functionality. I'm hoping we could simplify the instrument APIs in the future...
Will the API change much from 1.1 to 1.2?
For now, I don't think so - currently, the changes to the API mostly only affect multistream instruments. However, if you have any problems rebasing to master, or any other questions about the codebase or API, feel free to ask me, I should be able to help with that...
fundamental
Established Member
Posts: 165
Joined: Thu Nov 07, 2013 1:19 pm
Been thanked: 1 time

Re: Linux Audio Programmers: LMMS needs your help

Post by fundamental »

diizy wrote:I'm currently working on a memory manager for LMMS, which should somewhat improve RT-safety by cutting down heap allocations. It's still a long way to go to make LMMS RT-safe, but it's a step forward.
What are you using for your resizeable memory pool?
Right now I'm looking into TLSF for similarly eliminating heap allocs/deallocs, though I'm curious what others are using.
ZynAddSubFX maintainer
diizy
Established Member
Posts: 105
Joined: Tue Feb 04, 2014 2:48 am

Re: Linux Audio Programmers: LMMS needs your help

Post by diizy »

fundamental wrote:
diizy wrote:I'm currently working on a memory manager for LMMS, which should somewhat improve RT-safety by cutting down heap allocations. It's still a long way to go to make LMMS RT-safe, but it's a step forward.
What are you using for your resizeable memory pool?
Right now I'm looking into TLSF for similarly eliminating heap allocs/deallocs, though I'm curious what others are using.
I'm using a system where I have fixed-size MemoryPool objects, whose size can be set at construction time. At startup, one big MemoryPool is constructed (the size of the initial pool can be adjusted), if later on more memory is needed, then a new MemoryPool is created and added to a QVector<MemoryPool>. The minimum size of each new MemoryPool can also be adjusted.

The MemoryPools themselves use chunks of 64 bytes, with an array of chars indicating the state of each chunk, 1=free 0=in use. In addition there's a QHash holding all the pointers that are in use, and the amount of chunks each pointer reserves, and the MemoryPool each pointer uses, so that they can easily be deallocated when needed.

In addition, I'm adding a 2-tier system where some objects that get constructed/destructed often use their own, smaller dedicated managers (more of a caching system really).

If you're interested, the code can be found here: https://github.com/LMMS/lmms/pull/1088/files
fundamental
Established Member
Posts: 165
Joined: Thu Nov 07, 2013 1:19 pm
Been thanked: 1 time

Re: Linux Audio Programmers: LMMS needs your help

Post by fundamental »

diizy wrote:If you're interested, the code can be found here: https://github.com/LMMS/lmms/pull/1088/files
What's up with all of the locks if this should only be running on the realtime side of things?
ZynAddSubFX maintainer
diizy
Established Member
Posts: 105
Joined: Tue Feb 04, 2014 2:48 am

Re: Linux Audio Programmers: LMMS needs your help

Post by diizy »

fundamental wrote:
diizy wrote:If you're interested, the code can be found here: https://github.com/LMMS/lmms/pull/1088/files
What's up with all of the locks if this should only be running on the realtime side of things?
Because it must also run thread-safely and there's no way to prevent double-allocation of the same memory chunks without locks.

The rt-thread doesn't even allocate memory anyway, the allocs are called from other threads. Locks in other threads should be fine as long as they don't block for seriously long times. I think.

I'm also writing some dedicated cache managers for certain objects that get constructed often. Those will work without locks, by using atomic operations for keeping track of available objects, which is feasible to do because all objects in the cache are the same size. It's much harder to do the same for the generic manager which has to dispense memory for various sized objects.
fundamental
Established Member
Posts: 165
Joined: Thu Nov 07, 2013 1:19 pm
Been thanked: 1 time

Re: Linux Audio Programmers: LMMS needs your help

Post by fundamental »

Ah, fair enough.
I guess I'd need to use one of my tools like stoat to better visualize where exactly the callgraphs can flow within lmms
ZynAddSubFX maintainer
User avatar
raboof
Established Member
Posts: 1855
Joined: Tue Apr 08, 2008 11:58 am
Location: Deventer, NL
Has thanked: 50 times
Been thanked: 74 times
Contact:

Re: Linux Audio Programmers: LMMS needs your help

Post by raboof »

fundamental wrote:one of my tools like stoat to better visualize where exactly the callgraphs can flow within lmms
Sounds interesting, link?
fundamental
Established Member
Posts: 165
Joined: Thu Nov 07, 2013 1:19 pm
Been thanked: 1 time

Re: Linux Audio Programmers: LMMS needs your help

Post by fundamental »

raboof wrote:
fundamental wrote:one of my tools like stoat to better visualize where exactly the callgraphs can flow within lmms
Sounds interesting, link?
https://github.com/fundamental/stoat

and an example usage http://log.fundamental-code.com/2014/08 ... al-example

This is a recent rewrite of a much older static analysis tool of mine (sfpv (Static Function Property Verification)).
ZynAddSubFX maintainer
User avatar
raboof
Established Member
Posts: 1855
Joined: Tue Apr 08, 2008 11:58 am
Location: Deventer, NL
Has thanked: 50 times
Been thanked: 74 times
Contact:

Re: Linux Audio Programmers: LMMS needs your help

Post by raboof »

Post Reply