버퍼사이즈와 레이턴시... ETC.

(집에 냉장고가 없는) 인천의 김모씨는 정오부터 자정까지 시원한 맥주를 한 시간마다 한 캔씩 마시고 싶었습니다.

그래서 알람을 설정해두고 한 시간마다 한 캔씩 배송 주문을 했어요.

그런데 배달기사 아저씨는 바쁜데 그렇게 자주 왔다 갔다 할 수 없어서 화가 납니다.

그래서 자정에 12캔을 묶어서 문앞에 던져두고 갔습니다. 

배달기사 아저씨는 업무부하가 크게 줄어들어 기뻤습니다. 

여기서 배달기사 아저씨는 CPU나 시스템 프로세스의 부하를 의미하고

김모씨의 음주계획은 정해진 시간에 필요한 자원을 공급받고자 하는 시간축의 해상도(=샘플레이트:Sample Rate)에 있어서의 조달계획을 말하는데 여기에 시간지연(=레이턴시:Latency)이 발생한 것입니다.

묶음배송을 하면 시스템 부하는 줄어들지만 원하는 시간단위로 자원을 공급받지 못하고

낱개로 배송을 하면 구매자는 레이턴시없이 자원을 공급받을 수 있지만 배송시스템에 부하가 커져서 소화하지 못하는 수준이 되면 파업을 할 수도 있습니다. 그래서 배송업체에서는 묶음배송을 유도하기 위해 할인서비스를 넣기도 합니다.

그래서 아주 낮은 레이턴시를 요하지 않는 믹싱 같은 작업에서는 다 한 번에 묶어서 배송해주세요 라고 말하는 것입니다.

=================

컴퓨터에 밝은 분들은 음향장비에서 이야기하는 버퍼(Buffer) 사이즈나 워드클럭(Wordclock) 동기(Sync)라는 표현을 컴퓨터 내부의 동작방식을 연상하면 쉽게 이해할 수 있을 것입니다.

아날로그 딜레이에도 버킷브리게이드(Bucket Brigade)라는 방식이 있는데, 우물에서 불이 난 장소까지 물을 퍼나르기 위해서 100명 정도의 사람들이 줄지어 서서 양동이를 손에서 손으로 나르는 방식입니다. 이 양동이 하나를 데이터의 한 단위라고 생각합시다. 비트(Bit)일 수도 있고 니블(Nibble)일 수도 있습니다. 크기는 어쨌든 그게 가장 작은 단위라고 보는 겁니다.

컴퓨터 부품 중에서는 아무래도 CPU가 가장 빠른 클럭으로 동작합니다. 그래서 CPU가 몇메가헤르츠(MHz)라든가 몇기가헤르츠(GHz)와 같은 마스터클럭을 제공합니다. 그런 엄청난 속도로 양동이를 하나씩 전달해줄 수 있는 것입니다. 그런데 상대적으로 CPU보다 동작클럭이 느린 RAM이나 HDD는 물론 그 속도로 양동이를 받을 수 없습니다. CPU가 1초당 양동이 3개를 보내줄 수 있는데 RAM은 2개만 받을 수 있다면, 타이밍이 손발이 안맞기 때문에 심지어 2개도 아닌 1초당 1개씩 운반되는 상황이 됩니다. 그러면 마더보드(Mother Board)가 하는 일은 CPU의 클럭(마스터클럭)을 기준으로 CPU와 RAM의 동작클럭을 초당 1양동이로 맞춰주는 것입니다.

메모리의 속도를 이야기할 때 버스(Bus)나 대역폭(Bandwidth)을 들어보신 적이 있을텐데, 여기서 RAM이 힘센 팔이 3개가 달려서 한 번에 양동이 3개를 들어 올릴 수 있습니다. 그렇지만 초당 3번이나 나누어 움직일 만큼 빠르지는 못합니다. 그러면 CPU는 초당 3 양동이의 속도로 데이터를 전달하되, 마더보드 어딘가의 보관함(Buffer)에 넣어둘 수 있다면 3개가 모였을 때 RAM이 초당 3양동이묶음의 속도로 가져갈 수 있습니다. (앞에서 이야기한대로 0.5초당 한 번이라면 초당 6양동이의 계산입니다만)

이 보관함이 버퍼입니다.

만일 버퍼사이즈가 적절하지 않게 설정되면, 가령 버퍼사이즈가 지나치게 크거나 작으면 이 양쪽 장치들이 정해진 시간단위당 처리할 수 있는 데이터의 크기와 맞지 않는 부분이 생기므로 일부 데이터가 유실됩니다. 음향기기에서는 이것이 시간축에서는 지터(Jitter)가 되고 프리퀀시나 다이나믹스의 해상도에서 일부데이터가 소실되면 해당부분이 사라질 뿐만 아니라 그 전후의 데이터가 밀고 당기기를 해서 메우는 과정에서 왜곡이 발생하고 예상외의 파형이 만들어지기도 합니다. 그래서 우리는 디더링(Dithering)을 하게 됩니다.

컴퓨터와 컴퓨터 2대를 랜이나 블루투스나 USB나 뭐든간에 연결방법을 사용해서 연결을 해서 서로 통신하게 하려고 합니다. 이러한 기기외부의 접속방식을 사용하는 통신에서는 패킷(Packet)이라는 표현을 들어보신 분도 계실텐데 이 패킷사이즈가 버퍼사이즈에 해당합니다. 컴퓨터와 컴퓨터 사이의 아날로그 접속 통신에서는 클럭을 맞추는 것은 아니지만 이 패킷사이즈를 단위로 상품을 묶어서 전달을 하고, 물건이 잘 전달되었는지를 전화를 해서 "방금 10KB짜리 한덩어리 보냈습니다" 혹은 "방금 10KB짜리 36묶음 보냈습니다"와 같이 확인을 합니다. 그러면 받은 쪽에서는 상품을 비트단위로 일일이 검수하지는 않고 무게만 재보고 "맞네요"라고 하고 확인을 해줍니다. 만일 "방금 받은건 8KB인데요, 잘못온거 같으니 그것만 다시 보내주세요."라고 요청합니다. 이것이 "에러체크"입니다. 이 에러체크에서 유실이 확인되고 재전송을 자주 해야 하면 데이터 전송속도가 느려집니다. 여러분의 인터넷이나 뭔가의 속도가 사양서에 적힌 속도가 안 나오는 이유 중의 하나입니다. 통신품질이 나쁜겁니다.

그리고 이번에는 두 기기간의 클럭을 맞추어서, 앞의 예와 같이 2개 기기가 서로 공유할 수 있는 속도의 클럭을 맞추기 위해 동기화하여 패킷의 덩어리를 주고 받습니다. 이 패킷의 사이즈를 크게 하면 양쪽 장치의 입출력단에서는 한참 빈둥거리다가 갑자기 큰 것이 하나 들어오면 "영차" 하고 들어다가 던져놓으면 됩니다. 반대로 패킷 사이즈를 잘게 나누어 작게 하면 찰리채플린의 영화의 한 장면처럼 들어오는 상품의 입출력의 속도를 도저히 맞출 수 없게 되어 몰래 한두개를 뒤로 버려버리기도 합니다.

믹싱에서 버퍼사이즈가 커도 되는 이유는 실시간으로 데이터를 처리하면서 들어볼 필요가 없기 때문입니다. 헐리웃 영화에서 컴퓨터 그래픽으로 10초 분량의 엄청난 영상을 6개월동안 만들어서 10시간 동안 렌더링해도 되는 것과 비슷합니다. 결과물 10초가 만들어지기만 하면 되기 때문에 최대한 노력해서 텍스처나 빛의 반사나 여러가지 할 수 있는 기술을 다 쏟아 넣습니다.

레코딩을 할 때 버퍼사이즈를 가능한 줄여서 레이턴시를 낮추어야 하는 이유는 물론 실시간으로 자신의 퍼포먼스를 듣고 확인하면서 녹음해야 하기 때문입니다. 최근 3D 게임소프트웨어는 영화 못지 않은 대단한 영상미를 보여주지만 사실상 영화와는 영상의 품질차이가 꽤 있습니다. 플레이어의 조작을 실시간으로 받아 실시간으로 레이턴시 없이 텍스처의 빛의 각도나 반사, 그림자, 소리의 반사라든가 이런 요소들을 모두 계산하여 결과를 보여줘야 하기 때문에 현시대에 일반적으로 사용되는 시스템의 속도로 실시간 처리되기 어려운 내용들은 모두 생략할 수밖에 없습니다. 그 범위 내에서 최대의 효과를 보여주는 쪽으로 발전합니다.