D for Speech and Signal Processing

[Chris]

On Friday, 29 November 2013 at 16:58:47 UTC, Baz wrote:
> On Thursday, 28 November 2013 at 10:30:36 UTC, Chris wrote:
>> There are voice analysis and speech processing toolkits like 
>> Covarep and Voicebox (see links below) that were coded in 
>> Matlab, because they were originally only prototypes. There 
>> has been talk of porting them to C++. My first thought, as you 
>> might imagine, was why not use D? However, I don't know if 
>> there are any performance issues, especially for real time 
>> systems (in speech recognition), talking about GC, or in fact 
>> any other issues (number grinding etc.).
>>
>> A lot of the analysis tools are based on some sort of HMM 
>> (http://en.wikipedia.org/wiki/Hidden_Markov_model) and I think 
>> D could handle that elegantly.
>>
>> https://github.com/covarep/covarep
>> http://www.ee.ic.ac.uk/hp/staff/dmb/voicebox/voicebox.html
>
> Hi, I have a little experience in dsp programming using oop 
> languages, so I'll try to give you my mind, but my mind is more 
> related to entertainment dsp softwares (asio, vst, etc...).
>
>> talking about GC
> In "pseudo" real time (RT) audio (one or many buffer are 
> overlapped) you are a in a loop (interesting example is 
> bufferswitch in asio). It's time critical and performance 
> critical, so you'll never create a class neither allocate a 
> buffer here...The idea is: what does trigger the GC: memory 
> allocation and dynamic class instance creation. It's like in 
> GUI programming: you don't destroy and recreate many objects in 
> the "resize/realign" message handler...So the GC problem is 
> solved: there is no GC problem because in RT dsp you won't do 
> something stupid that'll trig a GC pass.
>
> In speech recognition you'll mostly use some frequency-domain 
> technics (not to name the fft), so basically if you don't want 
> to trigger a GC pass, don't use build-in array and make your 
> own array using alloc/malloc/free. For the classes it's the 
> same, you can still make your own class allocator/deallocator, 
> like specified in the manual (even if they say it's 
> deprecated). With user managed classes and array you'll avoid 
> most of the GC passes...But it doesn't mean that the most 
> important stuff is: not to allocate in the audio buffer loop.

Thanks. That's very interesting, I'll look into it.