36
edits
Changes
Jump to navigation
Jump to search
Line 25:
Line 25: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
no edit summary
During the processing of an audio frame to be presented to Asterisk, all client's buffers that are associated with a channel instance (node) are examined by taking an average of the RSSI value for each sample in the associated time period (the first 160 samples of the abstracted buffer (which is the physical buffer from drainindex to drainindex + 159) and whichever one, if any that has the largest RSSI average greater then zero is selected as the audio source for that frame. The corresponding audio buffer's contents (in the corresponding offsets) are presented to Asterisk, then ALL the clients corresponding RSSI data is set to 0, ALL the clients corresponding audio is set to quiet (0x7f). The overwriting of the buffers after their use/examination is done so that the next time those positions in the physical buffer are examined, they will not contain any data that was not actually put there, since all client's buffers are significant regardless of whether they were populated or not. This allows for the true 'connectionless-ness' of this protocol implementation.
During the processing of an audio frame to be presented to Asterisk, all client's buffers that are associated with a channel instance (node) are examined by taking an average of the RSSI value for each sample in the associated time period (the first 160 samples of the abstracted buffer (which is the physical buffer from drainindex to drainindex + 159) and whichever one, if any that has the largest RSSI average greater then zero is selected as the audio source for that frame. The corresponding audio buffer's contents (in the corresponding offsets) are presented to Asterisk, then ALL the clients corresponding RSSI data is set to 0, ALL the clients corresponding audio is set to quiet (0x7f). The overwriting of the buffers after their use/examination is done so that the next time those positions in the physical buffer are examined, they will not contain any data that was not actually put there, since all client's buffers are significant regardless of whether they were populated or not. This allows for the true 'connectionless-ness' of this protocol implementation.
=Asterisk CLI Commands=
These are the CLI commands that Asterisk and chan/voter supports:
*voter debug level {0-7}
**Prints debug information from the channel driver at increasing verbosity
*voter test instance_id [test value]
**Specifies/Queries test mode for voter instance
**Test Value can be:
***0 - Normal voting operation
***1 - Randomly pick which client of all that are receiving at the max RSSI value to use
***>1 - Cycle thru all the clients that are receiving at the max RSSI value with a cycle time of (test mode - 1) frames. In other words, if you set it to 2, it will change every single time. If you set it to 11, it will change every 10 times. This is serious torture test.
*voter prio instance_id [client_id] [priority value]
**Specifies/Queries priority value for voter client
*voter record instance_id [record filename]
**Enables/Specifies (or disables) recording file for chan/voter
*voter tone instance_id [new_tone_level(0-250)]
**Sets/Queries Tx CTCSS level for specified chan/voter instance
*voter reload
**Reload chan/voter parameters
*voter display [instance]
**Display voter instance clients
*voter txlockout [instance] <client_list>
**Set Tx Lockout for voter instance clients
*voter ping [client] <# pings, 0 to abort>
**Ping (check connectivity) to client