I want to monitor my voice after the effects . so low latency mode is not for me. Normally when I record I reduce the buffer size to around 128 samples. but now changing buffer size doesn't change anything. same latency as 2048 . when i do it in some other daw for example in fl studio it works fine with very latency with low buffer size. but not in studio one. I've tried changing two audio interfaces. Audient id and Yamaha ag06. any clue ?
Hi,
I can't change the buffer size to reduce the latency! When in a DAW (tried in Ableton & Reaper), and I click the button to make settings to the buffer, it opens Universal Control but there, it's all blank! There isn't a single setting to adjust! No checkboxes, buttons, sliders,...nothing, nada?
The requested info...
- (Self-built PC)
- Windows 10 x64
- Universal Control v3.1.2.54970, Reaper 6 & Ableton 10
- AudioBox USB, drivers....dunno. It's bundled in the Audio Control download so...?
- Digital Mixer? It's the one in the DAW mentioned above (strange question)
- I don't see a 'More Information' area?
How can I change buffersize in FMOD Studio Unity Integration 1.09.06 ? I try to set it by RuntimeManager.LowLevelSystem.setBufferSize but nothing change. it is on default values like before I mean 1024 and 4. I want to change it to 512 and 2.
In Studio One, the Audio Setup / Audio Device / Device Block Size setting in the Preferences dialogue sets the basic buffer size. For the lowest monitoring latency, set it as small as you can get it without incurring dropouts, glitches or clicks. I usually use 32 samples, or sometimes 64 samples (for high-res, high-track-count situations) when recording. The input and output latencies in milliseconds produced by the current setting are displayed at the bottom of the dialogue. Round-trip delay time is the sum of the input and output latencies.
As DSP chips became cheaper, the next solution for the buffer-size paradox emerged as dedicated DSP chips for monitor mixing embedded in interfaces. Real-time, hardware-based mixing has near-zero latency, so inputs are heard without delay and Device Block Size can be optimised for track playback.
Screen 2: With a 512-sample buffer set for mixing, latency is too high to monitor while recording without either hardware monitoring or native low-latency monitoring. If you needed to add an overdub while mixing a session with lots of tracks and plug-ins, making the buffer smaller could result in glitching.
Screen 3: When using hardware monitoring, latency on the input is of no concern. Here, an EQ is inserted on the input channel, committing that EQ to the recording. When the mixer is in the integrated window, double-clicking the meter on the input channel makes inserts visible.
One interesting technique to try if you have a PreSonus device with onboard DSP is linked hardware/software Fat Channels. Implement a Fat Channel on an interface mixer channel, implement a Fat Channel on the corresponding Studio One mixer channel, and then click the Link button. Now, the Studio One Fat Channel follows changes to controls on the interface Fat Channel. You get Fat Channel processing on your monitors while recording, and then those settings get transferred to the Fat Channel in Studio One so you can work with them after you finish recording.
With two separate buffers to meet two conflicting needs, Device Block Size can be kept low for minimal monitoring latency, while Process Block Size can be set larger to accommodate playing back lots of tracks without dropouts or glitches. As with Device Block Size, estimated latency times for the Process Block Size buffer are shown in the Monitoring Latencies section at the bottom of the pane.
All contents copyright SOS Publications Group and/or its licensors, 1985-2024. All rights reserved.
The contents of this article are subject to worldwide copyright protection and reproduction in whole or part, whether mechanical or electronic, is expressly forbidden without the prior written consent of the Publishers. Great care has been taken to ensure accuracy in the preparation of this article but neither Sound On Sound Limited nor the publishers can be held responsible for its contents. The views expressed are those of the contributors and not necessarily those of the publishers.
Does anyone know if there a way to increase the size of the logcat history/buffer in Android Studio? I remember there was a way to do it in Eclipse and was hoping Android Studio had a similar setting.
In Android Electric Eel 2022.1.1 Patch 1 (with new logcat) any of older answers in here didn't worked for me... in settings -> Editor -> General -> Console I don't have "console cyclic buffer" option, instead I have "Console commands history size" which can take at most 1000 (bigger num after pressing Apply will be reduced to 1000) and thats not true, I do have more lines in output.. also setting idea.cycle.buffer.size to some high value, 0 or disabled didn't make any changes (yes, IDE was restarted few times)
But I've found (new?) section in Settings -> Tools -> Logcat and in here we have "Logcat cycle buffer size". Changing this value worked for me (by default it was 1024)
edit: worth noting that we can also change on-device buffer size (in Developer Options). After setting above AS buffer size even hot device plug-in will give more historical logs at beginning
Because we need to set them all before calling FMOD_System_Init(), it seems impossible to change them ever again after initialization. But as you know, there are tones of music applications which offers options to adjust them freely.
There is no way to change the System sample rate nor buffer size once System::init has been called. To do so you must shutdown everything and start up again. Usually an appropriate rate and buffer size (often left at default) is chosen at design time and remains in effect, why do you need to change these things at runtime?
I'm having a lot of problems with my UX1 TonePort. I have used it for many years now without any problem, but I recently bought a new (better) computer and now there's some huge latency problems, as well as a lot of clipping and things like that.
The BIG issue is, every time I try to change the buffer size (to fix the latency issue) my computer freezes for a second and then I get the blue screen of death.
All drivers are up-to-date and everything is registered correctly. Could it be that my TonePort is just too old? I've had it since 2006, haha.
Would really appriciate any help.
Thanks!
Okay, tried that....according to the DPC, it should work fine. "This machine should be able to handle real-time streaming of audio and/or video data without drop-outs."
I don't get it. I thought it could be my monitors, but they worked perfectly on my other computer.
I'm currently testing the Fireface 802 with my Windows 10 64bit system running Cubase 10. For some reason, I can't change the buffersize in Cubase sometimes. I can open the settings tab, but whatever setting I choose the latency time stays the same. This is REALLY annoying.
I also wonder why there is two ways to enter these settings. One is over the ASIO device setting within Cubase and another one is by opening the Fireface USB Settings over the windows task bar. Changing the settings in both doesn't do anything.
If this is an unsolvable issue, I probably gonna send the unit back. Never had this problem with any other interface.
Hope you guys can help!
> I also wonder why there is two ways to enter these settings.
> One is over the ASIO device setting within Cubase
> and another one is by opening the Fireface USB Settings over the windows task bar.
Now would be interesting what particular version of OS, firmware, driver and software you are using.
Which Windows 10 version ?
Which RME ASIO Driver version ?
Which RME 802 firmeware ?
Which Cubase version ?
I have the exact same problem with my FF UCX (USB connnected).
No reaction to buffer size changes in Cubase, no matter if I change from cubase itself with the settings dialog,
or directly in the RME control panel.
Also if I change the buffer size after I close Cubase, Cubase won't playback any audio, I have to restart the system.
Every possible driver, windows and firmware is up to date.
The problem occured from the start, I also tried with an older Windows build
older bios, and older Cubase versions.
Also, every USB Port available on the mobo behaves the same.
Perhaps, it is Cubase related. Or a particular setting either in Cubase or in the FF Settings. Have you tried with other DAWs?
You could download Reaper, which has an evaluation period, but with unlimited funcionality and check!
In older versions the buffer size did not change when the project used only 2 channels of I/O. And there is a setting that stops Cubase in the background. But both don't sound like they could explain your exact situation.
It's no AMD problem. My system has an intel i7. It's interesting that sometimes the buffer size change works and sometimes not. And when it stops working I usually also can't play any other Windows audio anymore (like Spotify or Youtube...). The playback then sounds totally bitcrushed.
I think it has to do with Cubase. I have the newest Cubase version but it also happened on older ones. Drivers and Windows are all updated.
Last possible solution would be to connect the UCX via FW, using a PCIe>FW controller card.
I tested this some years ago on my old system (with onboard FW controller), but USB perfomed better.
Otherwise I'm running out of ideas.