Hello there; <br> <br>We've got a client with a 4PCIUF in a server we created for them; when the client records anything through the phone the signal is so quiet it makes our employee schedule publishing software unuseable. The normal pre-generated Teleflow prompts and information sound fine, it is only client recorded input. We have several clients running our software (some for years) on this board and have never encountered a problem like this one. <br> <br>I've done the following tests to try and isolate the problem: <br>- Had the client change phone lines on the server and the phone they record from (no effect) <br>- Called in myself remote and recorded a message from our own phone (just as quiet/unhearable) <br>- Had the client re-record their input, speaking as loud as possible (negligible effect) <br>- Transferred a test .VOX/.WAV sample file from an internal Teleflow server here (transferred file is nice and loud) <br>- Setting the internal Teleflow record volume to "High" (no apparent effect) <br>- Had the client record a .WAV using a microphone, converted it with TFSoundTransform, and then placed it in the Teleflow application (recorded file is nice and loud) <br>- Check the various driver and system settings to see if there were any sharing conflicts, disabled hardware, or other issues (there were none) <br> <br>I feel I've isolated enough factors to say that it is looking like the Dialogic card itself is at fault. The system apparently cannot record using it at any kind of appreciable volume. Some of the .WAV files produced barely even form a discernable wavelength. <br> <br>Because the server OS is Windows XP the Dialogic driver is "unknown" (as it is on all of our client installs) so there's no easy way to be sure it isn't a hardware/resource problem. <br> <br>I have a short term solution of creating a one-time batch file to increase the amplitude of the .VOX/.WAV files, but that obviously is not a long term solution. The client is also resistant to recording solely with the microphone attached to the PC instead of the phone and running TFSoundTransform to go from .WAV to .VOX, seeing as what sold them on the system was the telephone accessibility in the first place. <br> <br>The questions: <br>Has this problem been encountered before? Is it a bad card? Driver problem? I am essentially out of things I can check easily (server is in remote client installation) and am hoping that you guys will have some feedback or further steps. <br> <br>Chris Denschikoff <br>Celayix Software Support <br><a href="http://www.celayix.com" target="_new">http://www.celayix.com</a>

Unfortunately, this issue isn't one we have encountered. (As such, we can't be sure yet about your other questions) <br> <br>You mentioned that you have other customers on this card, but is it that exact model? (Do you have customers on other D4PCIUF cards, or are your other customers on different revisions, such as the D4PCIU card?) <br> <br>What version of the Dialogic software is running on this server? <br> <br>As for the short-term solution, does this make the files usable?

Chris - <br> <br>Thanks for your reply. <br> <br>Our other customers are using this exact same card, about 20 of them, the earliest from 3 years ago. As of yet this is first problem of this nature we've encountered. <br> <br>The customer is running Teleflow 2006.0207 with Dialogic SR 5.1.1 with SP 1 installed. <br> <br>EDIT-I realized I didn't answer your main question; as far as I know we are using the D4PCIU card we always have been. I asked one of our technicians and he said there was a slight change a few years ago, as Intel had discontinued that card but that in all other respects it was identical (e.g. uses the same drivers and has the same behaviour). <br> <br>EDIT^2: I've taken a look at the box for the card this client is using, and it is the D4PCIUF and not the original D4PCIU which has apparently been discontinued. I apologize for the stop and start nature of this information, this is the first time we've had to look into this kind of thing. <br> <br>EDIT^3-The short term solution is mostly that. The TFSoundTransform amplitude increase makes the files louder yes, but at a noticeable drop in quality (noticeable to both client and us). Also the client would prefer to be able to record via phone from multiple locations instead of being tied to computer w/ microphone. Also they need to process each file they record, or rather at this point, I have to process each file they record, not an optimum solution. So yes, in the abstract the short term solution does make the files usable but is not the preferred solution.

Unfortunately, you are going to have continue the "try and see what happens" approach you've already been working with. <br> <br>The best starting point would be to recreate the same situation in your test environment (assuming you have one). This means having a system with the same OS, same Dialogic software, same TeleFlow software, the same version of your application(s), and the same card. (model, it MUST be a D4PCIUF, not just a D4PCIU) Do you have the ability to set something like this up, and/or have you already done so? (I was actually not entirely clear from your last post: I know the D4PCIU was discontinued, and the last time they were available was earlier this year. Have you been using the D4PCIU up until it was no longer available, and more recently moved to the "F" version, or have you been using the "F" successfully in your lab and/or customer sites?) <br> <br>Thinking ahead to other things we might try: <br>How remote is your customer, and what does this mean for trying things out? <br>(i.e. Would it be possible to swap their current "F" card for another "F" card? In particular, if you can test one in your lab, and it works properly, it would be an excellent test to see how it performs when placed in the system with the problem. That would probably be the most ideal way to isolate a problem with the card, if indeed that is the problem.)

Oh, one other thing to note: Although it STILL doesn't deal with the quality issues, you could use the "Run Program" step to launch a converter inside the TeleFlow application. Granted, this is not a preferred solution, but may help the process a little in the short term.

We have two teleflow servers in the office (integrated with our product, Voice Xpress). Both of them are running extremely similar hardware as the client in question, same OS, service pack, Teleflow version, Dialogic drivers, etc. One of them is a production server we host for a client and the other is our internal development/demo server. <br> <br>We pretty well build the servers (w/ Dialogic card) for the customers from stock parts. For the most part the largest change in the build make up has probably been the switch from D4PCIU to D4PCIUF. We have about 8 customers using the F card by now, without any problems. <br> <br>The client is in New York and we're in Vancouver (actually we're across the street from Engenic and have probably inadvertently shared lunch a few times). They have an IT resource but I'm unsure as to his competence when it comes to hardware change out; I was hoping for a more specific diagnostic before having to engage in cross country couriering of parts, just in case it was something wrong with the PC. Put another way, I was hoping to find out explicitly that yes, the Dialogic card is at fault and we need to replace it. Do you guys have any arcane Intel diags that we could try? <br> <br>As for the Run Program step I'm not sure what you mean; let them use the AudioConverter program? As it is I've made a batch file that will simply convert every .WAV in a directory to .VOX. I've another that will convert every .VOX to .WAV, increase the amplitue 200% three times, and then convert all the .VOX back to .WAV. From a time/effort perspective it's not a big deal but it certainly is from client's appreciation of our product point of view. <br> <br>- Thanks for the additional info!