+-125 ms latency adjustment not enough

Hi. I'm using Songsmith in a VMware Fusion virtual machine on a Mac, and VMware's audio interface seems to have so much latency that it can't be compensated for with the +-125 ms range available in the Microphone Configuration window's Recording Latency Adjustment setting. Aside from this latency thing, Songsmith is working just fine in the virtual machine. The operating system inside the VMware Fusion box is Windows XP Professional SP3, but I don't think it has anything to do with this. Is there any way to have more delay compensation than +-125 milliseconds? I need many times more than that. Maybe something like 500ms or even more.

This is a great suggestion, and we'll definitely think about doing this if we're able to do continued releases of Songsmith.  Unfortunately we weren't able to test extensively on Fusion configurations (just for lack of resources), but making Songsmith work well under Fusion or Parallels will definitely be a major focus if we're able to go back and make some major Songsmith revisions.

Thanks for the suggestion!

-Dan

Thanks for the answer. But let's pretend I never mentioned Fusion. It's irrelevant. Can you make the latency adjustment range larger without releasing a major version update? I also suffer from the bug with non 7 bit ASCII characters in my user name, so I had to create a new user just to be run Songsmith. I guess you're going to fix that, so why not fix the latency adjustment too while you're at it? :) I have to admit I already bought the product, so now I just can't use it. (I know you shouldn't buy software without trying, but I figured this is a simple Microsoft product so how could it not work...)

FYI we just released a fix for the issue with extended characters in user names.

I'm doing my best to pretend you never mentioned Fusion. :)  But... while it's conceptually irrelevant, we _never_ see a need for latency adjustment  higher than 100ms on any non-vm configurations (i.e. we only see this under some Fusions and Parallel installations), so it actually is somewhat relevant.

What we don't show in the mic config dialog is that this latency adjustment slider applies a correction ON TOP OF latency reported by the sound card itself.  I.e., when this is set at zero (the default), Songsmith is already compensating for latency that it computes based on timing information reported by the sound card.  So this isn't just a latency question, it's a question of the accuracy with which the (virtual) sound card reports timing information, so it is a more complex change than just extending the range on the slider.  Something we'll _definitely_ think about in even a "1.1" caliber release, but not something that's super-easy to address right now.

So while I don't have an easy fix for you, I will give you one thing you can play with a little and see if it helps... if you open the file called "mysongconfig.txt", try changing this line:

APPLY_LATENCY_CORRECTION_REESTIMATION 1

to:

APPLY_LATENCY_CORRECTION_REESTIMATION 0

This will change some things about the way Songsmith computes latency, and while I don't specifically know that this will help you, it's worth a try.  Note that I don't recommend touching this value unless you're having serious issues like the ones you're experiencing.

Let me know if that helps... feel free to drop me an e-mail (use the "contact" button up above) to talk about this a little more; while there might not be anything we can do, I'd like to have your information to help us work on this if we do end up with enough resources to address this issue.

Thanks!

-Dan

Thanks, now I understand why the latency compensation slider's range is so small. Unless the sound card drivers are reporting the latency incorrectly (which is apparently the case with VMware Fusion's virtual sound card), there shouldn't be a need for manual compensation. In practice, the reported latencies are very often incorrect. For example, the driver may only report the first level of buffering latency, when actually there are more things going on like the buffering needed for transfer over the Firewire or USB bus, or other internal components. The best manufacturers report everything as correctly as they can, and AFAIK some even try to include A/D conversion latency. Unfortunately, at least for some "professional" sound interfaces, incorrectly reporting drivers can even be a marketing thing. Many people just look at the latency value their drivers report and are happy with it, so the incorrect numbers make the card seem better. (until someone notices their recordings aren't timed quite right, or if they actually measure the latency with tools like Cubase's "ping" feature) \n (________what does one need to do to get a simple line break these days...) Anyway, I noticed that VMware is offering an update to Fusion 2.x for all 1.x customers, so I'll upgrade to that and see if it helps. I read that the newest version has some fixes for sound issues. If it doesn't help, I found out that there's a parameter "pciSound.playBuffer" that can be added to the virtual machine's VMX configuration file, so I'll just have to try decreasing the value to a range that can be compensated for with Songsmith's latency adjustment feature.

 Disabling the latency correction made it work for me! I now have to have it at +100 ms.

Yes indeed, disable latency compensation in mysongconfig.txt as explained by Dan above, and then adjust for the latency in Options / Microphone Configuration. The slider's value +100ms seems to be just about on the spot for me as well.

I even upgraded to VMware Fusion 2, but that didn't help at all. The correct recipe for VMware Fusion is, disable automatic latency compensation and set manual value to +100ms.

So thanks everybody, everything is fine now! I even figured out how to do newlines in this forum. ;) You need to use the HTML tag for new paragraph, i.e. the letter p in smaller-than/greater-than "brackets".

Glad to see that everything worked out here, and now we have a great tip for us to pass on to anyone else using Fusion.

Thanks for working through this with us!

-Dan