nchtj

the wav file you are converting from is using a codec that is not installed on your machine. if you like, try to open the file in notepad (it may take 30 secs or so) , and then copy and paste the first couple of lines into a post, and I'll see what codec it needs.

well the possible problem there is you converted the songs to mp3 format, which is not very useful if you want to burn them to a music cd. music cd files are in wav PCM 44.1kHz 16 bit stereo format, and even if you converted them to mp3, they would get converted back to wav format when burning to cd. so try converting to that format instead of .mp3 and see if its any better. you may have originally recorded your 78s in that format anyway, so chances are you may not have to do anything other than burn to cd.

can you play them in real player? because i just tried a .ram file from that site now and it works fine for me in both realplayer AND switch. just load the .ram file in switch, and convert it. realplayer files do take a little longer to convert, so be prepared to wait a little longer.

the next version will allow you to configure a base folder tree through the output folder text box, so we're sticking with the current system.

unfortunately not, we can only handle what windows natively allows us to handle via the command line, and at the moment its "PCM8", "PCM16", "ALAW" and "MULAW". we're always happy to investigate things again though, maybe MS has extended their wav support.

my (limited) understanding (as the windows developer) was that flip4mac worked independently of the software products that used it. what it does is it extends quicktime to support wma, and since Switch uses quicktime for decoding then Switch immediately gets the wma support too. we think we've identified what is causing the component install problem anyway, and we are currently testing mac switch in preparation for a new release.

a suggestion is to try our soundtap software to record the files as you play them. (www.nch.com.au/soundtap)

do you want to be a beta tester when the next switch goes into beta phase ? if so, send me an email at ... and I will notify you when the time comes.

sorry no.

thats quite a fascinating find there, good research. Just to clarify some things, Express Talk uses the UDP protocol for all its call signaling and the RTP protocol for the audio data. These two protocols are designed to work independently of whether the network connection used is wireless or wired, and there are no specific techniques (that we know of) for making one type of connection work better than another. The fact that you were only getting Express Talk crashing and not other softphones appears to me as being just pure "bad luck". Glad to hear the driver upgrade fixed it though, that confirms what I just said.

For any customization requests for Express Talk, please go to the customizations page and fill in the form.

we will have a further look at this, thank you for the SIP log.

are you using Axon here? Broadvoice doesn't work too well unless Axon is "in the picture". See here: http://www.nch.com.au/phone/sipinfo/broadvoice.html . There have been lots of issues with the Broadvoice servers in the past, but we will continue to work with them if new issues are raised.

1) The audio wizard is for verifying your audio hardware works, it does not test audio across your network or the Internet. 2) If you run an Ethereal trace on your laptop, see it picks up the RTP audio packets from the hard phone. If not, that would imply the RTP is not getting to the laptop and it getting lost/blocked somewhere along the line. 3) Check your laptop's firewall settings and ensure ports 8000-8010 are open for incoming UDP data. 4) Also try enabling SIP logging in Talk by going to Settings -> Network -> "SIP Messaging" box. Enable the log RTP option too. Make a call and check the logs and see if it logs any RTP. If not, that confirms it did not receive any audio.

Unfortunately we only have tested the Intercom feature with Axon and cannot give support for its use with other PBXs (the Intercom feature does not follow an open standard and therefore is not intended to work with other products). Having said that, are you sure your port 8000 is not blocked? If you run an Ethereal trace on your PC where you get no audio, does it pick up the RTP packets ? if not, that means they aren't getting there, somewhere along the line they are being blocked.

In theory any service works, but some providers have problems with their servers that creates conflicts with out software. What is it about the Faktortel service in Express Talk that doesn't work for you ?

1) if you shut down your firewall, you haven't disabled it, firewalls remain active always regardless of whether they are on or off. You either have to configure it to "Allow All" data or uninstall them completely. 2) Try changing the RTP port in Settings -> Network to something other than 8000. 3) Try going to a site like "Shields UP" (google it) and get it to probe your port 8000 and see what it says. 4) Registration happens on port 5060, and call making/receiving happens on that port too, so we can assume your port 5060 is open. Only the audio itself happens on 8000.

if your VoIP provider is broadvoice or vonage (or someone using a similar type of server), their servers goes crazy when our software call polls them during a call and they disconnect the call as a result (our call polls happen every minute, so that is why you get the one minute dropout). You will have to install Axon on your PC and setup your SIP line there and check "Disable call polling" in the Advanced Line Settings". (www.nch.com.au/pbx)

explicity specifiy the private IP of your Asterisk PC in the "Server" field for your Line config and that should work. Also try turning off STUN and uPnP in Settings -> Network tab.

this bug has been confirmed, thank you for your report, it will be fixed for the next release. The ringer call timeout is currently 25 seconds - do you need longer than that? We will consider a "USB-friendly" version of Talk, no promises of course.

send me an email and I will arrange to get a diagnostic out to you. my current theory is that when your XP SP2 sends out a DNS SRV request to your router, the router is very slow to respond or is timing out on the response. I've seen this happen before, which is why I am thinking this. A diagnostic will verify this though.

not currently no, but your idea is good and I will note it down for the next release of Talk.

this is a very strange problem indeed, I would have said its a memory problem myself, but you appear to have eliminated the memory already.

I have no idea what that is, it certainly isn't programmed into the software. It's probably generated by the other end.

the underlying issue is that there is no real standardization of USB phones, and therefore we have no idea what will and won't work with our software. The only reason our recommended one works at all is because we wrote a driver for it.