At 03:46 PM 4/8/2006, Robert McGwier wrote:
This is my mistake for acknowledging a bug report here. All bug reports
for released versions are to be entered on the bug tracker. That way
everyone, including me, can have record of it. This is a promise: I
have acknowledged my last bug report here. If Jim wants to follow bugs
and action on them, that is what the bug tracker is for.
Wasn't so much the bug report/fix that I think is useful. As you say, the
bug tracker is a better place. It was the explanation of how the innards
work. The content in the bug tracker, the entire thing is:
Report Detail:
The audio buffer size request was not actually passed to the portaudio call
in the audio module. Reported by KD5TFD.
Response:
Audio buffer size request is now handled correctly in audio.cs
---
This doesn't give much explanation of how the buffer size is handled, where
it gets set, etc, all of which was discussed in the email interchange.
For instance, Bob's explanation:
The reasons for doing it this way is the horrible behind the scenes
stuff that goes on with managed code. We have proven absolutely
conclusively that referring to values declared in the console in the
callback routines regularly results in stalls. Now, down inside the
callbacks, we refer to local variables for these kinds of things.
There might be a few areas that still need cleaning up but there are no
longer console.Variable public properties with their hidden access
controls blocking us. If someone outside the audio class wants to talk
to the local private control variables, they must do it through the
audio class public access point using the appropriate public property.
---
Is quite useful to a potential developer/modifier of the code.
Jim
