thank you so much. you have been a huge help :D you have fixed a problem i have been having for so long and i appreciate it. really i cant thank you enough
rockbottom
Active Member
YW!
I don't use my OS drive for recording. I would leave the current OS drive in place & add the extra NVMe & use it for recording.
I don't use my OS drive for recording. I would leave the current OS drive in place & add the extra NVMe & use it for recording.
im pretty sure it does
right now i do not have a spare nvme or ssd so i have to use my os drive but i will purchase a new drive asap :D
rockbottom
Active Member
Z790 does, Z690 doesn't, just check to make sure.
With my 690, I can add/run a Gen 5 NVMe but it will be at the cost of my GPU as it would need to run @ x8 4.0 instead of x16 4.0.
With my 690, I can add/run a Gen 5 NVMe but it will be at the cost of my GPU as it would need to run @ x8 4.0 instead of x16 4.0.
ROG Strix B550-F Gaming WiFi II features two M.2 slots, one of which supports the PCIe 4.0 standard to provide maximum storage flexibility and the lightning-fast data speeds. Both M.2 slots support up to the type 22110 socket and NVM Express® RAID for a performance boost.
so ig that means i got 2 gen 4 slots?
Edit: i think ill buy a Samsung 990 Pro 4TB M.2
rockbottom
Active Member
Duh I forgot you were running AMD, to many logs today.
Yeah, no Gen 5 support so no reason to spend the extra $$$.
M.2_1 is Gen 4
M.2_2 is Gen 3
M.2_1 slot (Key M), type 2242/2260/2280/22110 (supports PCIe 4.0 x4 & SATA modes)
AMD B550 Chipset:
M.2_2 slot (Key M), type 2242/2260/2280/22110 (supports PCIe 3.0 x4 & SATA modes)*
6 x SATA 6Gb/s ports
Support RAID 0, 1, 10
* When the M.2_2 Slot is populated , SATA6G_5/6 ports will be disabled.
rog.asus.com
Yeah, no Gen 5 support so no reason to spend the extra $$$.
M.2_1 is Gen 4
M.2_2 is Gen 3
M.2_1 slot (Key M), type 2242/2260/2280/22110 (supports PCIe 4.0 x4 & SATA modes)
AMD B550 Chipset:
M.2_2 slot (Key M), type 2242/2260/2280/22110 (supports PCIe 3.0 x4 & SATA modes)*
6 x SATA 6Gb/s ports
Support RAID 0, 1, 10
* When the M.2_2 Slot is populated , SATA6G_5/6 ports will be disabled.
ROG STRIX B550-F GAMING WIFI II | Motherboards | ROG United States
ASUS ROG STRIX B550-F GAMING WIFI II AMD Ryzen AM4 ATX motherboard (PCIe® 4.0, 14 power stages, WiFi 6E, Intel® 2.5 Gb Ethernet, dual M.2, ASUS OptiMem II, Two-Way AI Noise Cancelation, USB 3.2 Gen 2 and Aura Sync)
rockbottom
Active Member
So for that 2nd slot, you can look for a Gen 3 NVMe but I don't think there's going to be much savings there. A Gen 4 will work fine, it will just operate @ Gen 3 speeds & that is still more than fast enough to record lossless.
Lawrence_SoCal
Active Member
I'd also recommend getting Gen4 data NVMe drive due to low/0 price premium over Gen3, as then you will have the extra usable bandwidth when you move that SSD to next motherboard. On the other hand, I wouldn't pass up a great deal on a Gen 3 drive if I came across one ... depends on your budget
On a side note... I do record to my OS SSD drive. But the recordings are only around 11GB for 60-75 minutes. And 1/2 that OS drive space is free and I have no issues. I'm also not recording at that high a quality (from old recollection, Streaming at 7Kb/s and Recording at around 3X that bitrate, which is plenty for my use case, that does not have high motion within it). Once Recording complete, and cloud backup/sync finishes, I move Recording to HDD for archiving, and all viewing/editing off HDD works fine. *if* I had extensive video editing on a particular Recording, I'd probably temporarily copy/move that video file back to SSD to work on it there, just to speed things up a bit
Rockbottom - thanks for what you do for the community. I'm not sure it is possible, but it would be great to compile some of your hardware setting recommendations/considerations into a FAQ
As for hard drive recording, or SSD woes...
If you have enough system RAM, consider a hot-swappable "Ram-drive" setup. It creates a virtual drive in memory. You can turn it on and off, as needed. Since you want a blank drive, there is no need to have a "source" to load.
Eg, if you have a 64GB RAM setup, you can easily spare an 8GB-32GB chunk, to use as a blindingly fast virtual drive. (If setup with a game, OMG, loading times are instant for almost everything! Except the initial read, from the HDD or SSD, going into RAM.)
Get a big streaming boost by having OBS with admin rights, one level higher priority than normal, the game being played on a RAM-drive and also the recording being saved to a second RAM-drive. (Don't stream to the same RAM-drive that the game is on.)
Also, native NVIDIA RTX encoding is AV1, not mkv or mp4. Cut out one step of cross-encoding, if you can. (Consider using nvidia's live capture as your primary recorder, unless you need something specific that OBS offers.)
If you have enough system RAM, consider a hot-swappable "Ram-drive" setup. It creates a virtual drive in memory. You can turn it on and off, as needed. Since you want a blank drive, there is no need to have a "source" to load.
Eg, if you have a 64GB RAM setup, you can easily spare an 8GB-32GB chunk, to use as a blindingly fast virtual drive. (If setup with a game, OMG, loading times are instant for almost everything! Except the initial read, from the HDD or SSD, going into RAM.)
Get a big streaming boost by having OBS with admin rights, one level higher priority than normal, the game being played on a RAM-drive and also the recording being saved to a second RAM-drive. (Don't stream to the same RAM-drive that the game is on.)
Also, native NVIDIA RTX encoding is AV1, not mkv or mp4. Cut out one step of cross-encoding, if you can. (Consider using nvidia's live capture as your primary recorder, unless you need something specific that OBS offers.)
Lawrence_SoCal
Active Member
Running an y end-user app as Admin is a REALLY bad idea, typically. The primary reason on Windows with OBS Studio this is recommended is to overcome an overloaded GPU scheduler.... (ie, your hardware is under-powered for your tasking/settings) and running as Admin is a blunt-force/crude work-around, with significant downsides (unless rig is on isolated VLAN prevented from communicating ANYTHING else on LAN, used ONLY for gaming, and OS re-installed regularly)
if running OBS Studio as Admin for CPU priority, then user is being foolish as there are secure OS ways to increase priority of an OS process (or lower others) without compromising the system
if running OBS Studio as Admin for CPU priority, then user is being foolish as there are secure OS ways to increase priority of an OS process (or lower others) without compromising the system
Unfortunately, many aspects of OBS's functions don't actually work correctly, or well, unless it has admin operation. Namely, screen capturing of various windows and some sound devices, which windows operates, with admin restrictions. Windows is virtualized anyways, through wow32 and wow64, admins are just an elevated user, and nothing more. It's not as detrimental as it once was. An "admin" can't do any "system" rights restricted actions, unlike before, in 32-bit OS days.
Sadly, that is the common fix to most issues with programs now. So common that it's as simple as checking a box and there is no longer a warning stated about switching to "run as administrator".
I don't think it's a burdened process issue. Almost every computer now has more than 4 cores and processes jump to unburdened cores, when needed. Audio is not a taxing process. A CPU would barely consume 5% CPU use, processing audio. They all have dedicated audio and video processors, natively, in every CPU and through onboard DSP chips, and within all GPUs made, since 2005.
Yet another reason to ditch Windblows. Seems that Micro$haft is (ab)using their industry inertia to vacuum up all they can to support their ad revenue, and don't really care about anything else. Like user privacy, or actually working well under the hood according to basic modern standards. On that last point, it really is a hack, pretty much always has been really, and has never been fixed while modern pressures make it even worse. A fix *now* is probably not going to happen either, because it would break literally everything.
Mac and Linux are both better than that, by a LOT, and not that hard to use anymore. Different, yes, and have to be learned all over again, but neither is actually *hard*. You just have to *do it*, like you've never seen a computer before, and force yourself to stick with it.
No, but it could be a scheduling issue. See below.
I'm not sure that there are dedicated DSP chips, outside of a sound card itself, and even those are pretty basic. There are, however, single-instruction-multiple-data (SIMD) instructions (do the same operation to an entire array in just one cycle), multiply-and-accumulate all in one instruction ([new sample x coefficient] + accumulator -> accumulator), and similar things to make the general-purpose CPU itself cover DSP functions as well. The instruction set really is that broad.
GPU's are also designed to do exactly that, originally because video processing needs that sort of thing too, but there's no reason it can't also be used for audio. Same operations. But I don't know of any applications that actually do that.
As far as I know, audio is almost always handled on the CPU. Like you said, it's barely any load at all, and it takes extra work to route it to the GPU and back again. (at least for audio guys, who don't have much interest in graphics) So with equal functionality, less routing code, and minimal performance hit, it stays on the CPU.
---
The real problem is scheduling and buffering. In a multitasking system that only does one thing at a time (per core) and switches constantly, you have to have a buffer that records the incoming stream while the system is focused on something else, and another buffer that plays out while the system is focused on something else. Every once in a while, it grabs the entire incoming buffer, processes it all at once, and drops it in the outgoing buffer. The buffers are usually at least doubled, to remove the requirement to hit it *exactly* between the correct samples:
If the scheduling doesn't hit the buffers before they fill up or run out, then of course you have problems. That can be fixed with better scheduling and/or bigger buffers.
- Windows seems to go with the "bigger buffer" approach, which causes problems with latency for people with even slightly complex routing that ends up going through Windows' audio system multiple times. Each hop between apps is another trip through the system.
- My favorite operating system - Ubuntu Studio Linux (one of the easy ones to switch to if you know nothing anyway) - is far better scheduled, which allows the buffers to stay small and still be rock-solid.
Lawrence_SoCal
Active Member
Definitely not true as a global statement
I have NOT had to use Admin rights/account for any OBS Studio operations since day 1 (5 years ago)... Window capturing, NDI video feed, PTZ camera control, audio input from Mixer, and more on an i7-10700K not overclocked.
I'd want to have an updated conversation with an experience CISO staff engineer before accepting things have gotten that much better. I do acknowledge my avoidance of using Admin acct goes back to WinNT days, and I've have enough 3-letter agency and security software vendor briefings to know that up until a few years ago, keeping users from having Admin rights was still the single largest step to take for secure, reliable OS operation, etc. And not much has changed since then. So, I'm skeptical of 'running as administrator' being as benign as you are suggesting. Better than XP days, sure... but..
Now, there was mention, years ago with Win10 (and I suspect Win11 didn't change it much, if any) regarding GPU scheduling priority when doing demanding GPU multi-tasking (like certain (not all) gaming oriented use cases along with video encode offload.... and using 'running as admin' as only practical workaround when so constrained. Though that probably means the scenario is decently documented (guessing, not my area, but a reasonable assumption considering other levels of available documentation on the OS), by GPU drivers inadequate, or gaming software, trying to max out GPU is hamstringing other operations (ie, basically sloppy code and there can be reasonable opposing opinions on whether OS should keep ALL stupid programmers from negatively impacting overall system, and the extent to which one does that. In the gaming world, keeping bad code (of which there is a LOT) from messing with other system performance would severely hinder game performance... no free lunch.) I'm not a Windows OS fanboy (just my area of expertise), but I'm always attributing blame when multiple parties involved ... and there is plenty for which M$ is rightly to blame... just not sure this is one of them (might be?)