Bug on Gigasampler Player 100% CPU #3825
Comments
|
You might just have a weak PC. I remember saying you couldnt play some lsp lmms project since it also was 100% but for me it was fine. |
|
This is not weak PC - Read info in LSP! High quality SF2 samples work fine, Any GIG not. |
|
I can confirm this problem. On my machine the CPU load also increases over time which really baffles me because if someone told me to explicitly implement such a behaviour I would have to think really hard how to accomplish this. 😉 I have also done some profiling with valgrind and got the following result (please click on the image for full size): Much of the time is spent in If you want to have a decay from let's say 1 to 0.001 in a certain amount of time you can compute the number of samples that span that time, e.g. n samples, and then compute a constant factor that you will multiply each sample by. For the given example you would do this by solving 1*x^n = 0.001 for x. This formula translates to: "I want to multiply the start value of 1 n times with the constant x so that I reach 0.001 after n steps." Once you have found x you initialize a variable (let's call it However, even if I replace the implementation of |
|
Here's a profiling result when replacing In this case it's dominated by calls to |
|
Here are the full profiling results: |
This is a guess, based on the load increasing, but are the notes being disposed of properly? From reading the code it looks to me like a note that ends up in the |
|
RC4 testted, Windows 8.1 and Ubuntu 16.04 64bit. -> The problem is still available. |
|
@softrabbit You are right that it has to do with the disposal of the In QMutexLocker locker( &m_notesMutex );
m_notes.push_back( GigNote( midiNote, velocity, _n->unpitchedFrequency(), pluginData ) );
GigNote const & noteAtBack = m_notes.back();
qDebug() << "Pushed note " << ¬eAtBack << "at " << QTime::currentTime().toString() << ", Thread: " << QThread::currentThreadId();In // Delete ended notes (either in the completed state or all the samples ended)
if( it->state == Completed || it->samples.empty() )
{
GigNote const & iteratorNote = *it;
qDebug() << "Removing note " << &iteratorNote << "at " << QTime::currentTime().toString() << ", Thread: " << QThread::currentThreadId();
it = m_notes.erase( it );
if( it == m_notes.end() )
{
break;
}
}This yields results like the following. Please note that I have cut out repetitive blocks: So at the start it is only pushing notes into the list because they all last 10 seconds. Then 10 seconds after the first note was played we get a mixture of removing and pushing because new notes are still being played while the older ones are removed. Finally after a while notes are only removed because no new notes are being played. The GIG Player plugin states on its envelope tab that no envelopes can be set for this kind of instrument so I assume that the envelopes are stored in the GIG format and that they are taken from there. The next thing that we therefore need to find out whether it is really a problem on our side or whether the GIG file used is just inefficient, i.e. if the length of 10 seconds for each sample is stored in that file. |
|
I have replaced the original GIG file used in my testing (found here: https://drive.google.com/file/d/0B8RY2vt8PBm8NV9qN3Y2LU0tRUU/view) with another GIG file and cannot reproduce the problem anymore. Here's what I did:
Because the problem cannot be reproduced with the alternative GIG file I therefore conclude that it's a problem with the GIG file @gdd71 Can you please check the GIG file |
|
@michaelgregorius, "G-Town_Church_Dual_Snare_01.gig" works same as you. Рroblem not with the GIG file.. entire collection "RGD Kit 2.3.4.5" (RGD Kit 5.gig has been submitted for testing ) and "FS-Gibson Les Paul Neck Pick-Up Electric Guitar Direct In" work great in Ardour - 20% CPU, same files in LMMS not. |
|
So.. I converted same used "RGD Kit 5.gig" file to SF2 with "Extreme Sample Converter" software. https://drive.google.com/file/d/0B8RY2vt8PBm8b294MWRfSHJXRmc/view So I still think that this is 100% a bug in LMMS. |
I did some further investigations. The problem is caused in part by the file and in part by LMMS. The file's partThe file defines a release time of 10 seconds for the sample. This can be seen when setting a break point in the method release = region->EG1Release;This sets the release of the ADSR to 9.99999905 seconds. Sometimes even the value 29.9999962 shows up, i.e. a release of half a minute. Please note that this value is read directly from the GIG file (documentation of EG1Release). LMMS' partThe Potential solutionIt seems that LMMS does not remove non-looping samples as soon as they have been played completely. It should be investigated if this can be fixed somehow. |
|
There is already a test that checks if all samples have been played. It can be found on this line. However, it's coupled with the additional condition If I remove the condition |
|
Test File check info: \Real.Giga.Drums.GIGA-DELiRiUM\CD3\ RGD Kit 4 economic.gig 107221114 4/25/01 |
|
My guess would also be @michaelgregorius As for |
|
The links are all dead. So it's a bit of a question if the issue can be reproduced at all. I cannot find the files on my local machine anymore. |
This is confirmed by another user
Test used in project "RGD Kit 5.gig" sample link + Video demo:
https://drive.google.com/file/d/0B8RY2vt8PBm8NV9qN3Y2LU0tRUU/view
Tested in RC3 latest code and older RC3 versions also.
The text was updated successfully, but these errors were encountered: