Audio transport yields mixed success

In one of my many stints of developing electronic gizmos as a contractor for the government, I was asked to build a transport device that would take in analog audio, transport it a distance, and then output it in a proprietary digital link format.
 
To do so, the analog audio was input to a standard "Channel Bank," that took analog in and output the now framed digital audio data on a T1 line, which could be run the distance needed. The trick was taking the standard framed T1 (1.536 Mbit/sec) and then converting the format to a 1.151 Mbit/sec proprietary Link format. Luckily the T1 was framed, so it would be rather easy to develop a "frame sync" for it.
 
I was not too worried about the complexity of the design. The rate changer circuitry was just shift registers with a PLD to control them. The audio data would need to be converted from 8 bit mu-law to 6 bit linear, but I could implement that in a small PROM. I figured I'd use a spare VME wire-wrap board (which could easily accommodate the needed circuitry), make up a simple wire harness, and put it in one of those Commercial Off-The-Shelf (COTS) 2 RU rack-mount chassis. I put together a quick PowerPoint brief and the customer was recognizably enthusiastic.
 
The problem came when I actually had to work together with our manufacturing department to put together a bid for building the unit. When I saw the bid they put together, it was four times the money that the customer had planned to cover the effort!!! What I found out was that, due to our rather draconian Configuration Management process, every item had a part number and associated drawings. These items were required to be spared, since they were being installed in an already deployed system. Our customer used to refer to our company as "BAM!" ("bring another million" -- apologies to Emeril Lagasse).
 
What to do??? Well, I guessed it was time to work around the "system." I talked to one of my associated contractors (whom I had known for many years) and he put me in touch with a small company that made T1 and E1 comms gear. The solution we came up with consisted of a Channel Bank on the remote end and a 2RU rack shelf on the local end, containing two slightly modified T1 and E1 interface cards. The T1 interface card had a mod wire run to the connector to give us a frame sync pulse for the T1, and the E1 card (which was based on a Xilinx SPARTAN gate array) had a couple of re-wires to bring in the Link clock and Link frame sync (the EPROM for the Xilinx code was also socketed for our use).
 
All of the hardware was paid for and I was left with enough funding to pay for three man-months of labor for one of our Xilinx gurus to write the VHDL code to build the interface (and a few weeks for testing). More importantly, the Customer was happy that we were able to implement this experiment with the funding he already had.
 
Of course, "the proof of the pudding is in the eating," and the question is "Did it work?" As with all prototypes, we had a few "teething" problems, but they were more a result of unfamiliarity with the vendor's product than actual design errors. I have to admit that I did get the data skewed one bit, but that problem was easy to find. The REAL headache was that the vendor had modified the cards and then shipped them to us with no documentation. I had a very hard time tracing the circuits on the 2 1/2" x 4" card, which used exclusively surface-mount chips. When I FINALLY got the schematic, I found that our T1 and Link frame sync signals were not run on the "clock spines" of the Xilinx. That is something I would have done differently if I could have.
 
The experiment worked and could have been put to good use transporting the audio signals that we were interested in, but I have to admit that it was not 100%. Of the 24 audio channels on the T1, we were only able to use about 16 of them. The rest were noisy due to routing issues internal to the Xilinx, as the audios near the low>hi and hi>low transitions of the frame syncs received the bulk of the noise.