Anyone using Portaudio?

Andrej Mitrovic andrej.mitrovich at gmail.com
Sun Oct 17 15:06:44 PDT 2010


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 <2korden at gmail.com> wrote:
> On Mon, 18 Oct 2010 01:10:31 +0400, Andrej Mitrovic
> <andrej.mitrovich at none.com> 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.
>


More information about the Digitalmars-d-learn mailing list