Latency, no monitoring

I just switched over to using Ardour on Windows 10 for the first time after using MacOSX. Having a few issues.

  1. No monitoring. When overdubbing vocals for instance, the singer cannot hear themselves while recording. If I set it to software monitoring, they can hear but with a slight delay. Hardware monitoring is quiet, but still records, but with the delay so the track is unusable.

  2. Latency. The delay described above.

I am using a Tascam 16x8 USB device. Latest firmware and drivers. Ardour 5.4 on both machines. I got fed up and went back to my Mac, no issues.


Also, brand new Dell Precision 5510. Quad i7, 24GB RAM. Fully patched Windows 10, BIOS, and drivers.

“Hardware monitoring” means that you arrange for an audio signal path (typically analog) for monitoring, typically by using a hardware specific utility to configure the internals of your audio interface to route from its own inputs to its own outputs without passing through the CPU. “Software monitoring” means that the signal flows to the CPU and thence into Ardour, which chooses to send it back out so that you can hear it.

Anytime the signal passes through the CPU, there must be latency. The amount is determined by the buffer size you choose to use - larger buffer sizes means more latency. The smallest buffer size you can use without issues gives the least latency, but the size is completely system dependent (hardware and software).

Right, and I have always used hardware monitoring setting on the Mac, Ardour came tat way be default. No different than the PC version. Using the same hardware, same settings, yet i get no latency, or at least no noticeable latency on the mac plus the monitoring works perfectly. Just curious what I may be able to try to get the PC to work as well as the Mac. Pretty much, its unusable on the PC because when it records, the audio does not line up with the rest of the track when played back. This is not an issue on the mac.

I should also clarify, I can hear everything else playback when using hardware monitoring, just not the active record track. And even if I go ahead and sing anyway, it still lays the track delayed. Once again not an issue on the Mac, just not sure where to look to fix. Settings identical both in Ardour and on hardware control panel for both platforms.

Did you install the latest windows driver for the device ? On Tascam site they say that windows 10 is only supported on driver version 1.03 and newer.

This device has no analog “Zero Latency Monitoring”. The monitoring function on US-16x08 seems to depend on a DSP mixer that needs os specific drivers / software. This means the device becomes obsolete when the manufacturer stops releasing drivers / software for new os versions. When this happens you lose low latency monitoring just as you described. But maybe you just did not install all needed software, since win10 is supported.

Yes, but I am really starting to think about ditching this PC idea. Countless performance issues since trying to use Windows. Not sure why a brand new powerhouse laptop is so incredible worse for this task than a 6 year old MacBook Pro.

I know what you are talking about :slight_smile: My experience with 21 years with windows, 12 years with OS X and 16 years with Linux puts windows at the bottom of the list. It is not all microsofts fault however, it must be incredibly difficult to support hundreds of differently put together systems. Some of it is nobody elses but microsofts fault, for example there is no other platform with “bitrot”, meaning the pc becomes slower and slower as months goes by.

Macs tend to work well and serve 5 - 7 years without any problems, hardware or software as long as you wait at least 6 months before upgrading to the new major os version after it’s release.

I use Macs at work and Linux at home.

Not trying to start any flamewars here. I hope I did not offend anybody. This is just my experience with these platforms, somebody else might have had better luck :slight_smile:

Absolutely no offense to anyone, just really curious objectively why the performance of all this is so drastically different even though my hardware is way beyond what should be capable for this project, and way beyond my Mac’s specifications. From day 1 using Ardour over a year ago on a 2011 Macbook, zero issues with performance and easy as pie to start producing music. Using Windows for a few weeks and it’s been nothing but challenges every step of the way, and that is just with mixing! I couldn’t even get to tracking on my PC as the latency was impossible to work with. Top all this off with my own naivety on the world of Audio DAW software architectures/software/configurations/etc, it is just getting frustrating and time consuming trying to figure it out. I hate to say it and be a cliche, but on the Mac, it just worked.

Maybe I should dual boot Ubuntu on this machine and see if it makes a difference? I would like to find to a solution for all of this in the case my mac ever dies completely.

Ardour developers won’t give official support to windows yet. WIndows is a quite a recent addition to Ardour platforms and because of this support is not as mature as for OS X and Linux.

If you want to try Linux with Ardour on your pc, please do not use common Linux distros, as the Linux system must be configured to support real time audio and generic Linux distros don’t do this.

There are two audio specific distros that are often mentioned here on the forums: KXStudio and AVLinux. Both are correctly configured for real time audio out of the box and also have many useful tools included.

As far as I know both can be booted and run from a USB stick for testing without installing.

Excellent! Thanks for those links, I will make a bootable USB and check it all out. Interesting insight on Windows too, I think I will just head back over to my Mac in the meantime.

@guitman423: more reading:

Put another way (which ought to be made more clear in that document): latency performance/capabilities have almost nothing whatsoever to do with CPU speed, or RAM size or speed, or any of the normal metrics used to define "a fast powerful computer".

Just for an update to this issue, my latency issues are fixed by adjusting the buffer size of my USB audio hardware. 128 buffer size fixed my issues with recording latency while tracking, >512 fixed my issue with DSP overload while mixing.

Thanks to user x42 for this comment in another thread, the video was incredibly helpful: explains DSP-load (realtime performances) vs CPU load/performance in layman terms very well.

Still having very slight latency issues. Had to go down to 64 sample buffer size in my audio hardware for it to be acceptable.

I noticed that this sample buffer size setting on my hardware is only for Windows, as indicated on page 14 of the owners manual:

“Set the buffer size (latency) in the audio application that you
are using or in this unit’s Settings Panel to a larger value.
(Windows only)”

Once again this was never a setting I had to mess with on my Mac, never any noticeable latency, yet on Windows I have really had to adjust this setting way down to get it to work. Anyone have insight as to what the differences in architectures are and why this is a setting for Windows only? Does OSX not use buffers for devices like this?

On Windows, with the ASIO driver, individual applications are not supposed to set the buffer size - that is supposed to be done by the user using the device specific control panel.

On OS X and Linux, applications specify the buffer size they want to use.

So in the case for Ardour on Mac, Ardour sets the buffer size? Curious what that buffer size is on the Mac, is there a default, or a way to see what the application has chosen while the application is launched?

You, the user, get to set the buffer size. It is one of the parameters in the Audio/MIDI setup dialog that you see whenever you start Ardour (that can also be accessed via Windows > Audio/MIDI Setup).

If you use JACK, then you’re actually setting the buffer size that JACK will use; all JACK clients will use this too. If you use Ardour’s CoreAudio backend, you’re setting the actual CoreAudio backend which is closely related (but not identical to) a device buffer size (on OS X, nothing controls this; the device driver architecture of CoreAudio just doesn’t work that way).

Ardour will continue to re-use your previous settings until you change them.