Serum CPU 사용량 최적화하기

원문

TOOLS / JANUARY 12, 2018

Optimizing Serum for better CPU efficiency

일러스트: Maria Chimishkyan

Xfer Records의 Serum은 강력하고 다재다능한 신디사이저로써 오늘날 수많은 사람들에게 신디사이저의 표준과 같이 칭송받고 있습니다. 특히, 진보된 할부 방식인 Rent-to-Own 방식을 지원하면서, Serum은 Splice’s Plugins store의 인기 상품이 되었습니다. 강력한 웨이브테이블 도구와 수많은 모듈레이션 옵션, 사용하기 쉬운 UI등이 사람들이 Serum을 선택하게 만들었지만, 한편으로는 지나친 프로세스 사용률로 비판을 받곤 합니다.

 KVR에서는

우선, 이 신스는 무지막지하게 프로세스를 사용합니다. i7 듀얼코어 프로세서인데도 Super saw 사운드로 노트를 치면 20~30%의 CPU 사용량이 나옵니다. 이건 한 가상악기라고 하기엔 너무 많이 먹어요! 물론 unison을 늘리는 대신 unison을 늘리는 효과를 흉내내는 이펙트를 쓰거나 글로벌 세팅에서 draft 퀄리티 설정을 함으로써 CPU 사용량을 줄일 순 있지만, 수학적인 임시방편에 불과합니다. 풍부하고 기름지고 깔끔한 소리를 원한다면, 이 문제는 상항 여러분들을 괴롭힐 것입니다. 여러분의 컴퓨터가 고사양이 아니라면, CPU 자원을 위해 MIDI 트랙을 오디오로 변환해야 할 것입니다.

MusicRadar에서는

세럼은 분명 신디사이저 연주자들의 구매 목록 최우선에 자리잡을 만큼 강력하고 경이로운 사운드를 뽑아냅니다.

장점 : 오실레이터 모핑, 다양한 unison 모드와 내부 웨이브테이블 편집기, 훌륭한 사운드, 뛰어난 이펙트, 엄청난 모듈레이션 옵션

단점 : CPU가 고생함

또한 Emusician에서는

강점 : 강력한 웨이브테이블 합성법, 다양한 모듈레이션과 톤 메이킹 기능

한계 : CPU를 많이 사용함, 스탠드얼론버전의 부재

업계 표준이라 칭송받는 Serum의 사운드에도 불구하고, 수많은 리뷰에서 CPU 효율 문제를 꼬집습니다. 그래서 본 글에서는 Serum의 CPU 사용량을 측정함으로써 사용자들이 겪는 불편함을 확인할 것입니다. 또한 Serum과 함께 유명한 웨이브테이블 신디사이저인 Massive와 비교하여 Serum에서 왜 CPU 문제가 발생하는지 알아보고 Xfer 개발자들에게 수정 제안을 하고자 합니다.

왜 저한테 이런 일이 일어나는 겁니까?

Xfer Records의 Steve Duda는 Serum subreddit (여기서 그는 유일한 관리자입니다.)과 Xfer 고객지원 포럼에서 활발히 활동하며, 늘 어떻게 Serum의 CPU 사용량을 줄일 수 있냐고 묻는 사용자들의 질문에 맞닥뜨립니다. Mr. Duda의 말에 따르면 CPU 사용량 문제는 보통 (적어도 부분적으로는) 사용자 문제에 의해 발생한다고 합니다.

제가 이전부터 쭉 받아온 대부분의 CPU 문의 사항은 지나치게 많은 동시 발음수 (Serum에서 오른쪽 아래에 나타남)를 제어하지 않아 발생한 것입니다. 어떤 신디사이저는 동시발음수를 64 이하로 제한하기도 합니다. 그러니 작업시에 늘 동시발음수에 유의하여 unison 설정을 하시길 바랍니다. (16이 좋은 소리가 나긴 하지만, 늘 최선의 소리가 난다는 보장은 없습니다!)

Xfer의 개발자였으며 현재 Splice의 오디오 과학자인 Sam Leggett도 이에 같은 의견을 표현합니다.

unison의 각 발음을 제어하는 것은 그 발음수에 따라 작업량을 늘리는 것과 같으며, 코드를 연주하는 것과 같이 한번에 많은 노트를 입력하는 경우, 그 노트의 동시 입력 개수만큼 작업량이 곱해지는 것과 같습니다.

즉, 사용자들이 동시발음수를 지나치게 올리면 CPU 사용량 문제가 발생한다는 것입니다. 디지털 신디사이저는 소리를 발생하기 위해 각 발음마다 어떠한 계산과정을 거쳐야 하며, 사용자가 동시발음수를 늘릴 수록, 그만큼 신디사이저에서의 소리 발생을 위한 계산량이 늘어납니다. CPU에서 이러한 계산 과정을 거치기 때문에, 동시발음수를 늘리는 것은 CPU 사용량을 높이는 것과 같으며, 이는 어떠한 디지털 신디사이저를 쓰더라도 피해갈 수 없는 현상이라는 것입니다.

Duda의 글에서는 은근히 NI의 Massive 신디사이저를 꼬집는 내용이 있는데, 바로 Massive가 동시 발음수를 64로 제한하여 동시 발음수가 64를 넘어설 경우 적절히 발음수를 줄이는 신디사이저이기 때문입니다. 이렇게 하면 사용자가 아무리 unison 세팅을 최대로 하고 동시에 여러 노트를 쳐도 Massive가 CPU 자원을 많이 사용하는 것을 방지할 수 있습니다. 다만, 대부분의 상황에서 동시 발음수가 많다는 이유만으로는 병목 현상이 일어나지 않는다는 점을 살펴 볼때, 동시발음수의 제한은 지나치다고 볼 수 있습니다.

Serum에서 2개의 오실레이터에 각각 8개의 unison 세팅이 되어 있는 패치로 도미넌트 13 C 코드 (C13)를 친다고 했을 때, 사용하는 동시발음수는 7개의 노트 (C E G B♭ D F A)에 2개의 오실레이터, 8개의 unison을 곱해 112개라는 답을 얻습니다. Massive의 경우 동시발음수를 제한함으로써 음색의 변화가 발생하지만, Serum은 동시발음수를 제한하지 않음으로써 CPU 사용량은 증가하더라도, 해당 패치의 온전한 음색을 재생할 수 있습니다. 

Duda 가 언급한 또다른 잠재적인 CPU 사용 문제로는 과도한 오버샘플링이 있습니다.

일반적인 오실레이터 설정에서는 2x 설정이 권장되며, 4x 설정과 별 차이가 나지 않을 것입니다. 그럼에도 4x 설정을 사용하는 것은 CPU 자원의 낭비를 가져옵니다. 4x 설정은 보통 FM 와핑 모드에서 매우 높은 주파수를 발생시킬 때 디지털 변조가 나타나는 것을 막기 위해 사용합니다. 이외의 다른 와핑 모드를 사용할 때 4x 설정이 소리의 차이를 만들어낼 것입니다.

오버샘플링 수준은 단순히 올리기만 하면 소리가 좋아질 것이라고 생각되지만, 사실은 Duda의 말이 옳습니다. 나이퀴스트-섀넌 샘플링 정리에 따르면 샘플링 주파수가 나이퀴스트 주파수(오디오 신호의 최대 주파수의 두배)보다 높다면 완벽하게 오디오 신호를 재현할 수 있습니다. 따라서 2x 수준의 오버샘플링만으로 충분히 거의 모든 오디오 신호를 정확히 재현해낼 수 있습니다.

그래서 뭐 어떡해야 합니까?

우선 Serum을 최신 버전으로 유지하세요. Serum의 코드가 업데이트되면서, 이전에 문제로 지목되던 CPU 효율이 개선되었습니다. 만약 크랙 버전을 이용하고 있다면 최신버전으로 유지할 수 없으며, 업데이트가 불가능하기 때문에 성능상의 문제가 발생할 수 있습니다. 정당하게 Serum을 사용하고자 한다면 한달에 9.99달러를 지불하는 Rent-to-Own 방식으로 정품 Serum을 구할 수 있습니다.

하지만 Serum을 최신 버전으로 업데이트 했다고 가정하고 Sam과 Steve의 주장을 확인해봅시다. 아래에서 우리는 그들이 잠재적인 CPU 병목현상의 원인으로 지목하는 요소들과 실제 CPU에 가해지는 부하의 관계를 확인할 것이며, 이것이 Serum의 최종 출력 사운드에 어떠한 영향을 미치는지 살펴볼 것입니다.

과연 말한 대로 작동할까요?

테스트를 위해 제 맥북 프로 레타나와 Splice 스튜디오의 맥 프로를 사용할 것입니다.

Serum은 스탠드얼론 버전이 없기 때문에 Ableton Live 9에서 Serum을 불러 테스트할 것입니다. CPU 사용량을 측정하기 위해 하나의 코어의 사용량 피크를 측정하는 Live의 내장 CPU 모니터를 사용할 것입니다. 물론 "전 18코어 하이풔쓰뤠딩 씨퓨쓰는데여???!!?!" 라고 생각할 수 있습니다. 하지만 사실 Serum은 두 개의 코어 쓰레드만 사용합니다.  Duda의 말을 다시 한번 인용하자면

DSP 쓰레드와 GUI 쓰레드로 구성됩니다. 보통 DAW에서 코어를 통해 인스턴스(트랙)를 호출하기 때문에 이 방식이 가장 적합합니다. 다수의 DSP 쓰레드를 동작시킬 경우 수많은 자원이 소모되는 대신, 단일 인스턴스에서 더 많은 것을 허용할 수 있지만, 이는 동시발음수를 적절하게 조절할 수 있다면 굳이 필요하지 않은 기능입니다.

Xcode의 가상악기에서처럼 CPU 사용량 프로파일링 테크닉을 통해 더 자세한 데이터를 얻을 수 있겠지만, Serum은 스탠드얼론 버전이 없기 때문에 결국 DAW와 독립적으로 CPU 사용량을 측정할 수는 없었습니다.

Steve의 포럼 게시글과 Sam으로부터 수소문해 얻은 제안들을 바탕으로 Live에서 아래의 요소들이 CPU 사용량에 어떠한 영향을 미치는지 확인할 것입니다.

동시 발음수

• 32 (Serum and Massive)
• 64 (Serum and Massive)
• 128 (Serum only)

오버샘플링

• 1x (Serum 1x, Massive Eco)
• 2x (Serum 2x, Massive High)
• 4x (Serum 4x, Massive Ultra)

엔벨로프 릴리즈 시간

• 200ms
• 1000ms
• 32000ms

리버브

• 모두 100%

위의 요소들을 제외하고는, 2개의 saw파 오실레이터로 구성된 init 프리셋을 사용했으며, 별도의 표기가 없다면 오버샘플링은 기본값인 2x로 설정했습니다. Massive의 릴리즈 시간은 예상값으로 설정했습니다. 동시발음수 테스트를 제외하고는 모두 같은 코드를 입력해서 테스트를 진행했으며, 각 요소들은 3번씩 측정하여 평균값을 구하는 방식으로 결과값을 도출했습니다.

어떻게 됐나요?

세 줄 요약좀요

CPU 사용량을 줄이고 싶다면

동시발음수를 제어하고

생각하고 오버샘플링을 합시다.

위의 데이터가 말해주듯이 CPU 사용량은 Massive와 Serum 모두 동시발음수와 오버샘플링 정도에 큰 영향을 받는 것으로 나타났습니다. 리버브와 릴리즈 시간도 CPU 사용량에 영향을 주지만, 이들의 영향은 비교적 적은 것으로 나타났습니다.

Serum의 CPU 활용도는 생각보다 너무 과장되게 표현되었습니다. 또다른 인기 웨이브테이블 신디사이저인 Massive와 비교해 보더라도 Serum이 데스크탑과 노트북에서 모두 훨씬 좋은 CPU 활용도를 보여줍니다.

그렇긴 하지만, 128개의 동시발음을 한 것 만으로 Ableton의 CPU 미터가 20퍼센트에 도달했으며, 이는 한 개의 신디사이저가 내는 것 치고는 매우 막중한 작업입니다.

교훈은 간단합니다. 정말로 필요해서 그런 것이 아니라면, 동시발음수나 오버샘플링 정도를 무식하게 올리지 마세요. 한 악기에 32개의 동시발음도 전체적으로 보았을 때는 너무 과합니다. Duda는 음을 쌓거나 코드를 만들 때 Unison 설정 값으로 "7"을 추천합니다. 여러분의 CPU 수준은 매우 다양하겠지만, 명심하세요. 동시발음수 512개의 소리를 실시간으로 렌더링하는 것은 분명 CPU를 혹사시키는 일입니다. 

만약 정말로 당신이 동시발음수 수백개에 이펙트도 짱짱 많이 들어간 4x 오버샘플링 해야하는 정신나간 FM 패치가 필요하다면, Sam Leggett은 다음과 같은 방법을 제안합니다.

수많은 동시발음수를 쓰는 굵직한 사운드를 원하는 이들을 위한 해결방법 중 하나를 제안합니다. 우선 비교적 낮은 동시발음수로 코드 패턴을 쓰세요. 그다음 그 패턴을 음원 파일의 형태로 추출하세요.

Serum 상단의 메뉴를 보면 Osc A 또는 Osc B에 리샘플링하는 기능이 있습니다. 추출한 오디오 파일을 OSC A/B에 넣어 웨이브테이블로 만드세요. 그러니까 예를 들면, 16발음 unison에 약간의 디튠을 가한 소리를 추출해 다시 Osc A에 리샘플링 해서 단일 발음으로 만들 수 있습니다. 리샘플링 과정에서는 해당 오디오에 걸린 FX를 포함한 모든 것을 계산하기 때문에, 리샘플링을 할 때는, 패치를 초기화한 후 이 방식을 적용할 것을 권장합니다.

이제 Serum이 CPU 사용률을 치솟게 합니까? 라이젠 CPU로도 깨지는 소리가 납니까? CPU 사용량을 줄일 다른 방법이 있습니까? @rewakmusic에게 알려주세요!