steinberg:cubase:audio_drop_out
[홈레코딩 필독서]"모두의 홈레코딩"구매링크
[공지]회원 가입 방법
[공지]글 작성 및 수정 방법
목차
Audio Drop out
기본적으로 Cubase 의 ASIO 드라이버는 디지털에서의 사용되는 데이터에 최대한 문제가 없도록 설계가 되어 있지만, CPU 사용률이나 컴퓨터의 안정성, 또 ASIO buffer 셋팅에 의하여 Audio Drop out 이 발생할 수 있다.
녹음을 하는 상황일 때 Audio Drop out 이 발생한다면 에러를 표시하면서 멈추게 되지만,
그냥 단순히 트랙을 재생하거나, 인풋을 소프트웨어 모니터링 하거나 VSTi 를 연주할 때에는 이러한 Audio Drop out 은 대부분은 귀에 들리지 않는, 티가 나지 않는 순간적인 Audio Drop out이1) 대부분이기 때문에, 플레이백 에서는 Audio Drop out 이 발생해도 무시되고 그대로 플레이/인풋 모니터링 되게 되어 있다. 다만, F12키를 누르면 나오는 Audio Performance 창에서 빨간색 피크색으로 표기를 하여 Audio Drop out이 발생했었음을 알려준다.
ASIO performance meter
Realtime
실시간 오디오 처리(소프트웨어 모니터링, VSTi 실시간 연주)에 대한 점유율을 보여준다.2)
만약 여기서 빨간색 Peak 등이 점등 된다면, 소프트웨어 모니터링 또는 실시간으로 연주되는 VSTi 소리에서 Audio Drop out이 발생한 것이다. 대체적으로 여기서 발생하는 Audio Drop out은 대부분 눈치 채지 못할 정도로 티가 나지는 않지만, Audio Drop out이 좀 더 많이 발생하면 소리가 끊기게 들리거나 틱틱 거리는 잡음이 날 수 있다.3)
하지만 여기서 Peak가 점등 된다고 해서 Audio Drop out 에러 메세지가 표시되면서 오디오 엔진이 멈추지는 않게 되어 있다. 그냥 계속해서 실시간으로 오디오 처리를 해야 하기 때문이다.
예를 들면, 무엇인가를 녹음할 때, 소프트웨어 모니터링으로 실시간 인풋 모니터링을 하면서 녹음 시에 오디오 드롭 아웃이 발생했다고 해서 녹음을 멈추면 안되기 때문에, 순간적인 오디오 드롭 아웃은 무시하고 오디오 엔진은 계속 동작한다. 즉 녹음이 멈추지는 않는다.
ASIO Guard
비실시간 오디오 처리(ASIO-Guard)에 대한 점유율을 보여준다.
이미 녹음되어 트랙에 있는 오디오나, 또는 이미 MIDI로 녹음되어 트랙 위에 존재하는 VSTi 노트들에 대한 오디오 처리는 ASIO-Guard 에서 따로 설정한 버퍼 사이즈 만큼의 처리 시간만큼 미리 읽어들여서 사전에 프로세싱한다. 이렇게 미리 처리를 함으로써 CPU 점유를 줄이는 것에 도움을 준다. 즉 이미 DAW에 미리 존재하는 데이터들이므로 미리 CPU로 읽어들여서 모든 오디오 처리를 안정적으로 끝마친 후, 재생 하는 커서가 위치하는 시점에만 맞춰 재생한다. 따라서, Realtime, 실시간 오디오 처리보다 훨씬 안정적인 오디오 처리를 할 수 있고, 훨씬 안정적인 CPU 점유율을 보여준다.
만약 ASIO-Guard 에서 부하가 커져서 Audio Drop out이 발생하면 Audio Drop out 에러를 표시하며 오디오 엔진이 멈춘다.
ASIO-Guard의 버퍼 사이즈는 Studio Setup에서 Audio System 페이지의 ASIO-Guard 에서 설정할 수 있다.
가끔 보면 소프트웨어 모니터링 사용이나 VSTi의 실시간 연주를 위해 ASIO-Guard를 끄라는 정보들이 많은데, 이것은 매우 잘못된 정보이다. ASIO-Guard에 의한 레이턴시 값은 내부에서 미리 처리하는 시간을 말하므로 실시간 소프트웨어 모니터링에 추가되는 레이턴시가 아니다. 또한 실시간 연주의 안정성을 위해서는 트랙에 이미 존재하는 오디오나 MIDI는 ASIO-Guard 버퍼를 통해 미리 프로세싱되는 것이 훨씬 안정성이 도움이 되므로 절대 꺼서는 안된다.
Peak
모든 오디오 처리를 종합하여 가장 높은 Peak 의 점유율을 보여준다.
실시간 오디오 처리나 ASIO-Guard 처리 중에 급격한 Peak 부하가 발생하는 경우 이 Peak 부분에서 표시된다. Peak 에 의해 Audio Drop 이 발생하면, Realtime, ASIO-Guard 상관 없이 Audio Drop out 에러 메세지를 표시하며 오디오 엔진이 멈추게 된다.
사실 이 Peak 미터가 보여주는 부분은 전체적인 오디오 시스템의 안정성을 대표한다.
즉 Peak 미터가 불안정하다면, 오디오 인터페이스와의 연결이 불안정하거나, 컴퓨터 시스템에 문제가 있어서 불안정한 경우가 대부분이다. 오디오 인터페이스와 시스템이 소화 불가능한 너무 낮은 ASIO 버퍼 사이즈를 설정해도 이 Peak 미터가 불안정하게 된다. 따라서 Peak 미터가 안정적으로 동작하는지 잘 관찰하면 사용하는 오디오 인터페이스와 시스템에 가장 적절한 ASIO 버퍼 사이즈를 찾는 것에 도움이 된다. Peak 미터가 안정적으로 동작하면, Realtime 이나 ASIO-Guard 가 많이 점유해도 안정적인 동작이 가능하게 된다. 또한 DAW의 전반적인 모든 기능들이 안정적으로 동작하게 된다.
따라서 오디오 인터페이스와 시스템에서 가장 안정적으로 동작하는 가장 낮은 ASIO 버퍼 사이즈를 찾을때 이 Peak 미터를 잘 관찰 하면 도움이 된다.
ASIO 버퍼 사이즈를 소프트웨어 모니터링을 위해 너무 최소로 낮추는 것은 좋지 않다. ASIO 버퍼 사이즈는 Peak 미터가 안정적으로 동작 가능한 버퍼 사이즈를 찾는 것이 중요하며, 이 때문에 소프트웨어 모니터링 보다 다이렉트 모니터링이 더 선호되는 이유이다.
Disk cache
만약 여기서 빨간색 Peak 등이 점등 된다면, 디스크에 기록되는 정보에서 누락이 발생하여 Audio Drop out 이 발생한 것.
원인은 디스크의 쓰기 속도가 오디오의 정보의 출력 속도를 따라잡지 못하여서 이다.
따라서 Audio Drop out 에러 메세지를 표시하며 오디오 엔진이 멈추게 된다. 즉 녹음이 중간에 멈추게 된다.
Audio Export를 할 때 Audio Drop out이 절대 발생하지 않도록 프로세싱 하게 된다.4) 그래서 CPU 부하가 큰 프로젝트의 경우에는 Realtime Export보다 일반 Export가 시간이 더 오래 걸리는 경우도 있다.
CPU 점유율과의 상관관계?
물론 버퍼 사이즈에 따른 CPU 점유율은 대략적으로 반비례 한다.
버퍼 사이즈가 128 samples 일 때 CPU 점유가 30%였다면, 버퍼 사이즈를 256 samples 로 높히면, CPU 점유는 15% 즈음으로 내려간다.
하지만 Audio drop out은 그렇지 않다. CPU 점유와 큰 상관이 없다.
어떤 시스템이 버퍼 사이즈 64 samples에서 오디오 드롭 아웃이 만약 발생한다면, CPU 점유가 0%에 가깝게 낮더라도 오디오 드롭 아웃이 발생한다.
하지만 만약 그 시스템이 256 samples에서 오디오 드롭 아웃이 발생하지 않는다면, CPU 점유가 60-70%가 되더라도 오디오 드롭아웃은 발생하지 않는다.5)
Realtime 점유 시 Audio Drop out없는 안정적인 동작
비실시간(ASIO-Guard) 점유 시 Audio Drop out 없는 안정적인 동작
실제로 이 스크린샷들 에서는 거의 100%에 꽉 찬 CPU 점유에도 불구하고 절대 Audio drop out이 발생하지 않았다.6)
좀 더 깊이 들어가면 이것의 원인은 일단 ASIO 드라이버가 Realtime(소프트웨어 모니터링, 실시간 VSTi 연주)에 대해서는 데이터의 정확성 보다 실시간 재생에 더 치중하여 디지털 데이터를 실제로 Drop out을 한다는 점, 그리고 CPU의 L1, L2, L3 캐쉬의 성능/DMA7) 성능과 관련이 있다고 알려져 있다.
그렇기 때문에 이 예시에 나오는 시스템에서는 ASIO 버퍼를 256 samples 이하로 놓고 레코딩을 하지 않는 것이 좋다.(시스템마다 이 값은 다르다. 안정적인 버퍼 값을 찾아야 한다.) CPU 점유와 상관 없이 Audio drop out이 발생하기 때문이다.
따라서, 이 시스템에서는 최소한 256 samples 이상의 ASIO buffer 사이즈에서 Audio drop out이 없는 안정적인 작동이 가능하다.
그러면 레코딩 시스템에서 모니터링은, 당연히 소프트웨어 모니터링을 하기 힘들다. 256 samples 만 되더라도 레이턴시가 살짝 있기 때문이다.8)
오디오 인터페이스에서 설정상 최소로 가능한 버퍼 사이즈와, 해당 시스템(오디오 인터페이스와 컴퓨와 DAW를 통합해서)에서 안정적으로 동작하면서 소화가 가능한 최소 설정 가능한 버퍼 사이즈의 의미는 엄밀히 다르다.
따라서 당연히도, 레코딩 용도의 시스템은 콘솔 모니터링이나 다이렉트 모니터링 시스템으로 구축하는 것이 바람직하다.
Warn on processing overload
만약 레코딩 상황이 아닌, Realtime(소프트웨어 모니터링, VSTi 실시간 연주)이나 단순 플레이백 상황에서 Audio Drop out이 발생했을 시에, 에러 메세지를 띄우고 오디오 엔진을 멈추고 싶으면 프리퍼런스에서 아래의 옵션에 체크를 하면 된다. 디폴트는 옵션에 체크가 안되어있는 상태인데, 재생이나 소프트웨어 모니터링에서 Audio drop out이 발생해도 오디오 엔진이 멈추지 않는다. 다만 drop out이 심하게 많이 발행하면 소리가 튀거나 버벅거릴 뿐이다.
일반적으로는, 이 옵션이 체크가 되어 있지 않으면 Realtime이나 플레이백에서는 Performance 미터에 빨간불만 들어오고 그냥 지나가고9), 레코딩 상황에서만 Audio Drop out 에러 메세지 표기와 함께 오디오 엔진이 멈춘다.
만약 Audio Drop out이 많이 발생한다면, 안정적인 ASIO buffer 셋팅이 아니므로 Buffer를 좀 더 크게 설정하여 사용함이 좋다.
레코딩 소스의 완벽성 및 안정성을 위해서 버퍼를 크게 사용해야 하기 때문에 다이렉트 모니터링이 중요하다.
버퍼사이즈가 매우 작을 때는(레이턴시를 낮추기 위해) 위 영상과 같이 Audio Drop out이 많이 발생할 수 있다.
4)
Realtime export 경우에는 만약 중간에 Audio drop out이 발생하면 에러를 표시하면서 멈춘다.
6)
예전 버전 기준 표기
8)
만약 64 samples에서 Audio drop out 이 절대 발생하지 않는 시스템이라면 소프트웨어 모니터링을 할만 할 것 같다.
9)
단, 지직거리거나 틱틱 거릴 수 있다.
로그인하면 댓글을 남길 수 있습니다.
[공지]회원 가입 방법
[공지]글 작성 및 수정 방법
steinberg/cubase/audio_drop_out.txt · 마지막으로 수정됨: 2024/08/26 저자 정승환