M2/M4 delay in going "beep" in Windows.

[Renate]

I bought a M2. It's my main (only) audio interface and goes to stereo speakers and takes in mic/guitar.

The main purpose was mostly to send songs to friends. I tested it, it did that. But it was also intended as general purpose Windows output, radio, video, whatever.

After a while I noticed that when a popup appeared ("Do you really want to replace this file?") there was a delay before a Windows system beep came out the speakers. I didn't think about it much. I was working on learning Morse code (why???) and wrote a trainer program. It played short audio clips. This previously noted delay made the trainer program completely balky. So I dived in with my much-beloved TotalPhase Beagle USB480 protocol analyzer. This started a long saga and a support ticket by Motu.

If you decide (out of the blue) to play an audio clip on an M2/M4 the first thing that happens is that they start up a PLL (phase-locked loop) for the audio clock inside the M2/M4. Then they sit around for 60 milliseconds waiting for the PLL to stabilize. Next, because they are running the audio isochronous asynchronous to the USB bus using the IN endpoint as an implicit feedback endpoint they start "recording". Ok, this is all tech details, but the short of it is they can not play without "recording". The recording does not go anywhere. But, the killer is that they "record" for 340 mS before they even start to play a sound. Then they play/record for the length of the audio clip, then they continue recording for 2 seconds in case you want to play another clip. The upshot of all this is that if you want to beep you'll have to wait a total of 0.4 seconds.

So, I butted heads with Motu and the upshot is, "Yeah, that's the way it is." I pointed out one (very trivial, unrelated) error that they had made and they acknowledged it and said that they'd change that.

I can't believe in all the due dilligence and reviews I read about this unit before buying that no one had noticed this. Have you noticed this? Or do you always use this only with a DAW app where it's "recording" (for the meters) all the time?

[bayswater]

I’d guess short bursts of audio is a use case no one thought of in the test plan.

[Renate]

I’d guess short bursts of audio is a use case no one thought of in the test plan.

It's not the length of audio that matters.
You can't play anything without a 0.4 second delay.

[bayswater]

I’d guess short bursts of audio is a use case no one thought of in the test plan.

It's not the length of audio that matters.
You can't play anything without a 0.4 second delay.

Don’t understand. If I play a guitar through any of my interfaces through DP with a low latency I can tell there is some delay but nothing like 400 msec. Are you saying that is not the case for a M2? Or that when you first fire it up you have to wait 400 msec for it to start working? Or when you play a video, the audio is 400 msec after the video? I read you earlier description but it implies there is an initial starting delay but not an ongoing latency.

[Renate]

If you are using something that "records" you will not see any delay.
That could be a DAW or VU meter or anything using the audio.

If you are using your M2/M4 as your normal Windows playback device and with no audio application running and you hit a "bad" key in any application or try to overwrite a file in any application the audio "error sound" will occur 0.4 seconds after you see the popup.

[James Steele]

This sounds like something that most users aren't going to run up against in normal DAW use? Sounds like you wrote a custom app for learning Morse code and you have maybe two audio files it alternates between? A short beep for a "dit" and a long beep for a "dah?" Hate to suggest it, but maybe if that's what you're doing you need 26+ different audio files? One for each letter (and other characters if there is such a thing)?

Probably it hasn't been reported because, again, most DAW users won't run up against this and they're not writing a specialized app so that an error beep that plays 400 ms. late isn't much of a problem?

[Renate]

This sounds like something that most users aren't going to run up against in normal DAW use?

No, this is something that any Windows user will run into.
If you're in any app and do something that will cause any popup error that makes Window beep you'll see this delay.
You probably thought that your system was overloaded or something.

It's trivial to check. Just check.
Use your text editor and try to save a new bit of text over an existing file.
It will have a popup saying "blah-blah already exists, do you want to replace it?"
Since the default is "No" you can just hit enter. Hitting enter again will try to save it all over again.
So you can just hit enter repeatedly and it will pop up every other time.

If you have no audio applications running you'll see the delay.
If you have your DAW running you won't see the delay.

[CharlzS]

Windows audio and drivers are problematic in many ways. If you want to try something different, turn Windows sounds off in the Sound Control Panel and use the flash display for sound notifications in Accessibility. I've been running this way for a while and it gives you the instant notification visually. Particulary helpful when using your audio interface multi-client for both your DAW and Windows.

[Renate]

If you want to try something different, turn Windows sounds off in the Sound Control Panel and use the flash display for sound notifications in Accessibility.

Err, that's an interesting suggestion, but not really a solution.

I'm just trying to point out a problem with Motu's approach to audio.
Considering that they've acknowledged it I don't see why it's difficult for others to see and acknowledge it.
The (halfway) solutions are:

• Always run a DAW app that is keeping the audio interface running all the time
• Use a different audio interface and speakers for Windows system sounds
• Turn off Windows system sounds (as above).
• Try to ignore the balkiness of the delay
• Buy a non-Motu audio interface

On quite a different theme, I have the beeps for CapsLock turned off in the Keyboard settings.
My custom volume knob on my desk edge has a tiny speaker in it that monitors keyboard locks and beeps (quietly).