Re: [Flexradio] Audio buffer sizes locked at 2048?
Bob, we still love you and it is refreshing to realize that you are, after all, still human. Your intellect is respected and admired more than you could possibly know. Brilliance is your worst enemy. 73 Ross K9COX PS: I really liked the CW demo. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert McGwier Sent: Saturday, April 08, 2006 6:23 PM To: Frank Brickle Cc: FlexRadio@flex-radio.biz; Jim Lux Subject: Re: [Flexradio] Audio buffer sizes locked at 2048? This one was stupidity itself. Very ugly. It should be tracked around the world as a monument to programmer ineptitude. Frank Brickle wrote: > Oh, well, why not take the easy way out? Just eliminate all remaining > bugs and then there's nothing to track ;-) > > 73 > Frank > AB2KT > > 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. >> >> Best wishes, >> Bob >> >> >>> >>> >>> >> >> > > ___ FlexRadio mailing list FlexRadio@flex-radio.biz http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz Archive Link: http://mail.flex-radio.biz/pipermail/flexradio_flex-radio.biz/ FlexRadio Homepage: http://www.flex-radio.com
Re: [Flexradio] Audio buffer sizes locked at 2048?
Bob
Do not apologize. Lot of us lurkers are interested and stimulated by
info
as to where things are in the software but are afraid to ask.
There is another point. We just started a reflector for those not
interested in software but in the operational aspects of the hardware. Thus
this is the forum for these topics.
73 DE Jerry NO2T (lurking)
At 02:23 PM 4/8/2006 -0400, you wrote:
>In setup.cs this function changes the audio buffer size when the setup
>audio value is changed:
>
>private void comboAudioBuffer1_SelectedIndexChanged(object
>sender, System.EventArgs e)
>{
>if(console.PowerOn)
>{
>console.PowerOn = false;
>Thread.Sleep(100);
>console.BlockSize1 = Int32.Parse(comboAudioBuffer1.Text);
>DttSP.SetAudioSize(console.BlockSize1);
>DttSP.SetKeyerResetSize(console.BlockSize1);
>console.PowerOn = true;
>}
>else
>{
>console.BlockSize1 = Int32.Parse(comboAudioBuffer1.Text);
>DttSP.SetAudioSize(console.BlockSize1);
>DttSP.SetKeyerResetSize(console.BlockSize1);
>}
>
>}
>
>
>console.BlockSize1 is a public property.
>
> From console.cs:
>
>private int block_size1;
>public int BlockSize1
>{
>get { return block_size1; }
>set
>{
>block_size1 = value;
>Audio.BlockSize = value;
>CWForm.CWBlockSize = block_size1;
>}
>}
>
>
>AudioBlockSize is a public property and from audio.cs
>
>
>private static int block_size = 1024;
>public static int BlockSize
>{
>set
>{
>block_size = value;
>}
>get { return block_size; }
>}
>
>
>
>I added Debug.WriteLine after block_size = value;
>
>and got the following output from the output window
>
>PowerSDR.exe': Loaded
>'c:\windows\assembly\gac\system.windows.forms\1.0.5000.0__b77a5c561934e089\
system.windows.forms.dll',
>No symbols loaded.
>'PowerSDR.exe': Loaded
>'c:\windows\assembly\gac\system\1.0.5000.0__b77a5c561934e089\system.dll',
>No symbols loaded.
>'PowerSDR.exe': Loaded
>'c:\windows\assembly\gac\system.drawing\1.0.5000.0__b03f5f7f11d50a3a\system
.drawing.dll',
>No symbols loaded.
>'PowerSDR.exe': Loaded
>'c:\windows\assembly\gac\system.data\1.0.5000.0__b77a5c561934e089\system.da
ta.dll',
>No symbols loaded.
>'PowerSDR.exe': Loaded
>'c:\windows\assembly\gac\system.xml\1.0.5000.0__b77a5c561934e089\system.xml
.dll',
>No symbols loaded.
>'PowerSDR.exe': Loaded
>'c:\windows\assembly\gac\adodb\7.0.3300.0__b03f5f7f11d50a3a\adodb.dll',
>No symbols loaded.
>'PowerSDR.exe': Loaded 'c:\documents and
>settings\n4hy2\desktop\powersdrsvn\trunk\bin\debug\interop.adox.dll', No
>symbols loaded.
>'PowerSDR.exe': Loaded
>'c:\windows\assembly\gac\custommarshalers\1.0.5000.0__b03f5f7f11d50a3a\cust
ommarshalers.dll',
>No symbols loaded.
>'PowerSDR.exe': Loaded
>'c:\windows\assembly\gac\microsoft.directx.directinput\1.0.2902.0__31bf3856
ad364e35\microsoft.directx.directinput.dll',
>No symbols loaded.
>'PowerSDR.exe': Loaded
>'c:\windows\assembly\gac\microsoft.directx\1.0.2902.0__31bf3856ad364e35\mic
rosoft.directx.dll',
>No symbols loaded.
>1024
>512
>The thread 'Splash Screen Thread' (0xb20) has exited with code 0 (0x0).
>
>
>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.
>
>I apologize for boring everyone with this. Why it was posted publicly
>with two people capable of answering it I do not know.
>
>
>Bob
>
>
>Bill Tracey wrote:
>> Somewhere between 1.4.5 preview 12 and 1.4.5 preview 16 it appears the
>> buffer size selection on Setup->Audio got disconnected from the value the
>> code is actually using. Currently (1.6.0) it looks like the block_size is
>> locked to 2048 in audio.cs (private static int block_size1 is initialized
>> to 2048 and never changed) -- intentional, or collateral damage in trying
>> to keep audio.cs from reaching out to Console.cs properties?
>>
>> Regards,
>>
>> Bill (kd5tfd)
>>
>>
>
>
>--
>AMSAT VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats,
>NJQRP/AMQRP, QRP ARCI, QCWA, FRC.
Re: [Flexradio] Audio buffer sizes locked at 2048?
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
Re: [Flexradio] Audio buffer sizes locked at 2048?
This one was stupidity itself. Very ugly. It should be tracked around the world as a monument to programmer ineptitude. Frank Brickle wrote: Oh, well, why not take the easy way out? Just eliminate all remaining bugs and then there's nothing to track ;-) 73 Frank AB2KT 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. Best wishes, Bob
Re: [Flexradio] Audio buffer sizes locked at 2048?
Oh, well, why not take the easy way out? Just eliminate all remaining bugs and then there's nothing to track ;-) 73 Frank AB2KT 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. Best wishes, Bob Jim Lux wrote: At 02:25 PM 4/8/2006, Bill Tracey wrote: I'd posted to the list because I thought discussion of what's going on inside the code was a good thing. My thought was open discussion of code changes for an open project with multiple developers was a good thing so other people mucking in the code are aware of changes/questions/etc. I'll take the discussion off the list. Leave the discussion on the list. It is the description of just these sorts of peculiarities that need to be kept somewhere. Whether or not the data is useful today, or boring, doesn't mean it won't be useful a year from now, when someone else is seeking to understand. More than once over the past years, I've resorted to searching my back email for an answer to some technical question that somehow never made it into the formal documentation. Bill (kd5tfd) At 01:23 PM 4/8/2006, Robert McGwier wrote: <..> I apologize for boring everyone with this. Why it was posted publicly with two people capable of answering it I do not know. Bob
Re: [Flexradio] Audio buffer sizes locked at 2048?
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. Best wishes, Bob Jim Lux wrote: At 02:25 PM 4/8/2006, Bill Tracey wrote: I'd posted to the list because I thought discussion of what's going on inside the code was a good thing. My thought was open discussion of code changes for an open project with multiple developers was a good thing so other people mucking in the code are aware of changes/questions/etc. I'll take the discussion off the list. Leave the discussion on the list. It is the description of just these sorts of peculiarities that need to be kept somewhere. Whether or not the data is useful today, or boring, doesn't mean it won't be useful a year from now, when someone else is seeking to understand. More than once over the past years, I've resorted to searching my back email for an answer to some technical question that somehow never made it into the formal documentation. Bill (kd5tfd) At 01:23 PM 4/8/2006, Robert McGwier wrote: ><..> >I apologize for boring everyone with this. Why it was posted publicly >with two people capable of answering it I do not know. > > >Bob -- AMSAT VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP/AMQRP, QRP ARCI, QCWA, FRC. ARRL SDR Wrk Grp Chairman Laziness is the number one inspiration for ingenuity. Guilty as charged!
Re: [Flexradio] Audio buffer sizes locked at 2048?
At 02:25 PM 4/8/2006, Bill Tracey wrote: I'd posted to the list because I thought discussion of what's going on inside the code was a good thing. My thought was open discussion of code changes for an open project with multiple developers was a good thing so other people mucking in the code are aware of changes/questions/etc. I'll take the discussion off the list. Leave the discussion on the list. It is the description of just these sorts of peculiarities that need to be kept somewhere. Whether or not the data is useful today, or boring, doesn't mean it won't be useful a year from now, when someone else is seeking to understand. More than once over the past years, I've resorted to searching my back email for an answer to some technical question that somehow never made it into the formal documentation. Bill (kd5tfd) At 01:23 PM 4/8/2006, Robert McGwier wrote: ><..> >I apologize for boring everyone with this. Why it was posted publicly >with two people capable of answering it I do not know. > > >Bob
Re: [Flexradio] Audio buffer sizes locked at 2048?
I'd posted to the list because I thought discussion of what's going on inside the code was a good thing. My thought was open discussion of code changes for an open project with multiple developers was a good thing so other people mucking in the code are aware of changes/questions/etc. I'll take the discussion off the list. Cheers, Bill (kd5tfd) At 01:23 PM 4/8/2006, Robert McGwier wrote: <..> I apologize for boring everyone with this. Why it was posted publicly with two people capable of answering it I do not know. Bob
Re: [Flexradio] Audio buffer sizes locked at 2048?
In setup.cs this function changes the audio buffer size when the setup
audio value is changed:
private void comboAudioBuffer1_SelectedIndexChanged(object
sender, System.EventArgs e)
{
if(console.PowerOn)
{
console.PowerOn = false;
Thread.Sleep(100);
console.BlockSize1 = Int32.Parse(comboAudioBuffer1.Text);
DttSP.SetAudioSize(console.BlockSize1);
DttSP.SetKeyerResetSize(console.BlockSize1);
console.PowerOn = true;
}
else
{
console.BlockSize1 = Int32.Parse(comboAudioBuffer1.Text);
DttSP.SetAudioSize(console.BlockSize1);
DttSP.SetKeyerResetSize(console.BlockSize1);
}
}
console.BlockSize1 is a public property.
From console.cs:
private int block_size1;
public int BlockSize1
{
get { return block_size1; }
set
{
block_size1 = value;
Audio.BlockSize = value;
CWForm.CWBlockSize = block_size1;
}
}
AudioBlockSize is a public property and from audio.cs
private static int block_size = 1024;
public static int BlockSize
{
set
{
block_size = value;
}
get { return block_size; }
}
I added Debug.WriteLine after block_size = value;
and got the following output from the output window
PowerSDR.exe': Loaded
'c:\windows\assembly\gac\system.windows.forms\1.0.5000.0__b77a5c561934e089\system.windows.forms.dll',
No symbols loaded.
'PowerSDR.exe': Loaded
'c:\windows\assembly\gac\system\1.0.5000.0__b77a5c561934e089\system.dll',
No symbols loaded.
'PowerSDR.exe': Loaded
'c:\windows\assembly\gac\system.drawing\1.0.5000.0__b03f5f7f11d50a3a\system.drawing.dll',
No symbols loaded.
'PowerSDR.exe': Loaded
'c:\windows\assembly\gac\system.data\1.0.5000.0__b77a5c561934e089\system.data.dll',
No symbols loaded.
'PowerSDR.exe': Loaded
'c:\windows\assembly\gac\system.xml\1.0.5000.0__b77a5c561934e089\system.xml.dll',
No symbols loaded.
'PowerSDR.exe': Loaded
'c:\windows\assembly\gac\adodb\7.0.3300.0__b03f5f7f11d50a3a\adodb.dll',
No symbols loaded.
'PowerSDR.exe': Loaded 'c:\documents and
settings\n4hy2\desktop\powersdrsvn\trunk\bin\debug\interop.adox.dll', No
symbols loaded.
'PowerSDR.exe': Loaded
'c:\windows\assembly\gac\custommarshalers\1.0.5000.0__b03f5f7f11d50a3a\custommarshalers.dll',
No symbols loaded.
'PowerSDR.exe': Loaded
'c:\windows\assembly\gac\microsoft.directx.directinput\1.0.2902.0__31bf3856ad364e35\microsoft.directx.directinput.dll',
No symbols loaded.
'PowerSDR.exe': Loaded
'c:\windows\assembly\gac\microsoft.directx\1.0.2902.0__31bf3856ad364e35\microsoft.directx.dll',
No symbols loaded.
1024
512
The thread 'Splash Screen Thread' (0xb20) has exited with code 0 (0x0).
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.
I apologize for boring everyone with this. Why it was posted publicly
with two people capable of answering it I do not know.
Bob
Bill Tracey wrote:
Somewhere between 1.4.5 preview 12 and 1.4.5 preview 16 it appears the
buffer size selection on Setup->Audio got disconnected from the value the
code is actually using. Currently (1.6.0) it looks like the block_size is
locked to 2048 in audio.cs (private static int block_size1 is initialized
to 2048 and never changed) -- intentional, or collateral damage in trying
to keep audio.cs from reaching out to Console.cs properties?
Regards,
Bill (kd5tfd)
--
AMSAT VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats,
NJQRP/AMQRP, QRP ARCI, QCWA, FRC. ARRL SDR Wrk Grp Chairman
Laziness is the number one inspiration for ingenuity. Guilty as charged!
