-
Notifications
You must be signed in to change notification settings - Fork 247
Comment accuracy: minimal wording fixes in src/ #3877
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. Weβll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
174827d
b08eca6
3351d54
26e42be
89c98b3
47abc32
d369482
c150d5c
a1d5b5e
2660f9a
d8bddae
5f05e77
de662fa
264469d
1d393b7
cd30e51
08f5f75
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -164,8 +164,8 @@ bool CNetBuf::Put ( const CVector<uint8_t>& vecbyData, int iInSize ) | |
| return false; | ||
| } | ||
|
|
||
| // to get the number of input blocks we assume that the number of bytes for | ||
| // the sequence number is much smaller than the number of coded audio bytes | ||
| // to get the number of input blocks we assume that the total sequence number | ||
| // overhead, iNumBlocks * iNumBytesSeqNum, is smaller than iBlockSize | ||
| const int iNumBlocks = /* floor */ ( iInSize / iBlockSize ); | ||
|
|
||
| // copy new data in internal buffer | ||
|
|
@@ -191,8 +191,8 @@ bool CNetBuf::Put ( const CVector<uint8_t>& vecbyData, int iInSize ) | |
| } | ||
|
|
||
| // The 1-byte sequence number wraps around at a count of 256. So, if a packet is delayed | ||
| // further than this we cannot detect it. But it does not matter since such a packet is | ||
| // more than 100 ms delayed so we have a bad network situation anyway. Therefore we | ||
| // further than half of this we cannot detect it. But it does not matter since such a packet is | ||
| // more than 170 ms delayed so we have a bad network situation anyway. Therefore we | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Actually, I find the whole comment (not this changed bit) very hard to digest with lots of repeated phrases.
|
||
| // assume that the sequence number difference between the received and local counter is | ||
| // correct. The idea of the following code is that we always move our "buffer window" so | ||
| // that the received packet fits into the buffer. By doing this we are robust against | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -716,9 +716,9 @@ int CChannel::GetUploadRateKbps() | |
| { | ||
| const int iAudioSizeOut = iNetwFrameSizeFact * iAudioFrameSizeSamples; | ||
|
|
||
| // we assume that the UDP packet which is transported via IP has an | ||
| // additional header size of ("Network Music Performance (NMP) in narrow | ||
| // band networks; Carot, Kraemer, Schuller; 2006") | ||
| // we assume the PPPoE-over-ATM DSL access path described in ("Network Music | ||
| // Performance (NMP) in narrow band networks; Carot, Kraemer, Schuller; 2006"), | ||
| // whose additional header size is | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This comment now omits the first line (UDP) from the description. It's probably also worth stating something like "PPPoE-over-ATM DSL chosen as a general domestic use case" (or whatever reason the authors gave in their paper). |
||
| // 8 (UDP) + 20 (IP without optional fields) = 28 bytes | ||
| // 2 (PPP) + 6 (PPPoE) + 18 (MAC) = 26 bytes | ||
| // 5 (RFC1483B) + 8 (AAL) + 10 (ATM) = 23 bytes | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -482,7 +482,7 @@ void CClient::SetDoAutoSockBufSize ( const bool bValue ) | |
| // | ||
| // When the first gain or pan change message is requested after an idle period (i.e. the timer is not | ||
| // running), it will be sent immediately, and a timer started. The timer period is dependent on | ||
| // the current ping time to the remote server. | ||
| // the current ping time to the remote server, which only a GUI client measures (see #3874). | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Not worth mentioning. Any "bad design" should be captured in an issue and addressed that way, rather than in code comments.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Overall AI hasn't done great on this "update the comments" exercise, but I think this change is valuable. Since the day robots took my writing career, I miss this eternal tension between developers and documentarians. The perfect should not be the enemy of the good. Futureware doesn't help anyone today. Should this matter become fixed, one could revel and delight in the removal of this mention of the fixed flaw. I've linked arms with developers and spun with delight as we threw out obsolete guidance. This worked well so long as I was the benevolent dictator of the documentation. Once the world moved to repos and toward engineers applying their engineering acumen to editorial judgements, as you do here, quality has suffered. Perfected futureware is the psychological bias of the lead engineer. Why mention a thing we should fix? To avoid suffering, that's why. My career involved using a magnifying lense on things developers want to disappear, and sometimes even hide. So this is nothing new. But please consider my differing point of view, oh benevolent dictator.
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
No, it'll get overlooked. Probably even by an AI coding agent.
It's not clear from the title of the referenced PR that it's directly related. And any "This is wrong" should have a "Fix in" reference rather than a "discovered as wrong in" reference. Again, it's negativity. |
||
| // | ||
| // If a gain or pan change message is requested while the timer is still running, the new value is not sent, | ||
| // but just stored in newGain or newPan within clientChannels[iId], and the minGainOrPanId and maxGainOrPanId | ||
|
|
@@ -1000,7 +1000,7 @@ void CClient::OnControllerInMuteMyself ( bool bMute ) | |
| void CClient::OnClientIDReceived ( int iServerChanID ) | ||
| { | ||
| // if we have just connected to a running server, iActiveChannels will be 0 | ||
| // if iActiveChannels is not 0, the server must have been restarted on the fly | ||
| // if iActiveChannels is not 0, the server was restarted or our channel timed out | ||
| // in that case, channels might have changed, so clear our list to get it afresh. | ||
| if ( iActiveChannels != 0 ) | ||
| { | ||
|
|
@@ -1009,7 +1009,7 @@ void CClient::OnClientIDReceived ( int iServerChanID ) | |
| } | ||
|
|
||
| // allocate and map client-side channel 0 | ||
| int iChanID = FindClientChannel ( iServerChanID, true ); // should always return channel 0 | ||
| int iChanID = FindClientChannel ( iServerChanID, true ); // returns channel 0 for an in-range iServerChanID | ||
|
|
||
| // for headless mode we support to mute our own signal in the personal mix | ||
| // (note that the check for headless is done in the main.cpp and must not | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -575,8 +575,8 @@ CClientDlg::CClientDlg ( CClient* pNCliP, | |
|
|
||
| QObject::connect ( &ConnectDlg, &CConnectDlg::ReqServerListQuery, this, &CClientDlg::OnReqServerListQuery ); | ||
|
|
||
| // note that this connection must be a queued connection, otherwise the server list ping | ||
| // times are not accurate and the client list may not be retrieved for all servers listed | ||
| // note that this delivery must be queued, otherwise the server list ping times are not | ||
| // accurate and the client list may not be retrieved for all servers listed | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hm. That's not what |
||
| // (it seems the sendto() function needs to be called from different threads to fire the | ||
| // packet immediately and do not collect packets before transmitting) | ||
| QObject::connect ( &ConnectDlg, &CConnectDlg::CreateCLServerListPingMes, this, &CClientDlg::OnCreateCLServerListPingMes, Qt::QueuedConnection ); | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -102,7 +102,7 @@ LED bar: lbr | |
|
|
||
| // System block size, this is the block size on which the audio coder works. | ||
| // All other block sizes must be a multiple of this size. | ||
| // Note that the UpdateAutoSetting() function assumes a value of 128. | ||
| // Note that the IIR_WEIGTH_* filter constants in buffer.h assume values of 64 and 128. | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Possibly worth splitting out "completely wrong" from "unclear or unhelpful". This looks like the former. |
||
| #define SYSTEM_FRAME_SIZE_SAMPLES 64 | ||
| #define DOUBLE_SYSTEM_FRAME_SIZE_SAMPLES ( 2 * SYSTEM_FRAME_SIZE_SAMPLES ) | ||
|
|
||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -165,7 +165,7 @@ CServer::CServer ( const int iNewMaxNumChan, | |
| iServerFrameSizeSamples = SYSTEM_FRAME_SIZE_SAMPLES; | ||
| } | ||
|
|
||
| // To avoid audio clitches, in the entire realtime timer audio processing | ||
| // To avoid audio glitches, in the entire realtime timer audio processing | ||
| // routine including the ProcessData no memory must be allocated. Since we | ||
| // do not know the required sizes for the vectors, we allocate memory for | ||
| // the worst case here: | ||
|
|
@@ -662,7 +662,7 @@ void CServer::OnTimer() | |
| bool bUseMT = false; | ||
| int iNumBlocks = 0; // init number of blocks for multithreading | ||
| int iMTBlockSize = 0; // init block size for multithreading | ||
| bChannelIsNowDisconnected = false; // note that the flag must be a member function since QtConcurrent::run can only take 5 params | ||
| bChannelIsNowDisconnected = false; // note that the flag is a member since DecodeReceiveData sets it and the check below reads it | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hm. Seems a pretty useless comment now. "This is a flag. It's read and written." The earlier comment explained why it existed at all. |
||
|
|
||
| { | ||
| // Make put and get calls thread safe. | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -151,9 +151,9 @@ class CSocket : public QObject | |
| void ProtocolCLMessageReceived ( int iRecID, CVector<uint8_t> vecbyMesBodyData, CHostAddress HostAdr ); | ||
| }; | ||
|
|
||
| /* Socket which runs in a separate high priority thread --------------------- */ | ||
| /* Socket which runs in a separate thread requesting high priority ---------- */ | ||
| // The receive socket should be put in a high priority thread to ensure the GUI | ||
| // does not effect the stability of the audio stream (e.g. if the GUI is on | ||
| // does not affect the stability of the audio stream (e.g. if the GUI is on | ||
| // high load because of a table update, the incoming network packets must still | ||
| // be put in the jitter buffer with highest priority). | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. (non-feedback) (I'll continue rumbling about this...) |
||
| class CHighPrioSocket : public QObject | ||
|
|
@@ -240,7 +240,7 @@ class CHighPrioSocket : public QObject | |
|
|
||
| void Init() | ||
| { | ||
| // Creation of the new socket thread which has to have the highest | ||
| // Creation of the new socket thread which requests the highest | ||
| // possible thread priority to make sure the jitter buffer is reliably | ||
| // filled with the network audio packets and does not get interrupted | ||
| // by other GUI threads. The following code is based on: | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems a pretty strange way of putting it.