Yeah, that's what I would usually do. The trouble is there's a library in DLL format, and there's only a couple of calls to it and that's it. But somehow the C client code performs better. I've just tried a D1 sample, with the same result. I'll have to investigate..
On 10/17/10, Denis Koroskin <[email protected]> wrote: > On Mon, 18 Oct 2010 01:10:31 +0400, Andrej Mitrovic > <[email protected]> wrote: > >> There's a .d header file in the Bindings project on dsource which I'm >> using with the Portaudio DLL v19, and I'm implicitly loading the DLL. >> There's a sine playback example, and I'm comparing the usage of >> Portaudio from the C sine example (patest_sine.c) compared to the D one >> (patest_sine_hello.d). The C and D code are almost identical, however >> there seems to be a pretty big overhead when using D. >> >> I can safely use a buffer size of 64 frames in the C example, but in the >> D one the minimum I could get was around 1800 frames. >> >> I've tried compiling with-O -release -inline, and issuing a call to >> GC.disable() before the call to Pa_StartStream(). I've also tried >> compiling the portaudio DLL in Release mode. But none of this had any >> effect. Anything lower than 1800 for the buffer size gives me choppy >> sound in D. >> >> There shouldn't be a problem with such a small buffer size, all the data >> is preallocated and the buffers are prefilled with data, so it can't be >> a CPU bottleneck issue. Since D uses C functions directly, I just don't >> see where the overhead could be. >> >> Has anyone used Portaudio with D2 (or D1 for that matter) with >> close-to-equal performance as when using C? > > From my experience, starting with D that purely calls C code and then > slowly porting it to D (one piece of code at a time) usually helps > revealing the problem. Just try to keep it the same (i.e. > interchangeable). You can do that by marking functions as extern (C) and > optionally having some of the variables as extern (C) __gshared. >
