7
\$\begingroup\$

Posted this question on SO but got no answers. Maybe somebody can help me here.

I recently had a well-working program which streamed WAV and Ogg sounds with OpenAL. I then decided to abstract the source and buffer objects into C++ classes. I got as far as the source class. My function which returns the number of processed buffers is not altering the integer passed to alGetSourcei.

int ALSource::GetBuffersProcessed() const {
    ALint processed;
    alGetSourcei(this->source, AL_BUFFERS_PROCESSED, &processed);
    int error = alGetError();
    if(error != AL_NO_ERROR)
            return -1;
    return processed;
}

I checked that error is never anything but AL_NO_ERROR. I generate the source in the constructor:

alGenSources(1, &source);

This also never gives any error.

The actual symptom of this is that processed is declared but not initialised. It's final value is the initial junk value that it starts out with. (Usually something like -8834824334).

Would this be expected behaviour? The OpenAL specification states that the value should be from 0 - any but is not really any more specific than that. The programmers' guide is the same.

\$\endgroup\$
2
  • \$\begingroup\$ I had to read this twice to figure out what you were asking. Consider reworking the question to make this more obvious. \$\endgroup\$
    – deft_code
    Commented Jul 27, 2010 at 5:00
  • \$\begingroup\$ @caspin, what parts are you having trouble with? \$\endgroup\$
    – Anthony
    Commented Jul 27, 2010 at 6:33

1 Answer 1

3
\$\begingroup\$

OK, here goes the solution. The root cause was an implicit destructor call which destroyed my AL context. What's interesting is that a bug in the Windows implementation causes OpenAL to fail silently when there is no current context. So all my calls to alGetError returned AL_NO_ERROR because there was no context. It's a nasty little bug, in my opinion.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .