The following collection of videos demonstrates the sources/bugs of performance issues like glitches and drop-outs in Live 7 (with some comparisons to Live 6, which comes with its own share of bugs).
Each video has a maximum length of 5 minutes and plays at full crystal-clear resolution plus sound (with some degradation due to compression).
The motivation behind these videos is to help Ableton get a hold on the bugs that make Live performing sub-standard and even crashing regulary. Until those bugs are eradicated the videos should also help users to avoid certain actions in Live (like starting Scenes with lots of outgoing Midi data).
No devices were connected to any of the Midi ports during the tests, so the source of the problems are not bandwidth limitations of the old-school serial Midi protocol.
Video 1 - Live 7.02 Beta 3 (click to watch in browser ->): Introduction to Setup & Bugs
This introduces the test-setup and how Live's performance is considerably affected by sending Midi data out. Notice how starting Scenes leads to more drop-outs than starting clips even when the ammount of data does not change. You can also observe how the maximum number of outgoing Midi events is proportional to the audio-cards Audio buffers/samples eventhough CPU load is well below 20% all the time (except for where tracks where copied, which eats alot of CPU).
Stay tuned! Video 3 (Live 6.10 Midi performance) and 4 (Plugin Buffer issues in Live 6 and 7) will follow tomorrow or by friday.
Videos: Sources of Performance Issues in Live 7
Videos: Sources of Performance Issues in Live 7
Last edited by Timur on Thu Jan 24, 2008 9:45 am, edited 2 times in total.
Video 2 - Live 7.02 Beta 3: Influence of GUI on Performance, Audio Sloooowdown
This demonstrates how GUI elements like Volume Meters and I/O controls can influence performance even when CPU load is low. You can also witness the dreaded audio slooooowdown that happens when Live's engine gets into trouble. Last but not least you can see how switching Multiprocessor Support on/off has no influence on the issues beside changing Live's CPU meter output (while the real CPU load stays the same). The Video ends with a crash!
This demonstrates how GUI elements like Volume Meters and I/O controls can influence performance even when CPU load is low. You can also witness the dreaded audio slooooowdown that happens when Live's engine gets into trouble. Last but not least you can see how switching Multiprocessor Support on/off has no influence on the issues beside changing Live's CPU meter output (while the real CPU load stays the same). The Video ends with a crash!
-
dave dominey
- Posts: 514
- Joined: Thu Apr 29, 2004 4:11 pm
-
Machinesworking
- Posts: 11551
- Joined: Wed Jun 23, 2004 9:30 pm
- Location: Seattle
Does C.... stand for CPU? What is Leer Laufprozess? it seems to eat up C... as much as Live??
I'm on a Mac and i don't think this specific issue is affecting me, but unfortunately the first thing to do since I'm aware of you extensive testing etc. is to see if a driver is the problem, meaning uninstall MAudio, and NI drivers etc. try try the test on a machines with no third party driver software.
Also, just a suggestion, and you probably have good reasons that these videos don't show it, but once you get failure, audio cracking up, no bass sound etc. if you could remove tracks until the audio clears up, if that's possible....
off to work....>
I'm on a Mac and i don't think this specific issue is affecting me, but unfortunately the first thing to do since I'm aware of you extensive testing etc. is to see if a driver is the problem, meaning uninstall MAudio, and NI drivers etc. try try the test on a machines with no third party driver software.
Also, just a suggestion, and you probably have good reasons that these videos don't show it, but once you get failure, audio cracking up, no bass sound etc. if you could remove tracks until the audio clears up, if that's possible....
off to work....>
Just a few notes.
The task manger is not a good measuring tools for audio performance. You need at least a tool that show the usage for each thread. Almost the same is valid true for the audio usage display of Live. What you cant see there are the peaks which again are responsible for the audio drop-outs you can hear.
It is true, sending many (several hundreds or more) MIDI notes through a MIDI port at the same time will lead to audio drop outs. But that's the case for all previous Live versions too.
What would be interesting is to know if there's a certain Live set that produces drop-outs in Live 7 but not in Live 6 (both version with the same setup of course).
Another question is the one for a real scenario concerning the maximal number of MIDI notes sent out via an MIDI port.
Regards,
/Alex
The task manger is not a good measuring tools for audio performance. You need at least a tool that show the usage for each thread. Almost the same is valid true for the audio usage display of Live. What you cant see there are the peaks which again are responsible for the audio drop-outs you can hear.
It is true, sending many (several hundreds or more) MIDI notes through a MIDI port at the same time will lead to audio drop outs. But that's the case for all previous Live versions too.
What would be interesting is to know if there's a certain Live set that produces drop-outs in Live 7 but not in Live 6 (both version with the same setup of course).
Another question is the one for a real scenario concerning the maximal number of MIDI notes sent out via an MIDI port.
Regards,
/Alex
Yes, that's CPU load, and "Leerlaufprozess" is the Idle-Process which I left right there to demonstrate that my CPU is still running idle time.Machinesworking wrote:Does C.... stand for CPU? What is Leer Laufprozess? it seems to eat up C... as much as Live??
Since I ran all test with three difference audio-interfaces I am quite positive that it is not a (sole) driver-issue. The performance of the three interfaces differs considerably with these tests (different ammount of Midi tracks can be played concurrently), but the general outcome is the same.I'm on a Mac and i don't think this specific issue is affecting me, but unfortunately the first thing to do since I'm aware of you extensive testing etc. is to see if a driver is the problem, meaning uninstall MAudio, and NI drivers etc. try try the test on a machines with no third party driver software.
I'm confused. Did you watch Video 1 to the end?Also, just a suggestion, and you probably have good reasons that these videos don't show it, but once you get failure, audio cracking up, no bass sound etc. if you could remove tracks until the audio clears up, if that's possible....
off to work....>
It does just that, delete Midi tracks until the crackles/glitches vanish, then it even demonstrates how you can double the number of Midi tracks when doubling the Audio Buffers and that you need to cut them in half if you lower Audio Buffers to half the value.
Last edited by Timur on Wed Jan 23, 2008 8:38 pm, edited 1 time in total.
After I am vinished with the regular videos (2 more to come, one about Plugin Buffers and one comparing Live 6.10) I will shot a video that includes what you asked for. I already did those test after reading your post and can tell you as much as this already: Neither hardware-interrupts, DPC or any of Live's threads seems to peak when measured at 0.5 second intervalls. The more Midi tracks are played the more CPU load is used by Microsoft's C Runtime Library MSVC71.dll. DPC Latencty Checker also remains all green and I can run a 3D stress-test via ATI-Tool without recognizing any much differences.Alex wrote:The task manger is not a good measuring tools for audio performance. You need at least a tool that show the usage for each thread. Almost the same is valid true for the audio usage display of Live. What you cant see there are the peaks which again are responsible for the audio drop-outs you can hear.
I underlined hardware-interrupts and DPC because Nico wrote me in his last e-mail that running the Midi port drivers hot would result in heavy CPU/system load because of hardware-interrupts. My system does not feel loaded down when Live starts producing drop-outs, albeit I can pretty much load it once I play several dozend Midi tracks.
If necessary I can download that Tracelog app, but maybe that's more of a task for your quality assurance/coder department, because I feel that I already invested too much time into this. All I want is to get rid of the bugs and see Live performing at its best.Microsoft Hardware Developer Center wrote:For good system performance, a Windows kernel-mode driver should minimize the time it spends in its deferred procedure calls (DPCs) and interrupt service routines (ISRs). DPCs and ISRs run at an elevated interrupt request level, or IRQL (DISPATCH_LEVEL and device IRQL, respectively). A driver that spends too much time in its DPCs and ISRs prevents the system from servicing threads, which degrades overall system performance. A driver should spend no more than 25 microseconds in an ISR and no more than 100 microseconds in a DPC.
You can measure the time that Windows kernel-mode drivers spend in DPCs and ISRs by using a new feature of Tracelog, a command-line tool provided with the Windows Driver Kit (WDK) that manages software tracing sessions. The DPC/ISR feature of Tracelog captures the activity of all drivers running in the kernel during the trace, even drivers that are not instrumented for tracing.
Live 6.10 behaves completely different! While in Live 7 only the total ammount of Midi data is relevant and it doesn't make any difference wether you are using one or several ports. In Live 6 the ammount of data per port is limited. In Live 6 I can send about three tracks of 127 notes out per one Midi port without drop-outs. So when I use three Midi ports I can send out a total of 9 tracks, while I can only send 3 tracks with one port. I can push Live 6's CPU meter upto 3000% while my system isn't even sweating. I will demonstrate all this in Video 3.Alex wrote:It is true, sending many (several hundreds or more) MIDI notes through a MIDI port at the same time will lead to audio drop outs. But that's the case for all previous Live versions too.
What would be interesting is to know if there's a certain Live set that produces drop-outs in Live 7 but not in Live 6 (both version with the same setup of course).
First of all, I setup these tests to run Live into the extreme and thus be able to find the weak spots. I know quite well that in real life you are not gonna send out several hundred Midi notes at once. But in order to get away from sporadic drop-outs/glitches and crashes to something reproducible I had to come up with an easy to setup test-scenario. Nevertheless I had one very particular practical application in mind!Alex wrote:Another question is the one for a real scenario concerning the maximal number of MIDI notes sent out via an MIDI port.
There is a regular scenario in which hundreds of Midi bytes are send out to physical interfaces: Sysex output of Control Interfaces! For very good reasons we Remote SL users have experienced the worst performance issues. The following list displays the Midi data being send from Live to the Remote SL while moving one single track fader from minimum to maximum position via mouse, and that's only one fader to one control surface (I'm using several!):
Code: Select all
TIMESTAMP IN PORT STATUS DATA1 DATA2 CHAN NOTE EVENT
0000B02F 1 -- B0 10 01 1 --- Control Change
0000B03E 1 -- F0 Buffer: 88 Bytes System Exclusive
SYSX: F0 00 20 29 03 03 11 04 04 00 02 01 00 04 04 2D 35 38
SYSX: 2E 30 20 64 42 20 30 2E 30 30 20 64 42 20 20 30 2E 30
SYSX: 30 20 64 42 20 20 30 2E 30 30 20 64 42 20 20 30 2E 30
SYSX: 30 20 64 42 20 20 20 20 20 20 20 20 20 20 20 20 20 20
SYSX: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 F7
0000B040 1 -- B0 10 05 1 --- Control Change
0000B048 1 -- B0 10 08 1 --- Control Change
0000B051 1 -- B0 10 0A 1 --- Control Change
0000B059 1 -- B0 10 0D 1 --- Control Change
0000B062 1 -- B0 10 12 1 --- Control Change
0000B068 1 -- B0 10 13 1 --- Control Change
0000B072 1 -- B0 10 16 1 --- Control Change
0000B081 1 -- B0 10 19 1 --- Control Change
0000B089 1 -- B0 10 1C 1 --- Control Change
0000B099 1 -- B0 10 20 1 --- Control Change
0000B0A0 1 -- B0 10 23 1 --- Control Change
0000B0B2 1 -- B0 10 29 1 --- Control Change
0000B0B3 1 -- F0 Buffer: 88 Bytes System Exclusive
SYSX: F0 00 20 29 03 03 11 04 04 00 02 01 00 04 04 2D 32 30
SYSX: 2E 32 20 64 42 20 30 2E 30 30 20 64 42 20 20 30 2E 30
SYSX: 30 20 64 42 20 20 30 2E 30 30 20 64 42 20 20 30 2E 30
SYSX: 30 20 64 42 20 20 20 20 20 20 20 20 20 20 20 20 20 20
SYSX: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 F7
0000B0BA 1 -- B0 10 2D 1 --- Control Change
0000B0C2 1 -- B0 10 30 1 --- Control Change
0000B0D0 1 -- B0 10 34 1 --- Control Change
0000B0D6 1 -- B0 10 35 1 --- Control Change
0000B0DE 1 -- B0 10 36 1 --- Control Change
0000B0F0 1 -- B0 10 38 1 --- Control Change
0000B0F6 1 -- B0 10 39 1 --- Control Change
0000B100 1 -- B0 10 3C 1 --- Control Change
0000B106 1 -- B0 10 3D 1 --- Control Change
0000B110 1 -- B0 10 40 1 --- Control Change
0000B11A 1 -- B0 10 44 1 --- Control Change
0000B122 1 -- B0 10 47 1 --- Control Change
0000B122 1 -- F0 Buffer: 88 Bytes System Exclusive
SYSX: F0 00 20 29 03 03 11 04 04 00 02 01 00 04 04 2D 31 31
SYSX: 2E 36 20 64 42 20 30 2E 30 30 20 64 42 20 20 30 2E 30
SYSX: 30 20 64 42 20 20 30 2E 30 30 20 64 42 20 20 30 2E 30
SYSX: 30 20 64 42 20 20 20 20 20 20 20 20 20 20 20 20 20 20
SYSX: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 F7
0000B12A 1 -- B0 10 4A 1 --- Control Change
0000B12F 1 -- B0 10 4C 1 --- Control Change
0000B140 1 -- B0 10 51 1 --- Control Change
0000B152 1 -- B0 10 59 1 --- Control Change
0000B158 1 -- B0 10 5B 1 --- Control Change
0000B162 1 -- B0 10 60 1 --- Control Change
0000B16A 1 -- B0 10 63 1 --- Control Change
0000B170 1 -- B0 10 66 1 --- Control Change
0000B182 1 -- B0 10 6E 1 --- Control Change
0000B187 1 -- B0 10 73 1 --- Control Change
0000B187 1 -- F0 Buffer: 88 Bytes System Exclusive
SYSX: F0 00 20 29 03 03 11 04 04 00 02 01 00 04 04 32 2E 33
SYSX: 36 20 64 42 20 20 30 2E 30 30 20 64 42 20 20 30 2E 30
SYSX: 30 20 64 42 20 20 30 2E 30 30 20 64 42 20 20 30 2E 30
SYSX: 30 20 64 42 20 20 20 20 20 20 20 20 20 20 20 20 20 20
SYSX: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 F7
0000B193 1 -- B0 10 77 1 --- Control Change
0000B19A 1 -- B0 10 7B 1 --- Control Change
0000B1A2 1 -- B0 10 7E 1 --- Control Change
0000B1AA 1 -- B0 10 7F 1 --- Control Change
0000B1FB 1 -- F0 Buffer: 88 Bytes System Exclusive
SYSX: F0 00 20 29 03 03 11 04 04 00 02 01 00 04 04 36 2E 30
SYSX: 30 20 64 42 20 20 30 2E 30 30 20 64 42 20 20 30 2E 30
SYSX: 30 20 64 42 20 20 30 2E 30 30 20 64 42 20 20 30 2E 30
SYSX: 30 20 64 42 20 20 20 20 20 20 20 20 20 20 20 20 20 20
SYSX: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 F7
0000BB61 1 -- F0 Buffer: 88 Bytes System Exclusive
SYSX: F0 00 20 29 03 03 11 04 04 00 02 01 00 01 04 50 6C 65
SYSX: 61 73 65 20 73 65 6C 65 63 74 20 61 20 44 65 76 69 63
SYSX: 65 20 69 6E 20 4C 69 76 65 20 74 6F 20 65 64 69 74 20
SYSX: 69 74 2E 2E 2E 20 20 20 20 20 20 20 20 20 20 20 20 20
SYSX: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 F7
0000BB61 1 -- F0 Buffer: 88 Bytes System Exclusive
SYSX: F0 00 20 29 03 03 11 04 04 00 02 01 00 02 04 31 2D 41
SYSX: 75 64 69 6F 20 20 20 32 2D 4D 49 44 49 20 20 41 2D 52
SYSX: 65 74 75 72 6E 20 42 2D 52 65 74 75 72 6E 20 20 4D 61
SYSX: 73 74 65 72 20 20 20 20 20 20 20 20 20 20 20 20 20 20
SYSX: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 F7
0000BB61 1 -- F0 Buffer: 88 Bytes System Exclusive
SYSX: F0 00 20 29 03 03 11 04 04 00 02 01 00 03 04 20 20 20
SYSX: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
SYSX: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
SYSX: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
SYSX: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 F7
0000BB62 1 -- F0 Buffer: 88 Bytes System Exclusive
SYSX: F0 00 20 29 03 03 11 04 04 00 02 01 00 04 04 36 2E 30
SYSX: 30 20 64 42 20 20 30 2E 30 30 20 64 42 20 20 30 2E 30
SYSX: 30 20 64 42 20 20 30 2E 30 30 20 64 42 20 20 30 2E 30
SYSX: 30 20 64 42 20 20 20 20 20 20 20 20 20 20 20 20 20 20
SYSX: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 F7
Last edited by Timur on Thu Jan 24, 2008 1:05 pm, edited 5 times in total.
The following screenshot demonstrates what happens exactly when Live 7 remains in Memory after a Crash. At the moment it seems as if Windows' DRWATSON is to blame for this. Neither can I kill it's thread nor can I even access its stack without hanging the Sysinternals "Process Explorer" application.
Concerning Live's performance when outputting lots of Midi data I'd like to emphasize again one of the video scenes where you can see that starting scenes leads to obviously more drop-outs than starting clips one by one even if the same number of tracks and notes keeps playing all the time!? Strange thing, isn't it?
Hey Alex,
thanks for the answers!
thanks for the answers!
I hope you do, and I tried my best to provide you with as many informations as I am able to squeeze out of my system. Feel free to discuss any questions via mail with me. Do you still need a video showing the thread-, hardware-interrupt and DPC load? Most probably I will also do one that demonstrates Live's tremendous GUI/CPU load problems on Vista and post it here. Some feedback on that could help though, since I can't tell myself how much of these issues is bound to my system and what you can reproduce yourself.all I can say for the moment is that we currently investigate some of these "MIDI" issues. However, you mention a lot of things so please don't expect that we will take a big part in that discussion here.
Ok, I'll wait for the questions then. I can also send you loads of crash-reports! Crashing occurs mostly when you try to lower audio-buffers during playback during that heavy Midi output. But also sometimes when trying to change ASIO drivers or trying to switch Midi ports on/off. Changing audio-buffers or switching drivers will also usually lead to stuck notes, loud noise, hanging GUI for a few seconds and the like.
I was wrong with this one. You can change Plugin Buffers in Live 6.10, but in order for Live to really make the change happen you have to restart/reopen the set.Also the Plugin Buffers setting of Live 6.10 does not work, but seems to always be set to 64 buffers.
I constructed a Battery set that makes sure that really only one voice is being played at a time. This still leads to timing errors in both Live 7 and 6.10 when using higher Plugin Buffer values. Anything setting above 128 buffers will lead to audible inaccuracies. Interestingly I cannot measure CPU time for the Battery thread for any buffer settings below 256 samples, so this definetively is the breaking point. 128 or 256 samples seem to be the best compromise between audible timing oddities and CPU load at the moment. It is still possible that this is due to a bug in Battery/Kontakt.I had plans for another video about the timing issues I experienced and demonstrated in conjunction with Plugin Buffers, but it turned out that the error/bug may be attributed to NI Battery 3/Kontakt 3 instead of Live or at least to both. I noticed that for higher Plugin Buffer values both Battery and Kontakt tend to play 3 voices regulary with peaks upto 5 eventhough they were only allowed to play 1.