Anyone using Portaudio?

Andrej Mitrovic andrej.mitrovich at
Sun Oct 17 17:16:10 PDT 2010

Here's the update, I hope someone puts it in the repo:

On 10/18/10, Andrej Mitrovic <andrej.mitrovich at> wrote:
> Problem solved!
> The D header file for Portaudio was bugged, I'll update it in the
> Bindings project.
> On 10/18/10, Andrej Mitrovic <andrej.mitrovich at> wrote:
>> This is interesting. It appears the callback function is not called
>> frequently enough. Really weird.. it must be some bug in my code.
>> You see, I have a sample rate of 44100hz per second, and a buffer size
>> of 64. This basically means that for 1 second of audio I need to fill
>> ~680buffers per second in my callback (the callback is called ~680
>> times per second, and each buffer is 64 frames in size), so ~680 * 64
>> = ~44100. The C code gets its callback called around 680 times, but
>> interestingly the D code gets its callback called only 29 times. This
>> is why I hear the sound stuttering, its because my callback isn't
>> getting called frequently enough and the audio card is filling the
>> missing buffers with zeros.
>> Now I have to figure out why it's not getting called often enough.
>> On 10/18/10, Andrej Mitrovic <andrej.mitrovich at> wrote:
>>> 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> wrote:
>>>> On Mon, 18 Oct 2010 01:10:31 +0400, Andrej Mitrovic
>>>> <andrej.mitrovich at> 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