Comments (6)
Hi!
Thank you for the suggestion! Actually, I've missed some new features in C#, and now I'm quite surprised (in a good way) about Span<T>
and Memory<T>
types. It seems like Span
could be perfectly used in some parts of the library. However, if I understand correctly, Span<T>
cannot be used as the class member or a property (but it can be used in intermediate operations on stack).
In the nearest future, most likely, I'll be focused on other things, but I think Span<T>
is definitely worth a try and I'll leave this issue opened.
PS. I'd also like to point out that currently memory is (re)used more or less efficiently in the library (as for me, the central part is DSP operations, not the DiscreteSignal
wrapper). New memory is allocated, in most cases, only when it needs to. Two cases of unneccessary allocation/copy are:
- wrap signal around only some part of
Array
; - wrap signal around
IEnumerable
, other thanArray
(conversionToArray()
will take place).
If these two cases become a significant bottleneck, then it's better to use plain arrays in operations (i.e. not wrap them in DiscreteSignal
class).
from nwaves.
Sorry. I've just noticed that this project doesn't updates for 8 months
from nwaves.
Hi!
Despite the sad fact that I haven't committed to this repo for a long time, I'm going to keep on working on it.
Regarding your suggestion - could you, please, give examples of scenarios when it's useful or necessary?
I guess it'll really make sense in some scenarios, and I need clear use-cases for a better understanding and code design.
This lib originally included only offline processing algorithms. I created the DiscreteSignal class just as a wrapper around plain array of floats, so that I could focus more on DSP algorithms and transforms. At this moment the library has already some online processing stuff that operates with plain arrays of floats (IOnlineFilter, BlockConvolver.Process, FirFilter.Process, IirFilter.Process). And currently signals can be created from any enumerable collections (that will ultimately be cast to array anyway. This is because indexing and BlockCopy (memcpy) are heavily used in the lib. So I think if we decide to switch to something more general, the IList interface is more appropriate than IEnumerable. And maybe it's "oldschool C++ guy" talking in me 😃, but I'm quite OK with arrays so far).
from nwaves.
Hello,
Adding a suggestion here instead of creating an issue since the topic is the same.
What do you think about Span? Could it be a suitable tool to enhance the performances instead of relying on IEnumerable and ToArray (which create copies)?
from nwaves.
I'm currently using your library in a project (not really ready to be released on Github) that involves computing a lot of FFTs (between 10 to 100k) and one of the bottlenecks was creating new arrays to store the data where the FFT is computed (considering that I pre-load the entire data in a single array, it's better to point to the place where the data is rather than copying it to a new buffer).
I got a huge performance boost by simply taking your Fft.cs and replacing void Direct(float[] re, float[] im)
with void Direct(Span<float> re, Span<float> im)
(now, is it better to just replace them or create a brand new class for Span, I'm not really sure).
Here's the full file I'm currently using.
EDIT: As a comparison, I tried using NAudio's FastFourierTransform, but I quickly gave up seeing that it'd take minutes (with your implementation it takes around one second to process everything) because of the Complex struct used (instead of using two float arrays).
from nwaves.
Yes, your scenario clearly requires Span
. Out of interest, what was the performace gain? In the "no-span version" did you create only one temp buffer and copy data there each time via BlockCopy()
(or NWaves.Utils.FastCopyTo()
) method? I'm sure Span
is faster; I'm asking, because I'm just curious.
Still, in many cases (I believe, in most cases) temporary buffers must be created anyway, since: 1) either the initial array/signal must be preserved; 2) or frames may overlap (it's common in spectral analysis). Also, as far as I understand, each particular FFT routine will run slightly faster with arrays (Span
adds little overhead for inner loops in array, from what I have read). Of course, in scenarios like yours the overhead of memory copying will be much more significant, but otherwise, array version would be preferred.
So, as for adding Span
support to the lib, users should be able to choose between array version and Span version, thus it's better to add a new class, just like you did. However, I'm still contemplating, should it really be done right now... I don't want to retarget project to .NET Standard 2.1 so far; neither I don't want to add dependency to System.Memory
package. I guess a lot of folks use older versions of VS and .NET (just like me myself )))...
from nwaves.
Related Issues (20)
- Playing saved audio HOT 2
- FeatureExtractor ComputeFrom FastCopy bug HOT 3
- FIR Bandpass Resampling becomes unstable after a long duration HOT 9
- Is there method for series filter? or parallel filter? HOT 2
- How to obtain digital SOS filter from analog zeros and poles? HOT 1
- FFT compatible with OpenAI Whisper features HOT 1
- Help with realtime resampling HOT 3
- Analog poles and zeros of elliptic filter are different from scipy HOT 2
- How to use the polyphase filters implementation
- Buggy RLS filter implementation HOT 3
- how to use stft like scipy.signal "f, t, tf_data = signal.stft(wavedata, fs=fs, window='hamming', nperseg=N_fft, noverlap=int(N_fft*0.8))"? Now we cannot get f,t value. The tf_data is different from var spectrogram = stft.Spectrogram(discreteSignal, normalize: true). HOT 2
- Question: Pitch Patterns
- out of memory using Stft.Spectrogram function HOT 1
- WaveFile: Compiler Warning (level 2) CS0652 @ line 134
- PowerSpectrum and Magnitude spectrum missing from FFT64, RealFFT, RealFFT64
- Order of instruction wrong on wiki page HOT 1
- Pitch shifter produces garbled noise HOT 1
- python speech features fbanks HOT 4
- DiscreteSignal.Samples contain more samples than the original signal HOT 2
- Pitch.FromYin triggers exception for certain sample rates and pitch ranges HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from nwaves.