Hello,
I am currently developing an application of this type (spectrogram + audiostream) :
https://i.ibb.co/sPXMbf1/screenshot-framed-1.png
But i have one problem and one question :
Problem :
I generate the spectrum with this function :
@JvmStatic
fun generateSpectrum(shortArray: ShortArray) {
val sw = Stopwatch()
sw.start()
val buffer = ShortValues(shortArray)
val fft = Radix2FFT(buffer.size())
val fftData = DoubleValues()
fft.run(buffer, fftData)
fftData.setSize(fftSize)
val spectrogramItems = spectrogramValues.itemsArray
val fftItems = fftData.itemsArray
val spectrogramSize = spectrogramValues.size()
val fftSize = fftData.size()
val offset = spectrogramSize - fftSize
System.arraycopy(spectrogramItems, fftSize, spectrogramItems, 0, offset)
System.arraycopy(fftItems, 0, spectrogramItems, offset, fftSize)
spectrogramDS.updateZValues(spectrogramValues)
sw.stop()
Log.v(TAG, "SPECTRUM : " + sw.elapsedTime.toString())
}
It works very well to generate data from a shortarray (from microphone or saved shortarray). Except that, sometime when I launch replays, on average 1 in 10 replays will be very slow. As you can see, I put stopwatch to isolate the problems and it comes from this function. This function takes an average of 2 to 3 milliseconds in normal time to perform. When a replay is slow, this function takes on average between 6 and 8 milliseconds to execute.
Why? Do you have any ideas?
Question :
I can read data from a microphone as shown on the screenshot. I also know how to replay them by cleaning spectrogramDS and sending back the read data.
Now, let’s say I want to replay but in the form of :
What is not yet played is drawn in grey (so i don’t clean) and as the dataset plays back, it takes the same color as the recording. Basically, we see in advance the sound template that is being replayed but also where we are currently in the replay.
Is it possible ?
Thanks for you answer,
Wavely
- damien gaillard asked 5 years ago
-
Hi Damien, the only ScIChart function I can see in your code is spectrogramDS.updateZValues(spectrogramValues). If you comment that one line out – does the performance problem go away? In other words, can you isolate the performance cost of updating the DataSeries? It’s worth running a profiler over this to see the individual cost of each line of code, which will give us a better picture. Best regards, Andrew
-
Do you have any screenshots/videos which demonstrate desired output for the second part of your question? For now it isn’t clear for me what you’re trying to achieve.
- You must login to post comments
Hi Damien,
I believe this issue could be caused by creating DoubleValues and ShortValues in that method. These classes are wrappers around arrays and if you set large size this would create them every time you generateSpectrum() and after that GC will need to dispose them. The problem is that in Android this process pauses entire app for some time and if you allocate large arrays then GC will be performed very often because at some point there will be no free memory to allocate. I would suggest to refactor your code and reuse ‘fftData ‘ and ‘buffer’ values between generateSpectrum() calls. Hope this will fix the issue.
Best regards,
Yura
- Yura Khariton answered 5 years ago
- You must login to post comments
Hello !
I will make some test keeping ‘fftData ‘ and ‘buffer’ between each call, if the problem is not solved, I will perform a more in-depth analysis of which line of this function is lagging
I will keep you informed, and I will also come back with more information about the question I also asked you.
Best regards
- damien gaillard answered 5 years ago
- You must login to post comments
Ok problem solved by removing DoubleValues and ShortValues ! Thank you
Now, regarding my question about the replay, my team and me talked about it and finally this feature doesn’t have much interest. I won’t bother you about it anymore.
Thank you for your support
Everything is resolved
- damien gaillard answered 5 years ago
- You must login to post comments
Please login first to submit.