SciChart® the market leader in Fast WPF Charts, WPF 3D Charts, iOS Chart, Android Chart and JavaScript Chart Components



I am currently developing an application of this type (spectrogram + audiostream) :

But i have one problem and one question :

Problem :

I generate the spectrum with this function :

    fun generateSpectrum(shortArray: ShortArray) {
        val sw = Stopwatch()
        val buffer = ShortValues(shortArray)

        val fft = Radix2FFT(buffer.size())
        val fftData = DoubleValues(), fftData)
        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)

        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,

  • Andrew Burnett-Thompson
    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
  • Yura Khariton
    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 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,

  • You must 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

  • You must 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

  • You must to post comments
Showing 3 results
Your Answer

Please first to submit.