Haha, “…an itsa really nicah!” 
1 Like
3 Likes
How can anyone postulate that the German work ethic is too serious, not that any other Anglo tribe can beat them on efficiency or innovation.
It’s well known, for example that Mr. Trump, in the US, is rather envious of German industrial achievements, as has at least one trade minister from the UK, noting that they would love to have an industrial relations system, anywhere near as good as that of Germanys’.
The fact is, we would likely all be using Macs, were it not for Steinberg, which would put the DAW out of reach of many and while there may have been a great number of issues, with x86/x64, over the years, we can all hope for a better, more compatible future where Macs’ and PC’s, can exist side-by-side.
Yes, that! Moreover competition is a major innovative force and both worlds inspire one another. It doesn’t matter if you lean more towards Win or Mac - it’s a win win situation.
Peace out
Addendum: And I love the occasional side blow against … okay, I behave and say Wac 
1 Like
I have two keyboards: a Roland Fantom and an Arturia Keylab MKII. Neither have drivers for my Surface Pro 11. I also have a Steinberg UR22 MKII. With the UR22, I am able to use MIDI cables and connect my Roland and Arturia. For software I mostly use Arturia’s V Collection and Pianoteq, neither of which have native ARM compiled versions.
Currently, I can get both to work, but it seems like there is lag and I play 99% live rather than make songs that play by themselves, which I would probably just use my Fantom for if I did. Does any of this new MIDI 2.0 stuff help my situation with lack of drivers and Arm-compiled software? I am hoping it is at least “if you build it, they will come scenario” so eventually Roland and Arturia will step up to the plate and support my Surface Pro 11.
Depends on where your lag is.
Are you using the correct driver for the UR22? If you are using the general Steinberg ASIO driver, you’re using an ASIO4All-type of solution and so will see higher audio latency.
For MIDI: With MIDI 1.0, a note on messages takes 1ms to transmit across the wire. That’s been pretty consistent whether the device is USB or DIN-connected, because of how many devices stick to the original protocol speeds when they expose any DIN ports.
So my gut here says your audio lag is likely due to using a sub-optimal driver for the audio interface.
Pete
Microsoft
1 Like
Thank you Pete. Admittedly I haven’t tried this since July apparently, but I used the beta driver from here: Yamaha Steinberg USB Driver Updates and Downloads | Steinberg It appears that there is a much newer driver there. Is that the one I should be using?
Edit: After seeing the FAQ at the above link, it makes more sense now. I need to select the “Yamaha Steinberg USB driver” instead of the Steinberg ASIO driver when selecting where to send the sound. I will give it a try…
1 Like
Success! Thanks Pete! I downloaded the latest version of the driver and the latest version of Pianoteq. At first, I tried Audio Device Type: Windows Audio. I found that if I set the control panel to 192KHz, I could get the lowest ms rating in Pianoteq of around 4 ms depending on how many samples I chose. It was better than in the past, but still a bit sluggish. I felt like I was waiting for the sound when I was playing and it was tiresome. Then I tried Windows Audio Low Latency mode and it seemed a little better, but not perfect. Then I tried Windows Audio Exclusive Mode and it souinded terrible. Then I tried Direct Sound and it was very laggy. Finally I tried ASIO and it listed it as Yamaha Steinberg USB ASIO and there was only the Sample Rate that I could change, but not the milliseconds. At 192Khz, it uses 2048 samples and lists 10.7 ms. If I choose others, it is still around 10ms. Well, using this ASIO mode, the sluggishness vanished, and I can totally play now without lag. I am not sure if this is what you were recommending, but it seems to work the best for me. Thanks again!
Yes. the Yamaha Steinberg driver for their hardware is what you want to use. I couldn’t recall the exact name, but I know the names of the drivers in the Steinberg download assistant can be a little confusing.
I found that if I set the control panel to 192KHz, I could get the lowest ms rating in Pianoteq of around 4 ms depending on how many samples I chose. It was better than in the past, but still a bit sluggish.
Not sure where the 4ms came from, but for sure, humans cannot feel 4ms of audio latency (I’ll fight anyone who says otherwise ) the equivalent of standing apx 4’ from a speaker, and I wouldn’t expect our in-box solutions to offer latency that low in most cases. So that seems misreported to me.
Some players can feel a 11ms latency, depending upon instrument and style. I wouldn’t play with a buffer that high, but I also don’t use 192khz.
Then there’s ASIOguard and other bits in Cubase which may impact the overall latency.
But glad you got it working well in the end 
Pete
Microsoft
Thanks again Pete. I may play some more with what frequency I use, but the good news is it seems to be acceptable now in my limited testing. I was originally thinking that the Prism emulation was causing the lag. I am glad that is not the case. I totally don’t trust the 4ms rating because I think that is just part of the puzzle. Using Direct Sound is way laggier for example with 4ms than Windows Sound is, and ASIO with 10ms is less than Windows Sound is with 4ms. In case you are curious, you can download Pianoteq from Modartt for free. It is just time limited and some of the keys don’t work while in demo mode.
I am very happy that I have a working solution now thanks to you, Steinberg and my luckily already owned UR22, but I still hope that Roland and Arturia provide drivers for their keyboard products some day for the new Microsoft Surface users so I don’t need to use the UR22. It would also be nice to have Arm compiled software for the best efficiency. Maybe if there was a compatibility page somewhere, there could be a list of companies on the “compatible” side, and a list of companies on the “not yet available” or “requires a UR22 because they don’t have drivers” side, so they get called out for not supporting their customers. I am only half kidding.
Thanks again!
1 Like
There are some compatibility lists out there.
I helped Sweetwater with their Arm64 guides, but they maintain the actual compat list. KVR also has a compatibility list. Both are linked in my post above.
For hardware, the following devices have Arm64 drivers today:
- Steinberg/Yamaha USB interfaces
- RME USB interfaces
- Audient USB interfaces
- Fluid Audio USB interfaces
Focusrite will have their native drivers and apps soon, and we’ll have a native in-box driver near the end of the year +/-, with previews ahead of that. Just like on macOS, vendor-specific drivers can often get you a little more performance for a specific device, but our in-box driver will handle the most devices and so vendor-specific drivers won’t be needed every time like they are today.
Pete
Microsoft
2 Likes
Thanks Pete. That sounds really great, but how can you make a driver that just works with unknown/different hardware? Like will my Arturia and Roland just work? My Roland for example has multiple audio output devices when you plug in the USB cable and install the Roland driver (Main out, Sub Out, etc.). The only thing I could think of would be to have a driver wrapper or something similar to Prism where it knows what to do with x86 drivers and translates them to Arm.
Edit: Just read your linked post. It is full of great information. Sounds like as long as my Roland is built with USB Audio Class 2 , I might be good to go. Great work! I am not sure about the MIDI side, but perhaps it is similar.
There’s a USB Audio Class 2 (UAC2) standard which most USB audio devices implement. It’s what allows them to work on macOS, or your tablet, or your phone without any sort of driver.
Our current USB Audio Class 2 driver in Windows is optimized only for consumer scenarios. It has a minimum 10ms latency, typically, and doesn’t support all the channels of IO that are in the standard.
The standard dictates how devices should report things like their number of channels and the use of those channels, sample rates, etc.
The new driver is for any UAC2 device, and includes both Windows (WaveRT) and ASIO interfaces so that we can have the best of everything.
I actually have a pile of devices here at the moment (and more on the way) that I will be testing with an early build of the driver later this week. Some of these devices have never had a proper ASIO driver in Windows, with their developers cutting costs by telling customers to use ASIO4All. Nevertheless, they are class-compliant, and will work with the new driver.
Edit: Just saw your update.
MIDI: yes, there is a USB MIDI Class 1.0 and also a USB MIDI Class 2.0 driver standard. Our in-box drivers will support both (MIDI 1.0 is in there today, MIDI 2.0 is in Windows Insider preview builds). The only reason many vendors provide their own drivers today is because our MIDI stack has not supported more than one connection to a device in the past. In the new stack, we support that (called “multi-client”) so third-party drivers are very rarely needed. In fact, you’ll often have a better experience by not installing them.
Pete
Microsoft
1 Like
That sounds awesome and exciting! How about the MIDI side of things? Will it work with that too, like for keyboards, etc.?
Edit: lol just saw your edit too. Thanks! Sounds like there are great things coming that we really look forward to! Much appreciated.
1 Like
Here’s the breakdown of this list you see, currently attached to my desktop PC. This is using the MIDI console that ships with Windows MIDI Services.
- BomeBox (all three) : Network MIDI 2.0 preview transport
- ContinuuMini: USB MIDI 1.0
- Default Loopback A/B : Software-defined loopback through our MIDI Settings app
- ESI M8U: USB MIDI 1.0
- Waldorf Iridium: USB MIDI 2.0
- Montage M: USB MIDI 2.0
- MOTU: USB MIDI 1.0 with their own proprietary driver
- MRCC: USB MIDI 1.0, but using our new driver for even better performance
- Moog One: Same as MRCC
- UM-ONE: USB MIDI 1.0 using Roland’s own driver (our in-box driver works as well)
- WARBL: USB MIDI 1.0. We’ll have BLE in the future, but not for a bit.
- nanoKEY Fold: USB MIDI 1.0 using our own in-box driver, not the Korg driver.
I also have a box with a ton of USB MIDI → DIN interfaces since they’re all a little different. At some points, I’ve had enough USB devices attached to this PC to max out the Intel controller 
Edit: In case command-line is not your thing
Pete
Microsoft
1 Like
That is awesome. It reminds me of a Youtube video I just watched from Linus Tech Tips called “How many USBs can you plug in at once”. I have a Roland UM-One and a few other devices like that. Let me know if you want me to test my Roland Fantom and Arturia Keylab whenever you are ready. Good times ahead!
It’s enough if you have a Steinberg Midex-8 and you make sure, that one will work. I presume to be speaking for all of humanity. 
Well, the midex isn’t class-compliant, and the drivers are unsupported, but some people have gotten it to work on Windows 10.
If you can get the drivers installed and working on Windows 11, and the device is visible via the WinMM API (“Windows MIDI”) chances are very high that it will work with the new stack. But because it isn’t class-compliant (the USB MIDI class didn’t come out until late 90s, and took a while to catch on), there’s nothing special we can do to support it if not.
I don’t have one around here, so can’t give you a definitive answer, unfortunately.
Edit: Oh, and because I lost context when responding: if you’re talking Arm64, then no, this device will not work on Arm64 because there is no native driver available.
Pete
Microsoft
I get lag, sometimes due to a “weak” chipset, as I believe, which means when saving, playback stops.
If, by the time WoA, becomes a complete system; it would be great if the timing could be made such that while saving, if audio is unable to be played back consistently, that it should remain in time, as if it was so that when playback recommences, everything is still in time and can be played along with, using for example acoustic (non-DAW based) instruments.
Any word about MOTU? I’ve got various MOTU interfaces in the studio I’d love to use on ARM64 at some point. 
BTW, it’s very nice to see Audient support Arm64 so soon… that actually surprises me they beat MOTU TBH. Audient’s drivers haven’t been known to be the best in the past, but this is a good sign. Maybe they’ve dedicated more resources to driver development lately? The iD48 looks nice. That might influence my decision over my next interface. (I actually need another one soon, and the new MOTU 828 (2024) and Audient iD48 both look like good candidates. Maybe that pushes me to Audient…)
How flexible and feature-rich will the in-box driver be? Not much needed for a basic i/o, of course, but some of these more complex multi-i/o boxes have tons of features (mixing, routing, loopback, DSP, etc.)… So will the MS in-box driver just present those interfaces as straight up simple i/o like class compliant devices appear on MacOS and Linux? Or will there be any extra flexibility, routing, aggregation, performance settings, etc., etc.?
If the in-box driver will be on simpler side, that’s fine, I understand that, but it also underscores the need for these developers to keep working on developing Arm64 native drivers for their higher-end interfaces! (And therefore, in your outreach to developers, may I suggest you please urge MOTU to get on board the Arm64 train?)
Thanks for all your work, @Psychlist1972 – please keep us updated. Lots of neat tech on the horizon!