리눅스를 처음 설치할 때 깜짝 놀라게 되는 것중 하나가

"왜 리눅스에는 사운드 API가 이렇게나 많은걸까?" 라는 것입니다.



사실 잘 뜯어보면 API와 디바이스 드라이버를 분리하지 않고 뭉뚱그려서 언급하기 때문에 혼돈이 생기기 마련입니다.



결과적으로 말해 리눅스에서 디바이스 드라이버를 포함하고 있는 것은 딱 3개뿐입니다.



첫번째가 ALSA

두번째가 OSS

세번째가 FFADO



오디오 하드웨어를 직접 컨트롤할 수 있는 것은 이 3개가 유일합니다.



먼저 FFADO는 리눅스의 유일한 Firewire 드라이버로 1394 장비를 쓰는 분들은 달리 선택사항이 없습니다.

ALSA나 OSS는 1394 드라이버를 전혀 가지고 있지 않을 뿐더러 개발 계획도 없습니다.



원래 리눅스 커널 2.4까지는 OSS가 커널에 올라간 유일한 API였습니다.

Unix 계열에 널리 채택된 OSS는 v3까지 공개였다가 상용으로 바뀌게 되면서 많은 비난을 받게 되었고

리눅스 커널 2.6에서는 OSS를 빼고 ALSA로 대체했습니다. 이때가 2003년말입니다.

그때 이후로 지금까지 OSS는 "deprecated"로 표기가 되고 있습니다.

말 그대로 사용을 반대한다는 뜻입니다. (쓰려면 돈을 내야 하기 때문에...)

뭔가 새로운 버전이 생겨나서 낡은 버전이 되었다는 'obsolete'와는 사뭇 성격이 다릅니다.



처음 ALSA가 등장했을 무렵만 해도 꽤 많은 사람들이 완벽한 API가 정치적인 이유로 배척당했으며 ALSA같은 쓰레기 API는 커널에서 빼버려야 한다고 비난을 하기도 했습니다.

당연히 오랜 시간 안정화가 된 OSS와 비교해서 ALSA는 초기단계인데다가 개발자들이 프로그래밍하는데 참고해야할 문서들이 제대로 갖춰지지 않았기 때문에 욕을 많이 먹었습니다.

그러나 시간이 흘러 ALSA에서 지원하는 드라이버가 늘어나고 안정화를 거치면서 현재는 이미 OSS를 완전히 대체하게 되었습니다.



리눅스에서 사그러들던 OSS가 완전히 버려진 것은 아니었습니다.

OSS가 너무 구식에다가 모듈화가 안되었고 모던한 커널과 맞지 않는다는 비난을 받자 이를 보완해서 OSS v4로 진화하였습니다.

현재 OSS라고 한다면 v4를 언급하는 것이고 이전의 OSS를 FreeOSS 혹은 OSS v3라고 부릅니다.



그러나 이미 커널에서 삭제되어 시간이 흘러흘러 OSS는 이미 돌아올 수 없는 강을 건널 지경이 되었습니다. (사실상 이미 건넜습니다만)

그동안 ALSA가 착실히 그 자리를 완전히 대체해버렸기 때문입니다.

심지어 개발이 오래된 프로그램들은 기본 사운드출력을 ALSA로 바꾸게 되었고 오히려 OSS를 지원하기 위해 사용자가 뭔가 셋팅을 바꿔야 하는 수고로움이 생기게 되었습니다.

게다가 그놈이나 대표적인 GUI 환경의 기본 사운드 출력도 ALSA로 바뀌게 되면서

절대 다수의 사용자가 굳이 OSS를 써야할 이유가 사라져버리게 되었습니다.



이런 상황에 이르러 2007년에는 소리소문도 없이 OSS가 다시 공개로 돌아서게 되었습니다.

그런데 상용이던 프로그램이 공개로 풀리는 경우는 대부분 개발자가 손을 놓을 것이니

필요하면 '알아서 고쳐쓰라'는 암시적인 의미가 있습니다.



실제로 2007~8년 무렵 OSS 개발자는 개인 블로그에서 자신은 부양해야 할 가족이 있다면서 필요하면 사용자가 고쳐서 쓰라는 메시지를 던집니다.

또한 커널 포럼에서는 ALSA나 OSS나 디바이스 드라이버를 공유할 수 있는 부분이 있으니 함께 발전했으면 한다는 바람을 피력한 바가 있습니다만...

리눅스 세계에서 시간이 흐를수록 OSS는 어떻게 될지 미래를 기약할 수가 없게 되었습니다.



가장 대표적인 배포판인 우분투의 경우는 OSS에 대한 모든 지원 중단을 선언했고,

그놈을 사용하는 배포판은 거의 같은 운명이라고 생각하시면 됩니다.

발표주기가 엄청나게 짧은 그놈을 쓰는 페도라도 비슷하다고 보시면 됩니다.



사실 OSS가 죽은 것은 결코 아니며 까마득한 예전에 OSS를 지원하던 프로그램은 여전히 계속 OSS를 지원합니다.

배포판에서 지원을 중단해도 사용자가 원하면 얼마든지 커널에 올리고 사용하면 됩니다.

단지 어떤 문제가 생겼을 때에 해결이 쉽지 않다는 한계가 있을뿐입니다.

FreeBSD 같은 경우 진작에 OSS를 변형한 API를 사용하고 있기도 하구요.



여기까지가 OSS와 ALSA의 발전 역사입니다.



관심있으신 분들은 찾아보시면 ALSA와 OSS를 비교하는 글을 검색하실 수 있는데,

그 어디에서도 OSS의 음질이 더 뛰어난 근거를 찾을 수는 없습니다.

(언제나 그렇듯이 개발자조차도 음질이 더 뛰어나다는 얘기를 절대 안함)



다만 프로그램 개발자 입장에서 문서작업이 잘 되어 있어서 개발자들이 개발하기에 편리하다는 것과

API 자체가 믹서를 끼고 있어서 비스타처럼 어플리케이션별로 볼륨 조절이 가능하다는 것

유닉스 계열에 사용되어서 포팅이 더 유리하다는 점 (ALSA는 리눅스 only)

이 3가지 외에는 우위에 있는게 없습니다.



흔히 OSS는 로우레벨에서 하드웨어를 제어하기 때문에 음질에 더 유리하다는 얘기를 하는데 그건 잘못 알려진 사실입니다.

하드웨어를 직접 컨트롤하는 디바이스 드라이버를 제공하는 것은 ALSA도 마찬가지이고

앞에서도 잠깐 언급했지만 구버전의 OSS는 API 자체가 가상화나 쓰레드 단위의 프로그래밍에 불리한 정반대의 단점도 있습니다.



결정적으로 OSS가 ALSA를 대체하지 못하는 이유중 하나가...

OSS는 ALSA만큼 USB 기기를 제대로 지원하는 드라이버가 만들어지지 않았습니다.

(OSS는 아직도 베타수준에다가 만들어질지 아닌지 기약도 없습니다)

부가적으로 블루투스 드라이버도 ALSA에만 존재하며 OSS는 미디지원도 부실합니다.



참고로 사운드카드가 과거 하드웨어 믹서 탑재에서 믹서 생략으로 바뀌는 추세와 더불어 OSS와 ALSA가 믹싱 부분에서 좀 차이가 있습니다.

OSS의 장점중 하나가 이 믹싱이 기본으로 탑재되어 있어서 어플리케이션별로 볼륨 조절이 가능하다는 것입니다만 (비스타와 XP의 차이를 생각하시면 됩니다)

이부분은 재미있는게 믹서의 존재 자체를 싫어하면서도 OSS를 좋아하는 유저들은 잘 언급을 안하는 부분이기도 합니다.



반면 ALSA는 물론 소프트웨어 믹서가 존재하기는 합니다만,

어플리케이션별로 볼륨을 적용할 때에는 다른 사운드 API(가령 펄스오디오)를 사용합니다.



사실 이 믹서부분이 리눅스 API에 복잡하게 얽혀있는 부분으로 제 능력으로 다 설명을 못합니다.



재미로 읽으시라고 쓰는 글이지만, 이것만 기억하십시오.



1) 리눅스에서 디바이스 드라이버를 포함한 API는 딱 3개 뿐이라는 것 (ALSA/OSS/FFADO)

2) 1394 장비 사용자는 다른 대안없이 FFADO를 쓸 수밖에 없다는 것

3) 리눅스 커널에 올라간 기본 사운드 API는 ALSA라는 것

4) OSS는 현재의 리눅스 커널에서 빠져있고, 그 미래를 기약할 수 없다는 것



마지막으로 OSS나 ALSA나 디바이스 드라이버를 제외하고 소리 출력을 위한 API를 가지고 있는데도 리눅스에는 왜 이렇게 API가 많은지에 대해 언급하겠습니다.



결론적으로 말해 쓰임새가 다르기 때문입니다.



가령 펄스 오디오 같은 것은 스트리밍에 특화된 API 입니다.

즉 내가 사용중인 PC의 소리를 다른 PC로도 출력하고 싶을 때에는 펄스 오디오를 사용하면 편리합니다.

JACK 은 프로페셔널 오디오의 사용을 위해 만들어진 API로 녹음작업시 레이턴시를 최적화할 수 있고 패치베이같이 어플리케이션의 소리 출력을 다른 어플리케이션의 입력으로 연결해주는 기능이 있습니다.



위의 두가지는 용도가 분명한 API이고,

일부는 물론 API 이지만 프레임워크로 분류해야 하는 것이 있습니다.

가령 Gstreamer 같은 것은 프레임워크의 대표격입니다.

간단히 말해 Gstreamer는 윈도우즈의 DirectShow나 OSX의 퀵타임같은 것입니다.



비유를 하자면 프레임워크는 붕어빵을 찍어내는 틀과 같습니다.

프로그램을 만드는 사람은 이미 만들어진 붕어빵 틀에다가 재료만 넣어주면 자동으로 붕어빵이 완성됩니다.

회사에서 프레임워크란 용어를 접하셨을 수도 있는데 같은 개념입니다.

업무의 흐름을 자기 맘대로 정하는게 아니라 정해진 프로세스(프레임워크)에 의해서 진행하는 것과 마찬가지입니다.



가령 FLAC을 정해놓은 프레임워크로 처리하는 경우

예를 들어 FLAC 파일을 입력하면 디코더가 PCM으로 변환하고 DSP를 거쳐서 ALSA로 사운드를 출력하는 것이 순차적으로 처리되게 됩니다.

이런 프레임워크를 마치 API가 중복되어 출력되니 음질적으로 좋지 못하다라고 생각하시면 안됩니다.

프로그래머는 프레임워크를 쓸 때 디코더를 따로 개발할 필요가 없거니와 뭔가 다른 사람이 만들어놓은 DSP를 적용할 때 그냥 끌어다 쓰면 되기 때문에 확장성이 커지면서 동시에 프로그램 개발 시간을 단축할 수 있기도 합니다.