Hi Compactus.
Right up my theory.
You are now using another internal Windows hub and a new interupt and so on…agree?
Hey, cka. yes that’s right.
Still not sure if that solved my realtime audio playback issues inside Cubase. Maybe not…
However, audio dropouts caused by using the browser are gone now. So that really has an impact.
Hi Folks,
For those of you that have yet to give up hope I have some news that I am able to share. I have received a new Prototype Yamaha Steinberg USB driver (Proto 1.11) for testing and can report the following:
- The Proto driver on minimum buffer setting (64 - 48kHz) works on an empty project - no VST peak light continuously on as was seen with all released driver after 1.9.6
- The Proto driver on minimum buffer setting works on my Spiky Test project - 4 VSTi with one armed track and my playing something
- The Proto driver on minimum buffer settings works on my Spiky Test project - 4 VSTi all armed and my playing something. The average load is quite high and the realtime meter is maxed out but it doesn’t trigger the Peak light nor is an audible distortion occuring
- The Proto driver on minimum buffer settings works on my real project, with video playback and with one armed VSTi for recording.
All my hardware is the same, the only thing that changed is the Proto driver (unless Windows 10 did an update without listing it).
I am still seeing significant spikes in realtime performance metering but overall the important thing to note is the UR44 now works on minimum buffer settings where it was unable to work at all previously. At 128 buffer setting, perhaps more realistic, the average load and realtime load are more like each other (sans the occasional spike in realtime).
Since trialling the Proto driver during a real world composing project I have had only 4 peak red lights on minimum buffer settings. All non-repeatable unfortunately - I have tried several times to repeat a realtime export peak I saw given its not reliant on my human playing so should be repeatable but it has succeed on all but that first occasion.
I’m currently trying to work out a more diagnostic test of performance on the new driver. If you have suggestions please let me know as Steinberg are being receptive to the detailed feedback. I have an i7 3770 and with Kontakt and Halion Sonic VSTi all playing exactly the same chord track (it sounds terrible!!) I get about 14 tracks of playback with one track armed before the AVERAGE load maxes out and things start to die. I am not at all sure this is good or bad performance, and it’s not particularly real as rarely in my actual projects do all VSTi activate at the same time on the same chord (and there is a definite real time spike from Kontakt Sessions String Pro when it plays the initial notes).
No release date on this yet, and no I can’t send it to you (sorry). I am very surprised this improvement has occurred and live in hope Yamaha Steinberg have actually found the underlying problem now and we can look forward to further optimisation and a return to the performance I enjoyed when I first purchased (Win7, Cubase7!).
Cheers,
Rob
hey Rob…thanks for sharing your info! i was going down to buy the MOTU tomorrow. MAybe ill hold off another week or 2.
my problem is not really about smaller buffer sizes. Regardless of the buffer size, regardless of the USB port, the $teinberg USB driver seems to “dump its guts” it seems at an interval of around 5 minutes. Its like theres some memory leak or a stack overflow or something, and it just craps out and everything goes silent for a second or two during playback in Cubase, then a stutter and playback recommences. After the first time it does this in Cubase, the peak meter red overload indicator can no longer be turned off by clicking on it. Well …you click on it and it returns back on within a split second, even with the green meter bar returned far away from it, down to around half level.
Ive tried just recording some vinyl to Sound Forge with the UR824. So nothing to do with Cubase. No plugins running in Sforge. Just a stereo file recording. Childs play. Listening in real-time through the unit, i dont hear a skip or silence in a vinyl transfer, but the subsequent recording in SF has a skip. Every 12" inch i transfer has a skip somewhere because of this crap. Again, it occurs every 5 mins from the previous time the USB driver decided to take a dump in its pants. So its not a specific Cubase issue. Its not some spiky plugin. Nothing to do with it. Its the lemon driver.
i tried rolling back the 824 firmware tonite to 1.5 (from 2.11). no diff. So its not a firmware issue.
thats interesting. I had the opposite. When i changed the Ur824 to a 3.0 or 3.1 port, all hell broke loose. Only way i can even try and get any work done is for it to be plugged into a 2.0 usb port without any other things plugged into any other 2.0 port.
Every pc sets up how the interrupts are assigned differently tho. It all depends on how Windows is feeling that day. And what else is plugged in, as to whether it “shares” interrupts or assigns a unique one. This is part of what makes nailing down problems like this such a minefield. So its very possible that interrupts are simply different for the ports in my PC to yours. But interrupt assignments and how the $teinberg USB buffers handle these may be a big part of the problem. Just at a guess
in desperation tonite i just downgraded the UR824 firmware to good ole V1.5 (theyre from July 13) and uninstalled all the drivers and went back to the old 1.5 drivers as well…
dropouts are gone!
Obviously a BIGG problem with the current drivers somewhere. Someone tried to be clever and “improve” them eh.
did this solve the problem for anyone else here or just me?
Hey guys,
after i received my new PC on tuesday, i had the same sound lag problems. i tried all tips to solve this issue without success. After a couple of hours of troubleshooting, i could fix it for my configuration:
I bought the new components for my PC seperately and installed Windows 10 manually:
Intel Core i5 7500
MSI B250M Pro-VDH
Ballistix Sport LT 16GB
Crucial MX300 275GB SSD
onboard graphics card
disabled sound adapter in BIOS
Microsoft Windows 10 Pro (version 10.0.15063; build 15063)
Steinberg UR22mkII latest firmware and driver.
ASIO driver only for pianoteq
Windows sound for youtube, amazon video, netflix…
I installed windows 10, the yamaha driver and some applications. Then i installed the driver package from MSI including latest intel chipset, realtek ethernet and realtek sound drivers.
After that i had sound lags every ~10seconds, especially in browser websites like youtube.
On the next day and a couple of hours reading this thread i format the whole system and reinstalled windows 10 again; this time just windows 10, all feature packs and updates and the yamaha driver. ==> everything was fine. No lags anymore. After installing my applications, the error did not come back.
In my opinion and on my system it must be a driver issue with intel chipset, realtek sound or realtek ethernet adapter. With the original chipset and ethernet drivers from windows 10 (Microsoft windows 10 DVD or windows 10 Update Server) the ur22mkII works fine.
Regards,
Sebastian
Rob,
I was just curious… I didn’t see it in your post but I was wondering if you had any dropouts using the Windows driver (not ASIO) such as when listening to the Media Player, etc.
J.L.
BOTH OF MY FRIGGING UR28M interfaces are gone screwed up. Input 2 does not work and 3 and 4 are very now… BOth Units…
I WANT A SOLUTION! SAME WITH THE UR44. I think you people screwed up big time…!
GIRO revert back to older drivers and see if the problem is fixed…
Rob,
I was just curious… I didn’t see it in your post but I was wondering if you had any dropouts using the Windows driver (not ASIO) such as when listening to the Media Player, etc.
J.L.
Hi
No, I’ve never had a problem with the UR44 under windows drivers, only with ASIO.
Cheers
Rob
You can’t revert the Firmware. (edit* Actually I can but nothing) The Unit was fine before the Firmware. I have USB Drivers 1.7.3 now and input 2 is dead on the UR28M and on the UR44 inputs 2-3-4 are also gone. gonna try 1.9.10 now which is taking forever to download.
My units are on Main V2.11 and Boot V2.11 dspMixFx V2.1.3
Seems like the firmware update has shut down all inputs but input 1
I just HOPE my UR824 is still working or I gonna flip big time!
I’m my MR816CSX now while trying to figure out all the nonsense on the USB UR series interfaces.
MR series hahaha still can’t have the frigging thing running at 400… I have it slow at 200 and it works…
I’m on Win7 64 by the way
GIRO i reverted my UR824 firmware. I just loaded the firmware installer, it said Firmware v2.11, i loaded the V1.5 and it just happily installed it into the UR824.
And the driver has confirmed it is now running V1.5 firmware.
(This might be different for a UR28M tho)
I actually did and was able to revert but to no end.
I’ve tried everything!
Thanks for posting!
Had this problem for ages and followed this thread (and the others).
Tried USB2 hub, tried USB3 hub, tried the 3 different USB hubs on mobo (front ports, rear ports etc.).
Tried USB2 ports, USB3 ports. Tried to disconnect all other USB devices, even keyboard and mouse.
Tried all different versions of Intel drives for the Asus X99 Pro mobo.
Tried all different versions of drivers for the UR-22 MKII.
Wasted more than 12 hours on troubleshooting and probably another 12 on listening for drop outs.
Countless days of aggrevation with this audio interface from hell.
Gave up and put up the UR22 MKII for sale now, will probably loose about 100EUR to get rid of it and get this unit out of my life.
Bought a Behringer XENYX UFX1604. Tought process beeing that it has USB and FW in case my USB controller etc. is the issue, I can try FW.
Hooked up with USB, played Spotify now for 5 hours with no dropouts. UR22 MKII had dropouts every 1-2 mins of 0.5-1.5sec.
Lesson: Never buy anything from Steinberg again, they are not willing to fix an issue that affects SO many users of the UR-series.
Maybe a comment from Steinberg would be nice?
As usual! Every Steinberg interface ends up dead. Since ever.
Yamaha mLan i88 dead - MI4 dead - MR816 series dead - Ci series dead - it’s very frustrating!
All of them plagued with bad drivers.
The only one I remember that was ok was the Nuendo Audiolink 96 which was actually RME with a Hammerhall PCI card.
I have not received any reply from my tech support ticket - already 4 days!
The Yamaha i88 isn’t a Steinberg interface 
The MR816 is based on the Firewire interface which isn’t exactly next gen technology and not really our fault that there are only few new systems out there that still support Firewire.
The Firewire driver supports all current operating systems, so I wouldn’t call it “dead”. The CI and UR are also not dead as both use the same Yamaha Steinberg USB driver which is still developed.
However, I understand where you are coming from and for everyone here in this thread, the current condition of the YSUSB driver must feel like it’s on the brink of being dead. To put it into perspective, there are tens of thousands customers who do not have those issues. But yes, I know, who cares if it does not work for you which it absolutely should!
As robw mentioned, the new driver that is currently in testing seems to be very promising and should improve the situation a lot. At this point, I do not know anything about a release schedule for the driver but we’ll let you know asap.
The US support team just recently lost two long time team members and they haven’t fully recovered yet. I assume that this is why a reply takes longer than usual.
WHen I say dead you know exactly what I mean boss and I know that the mLan is not Steinberg but it’s Yamaha I included it as a point of reference and to point out that all Yamaha interfaces are plagued with bad drivers since mLan till now with USB. Still to this day, we can’t run the MR816 at full speed, and switching sample rate is a pain. (it just hangs cycling for ever) but it’s still working there looking at me like “Don’t give up on me man” My UR824 Thank Heavens is still good after the updates. I use it for my mobile studio.
I’ve been around in this audio interface race for a long, long time dating back to running Cubase with a Soundblaster and I can tell you that and as usual, every Steinberg interface ends up dead (out of the race). Since ever. It’s very frustrating! All of them are plagued with bad drivers. I have used them all! The only one I remember that was ok was my Nuendo Audiolink 96 which was actually a breakout box RME with a Hammerhall PCI card. But back then we were plagued with IRQs… Aaah the good old days hahaha!
The UR series have a big problem. Other users have had same problems with the UR series of dropouts and inputs going bad after the firmware update. UR28M inputs go bad. UR44 same thing inputs 2-3-4 go bad. UR44 has a solution at best of fixing lost inputs. One of my clients was able to get it fixed as she boldly contacted Yamaha directly and demanded a fix and they did. 
All of my M-Audio Delta series interfaces worked back then. Even my FW18/14 never failed and I actually gave up on it as a result of blind loyalty to Steinberg and moved to Steinberg interfaces for the Pre-Amps. Why we have a UR824 interface with 16 adat and no UR D-PREs expansions?
I was hoping they would come up with a series of UR-D PRE expansions and never happen 
had to use other 3rd parties ugh!
I’m so disappointed and embarrassed at this point.
Using a UR22 MkII with a Win10 system on i5-7200 with 8GB of RAM and an SSL drive, which was dropping out every 10 minutes or so and popping continually when playing Ivory II live via Ableton, even with an intrusively large buffer …
Things that haven’t helped for me:
- Disabling WiFi (on its own);
- Updating the driver;
- Increasing the buffer size;
- Changing from USB 2.0 to USB 3.0 port;
- Powering the UR22 independently;
- Changing USB cable; and
- Connecting via a USB hub.
Things that have helped in a big way:
- Disabling Hyper-Threading;
- Disabling C-States;
- Disabling core parking; and
- Keeping WiFi disabled.
Popping problems very obviously fixed instantly with these changes, and no dropouts yet after two days’ use. Keeping fingers crossed that this is all now fixed for me, and experimenting with much lower buffer sizes. I made all the BIOS changes in one session, so I can’t say whether it was (for example) core parking alone that was causing the problem.
Thanks to Ed for collating all the possible fixes at the start of this thread … but really this sort of thing (if it can’t be fixed from the driver) should be in bold print on the first page of the installation manual! Enjoying the hardware though, and the more so now that it seems to be working properly …