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.
