It should work better, but I don’t think the console device has jitter buffering by default, so it may still be subject to network jitter. I think you may be able to turn on jitter buffering, but, in general, the console device is not intended for serious use, except possible to driver a paging speaker. For a fair test, you should use two SIP phones.
Sorry. I had forgotten the details of the sample configuration. If you are just listening to the internal recordings, rather than making the test call to Digium, or to a local SIP phone, the problem is either due to running on avirtual machine on a loaded hsot, or because you haven’t got a properly configured timing source (I’m not sure, but the console device may provide a good enough timing source).
Please search on timing sources, as the options are changing at the moment. for 1.6, you would generally want dahdi_dummy and to have internal timing enabled in asterisk.conf, but as noted, the console device might not need this.
Note 1.4 is not reccommended for new installations. 1.8.x is the stable series with the longest support.
I think the ability to run Asterisk on a VM depends on what else is on the VM. If the host is configured to give enough resources to the Asterisk VM, you may be OK, especially with real SIP phones, which will have good jitter buffering.
If it is heavily loaded, you will get broken up speech, even with real SIP phones. We get this problem when we try to development test on VMs. Hopefully a production VM would be on a system that was carefully dimensioned.
The other risk with development testing on a VM is that you are much more likely to only gain access to only one processor core, so you are much less likely to find one of the many race conditions in Asterisk.