[asterisk-bugs] [Zaptel 0011194]: ztmonitor issues

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=11194 
====================================================================== 
Reported By:                meneault
Assigned To:                
====================================================================== 
Project:                    Zaptel
Issue ID:                   11194
Category:                   Utilities
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
Zaptel Version:              SVN 
SVN Branch (only for SVN checkouts, not tarball releases):  1.4  
SVN Revision (number only!): 3121 
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             11-08-2007 10:21 CST
Last Modified:              11-09-2007 02:10 CST
====================================================================== 
Summary:                    ztmonitor issues
Description: 
I recently tried ztmonitor to set up my rx/tx gains on my zaptel hardware
and I noticed one issue.
When giving -r -t or -R -T options to monitor rx/tx separately it results
in the receive stream being saved as the transmit one (and the transmit
stream as the receive one). This is the same for preecho streams.
Apparently this bug appeared in revision 2433 (when the feature was added).
====================================================================== 

---------------------------------------------------------------------- 
 meneault - 11-09-07 02:10  
---------------------------------------------------------------------- 
This is used in an inconsistent fashion, as I said the problem lies when
rx/tx streams are fetched separately.
I will show you the case multichannel==1 and preecho==0, it would be
exactly the same for pre-echo cancellation streams:

when fetching arguments:
-r 0	=> ofh[0]  (rx stream saved in ofh[0])
-t 1	=> ofh[1]  (tx stream saved in ofh[1])

opening pseudos:
pfd[0]	=> MONITOR_TX (pfd[0] will monitor TX)
pfd[1]	=> MONITOR    (pfd[1] will monitor RX)

main loop:
buf = read pfd[0]
write(ofh[0], buf) => in rx file we are writing TX stream!!
	
buf2 = read pfd[1]			
write(ofh[1], buf2) => in tx file we are writing RX stream!!
		
if visual
	visualize(buf as tx, buf2 as rx...) 
            => here however the visual mode is correct!
            => just the opposite as file contents!

This more tricky that it look likes because the same descriptor numbers
are used for multichannel==0 and multichannel==1.
Here we definitively needs some defines so as not to mix both streams!
And good variable naming (buf,buf2, res, res2 are not really friendly and
are error prone).

My patch fix this issue, I also noticed:
- an outdated comment in audio code:
"Sound card won't let me set fragment size to 10 64-byte buffers (%x)\n"
"so sound may be choppy: %s.\n" 
=> we are not using 10 buffers anymore and they are not 64-byte long!

- however last part of my patch concerns buffer size, and this part is not
objective (initially I made buffer size equal to block size to leverage
internal buffering and blocking -- but that's not necessary at all).

So I will send three patches instead of one:
- tx/rx issue (variable naming/defines/comments on "magic" numbers)
   ztmonitor-c_patch_txrx_1_4_rev3121

- audio comment issue
   ztmonitor-c_patch_audio_1_4_rev3121

- buffer sizes (this time I will only let buffer size as a define)
   ztmonitor-c_patch_buffer_1_4_rev3121 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
11-09-07 02:10  meneault       Note Added: 0073429                          
======================================================================