|
그러게요.
cplay는 안써봤고, jriver와 foobar를 번갈아서 써보면 얼핏 차이가 느껴지고, 자세히 들어보면 아닌거 같고. 계속 틀어놓고 있다 보면 또 차이가 있고. 그렇더란 말이죠.
동일머신에 우분투를 설치해서 들어보면 차이가 꽤 크게 나타나고 말이죠.
데이터는 똑 같은데!
이거 설명하자고 하면 갑자기 사이비로 몰릴거 같은 불길한 예감이 되네요. ㅋ
다음은 저의 소설이니 그것을 fact로 받아들이진 말아주세요.
자신의 소리가 뭔가 마음에 들지 않을 때, 돈 한푼 안들이고 효과를 볼 수도 있습니다.
1.
플레이어가 음원을 플레이해서 output device에 출력할 때, 가장 중요한 것은 cpu 이며, cpu는 주변 device를 돌아가면서 컨트롤합니다.
아무 일 안하고 재생소프트웨어만 플레이하는 경우라도 OS는 백그라운드에서 여러가지 일을 하며, 그것을 위해 cpu는 돌아가면서 실행을 시킵니다.
그러나 cpu는 매우 고속이므로 나머지 느린 디바이스에 비해 병목이 발생할 일이 별로 없습니다.
병목은 보통 device 자체에서 발생시킵니다.
병목이 발생하는 device로 인해 음악재생소프트웨어가 적절한 시점에 연산이 처리되지 않을 수도 있습니다.
이것은 dpc latency 라는 유틸리티로 확인이 가능하며 ratency가 갑자기 튄다면 음악재생프로그램이 적절한 시점에 데이터를 출력하지 못하는 drop-out이 발생할 수 있습니다. 확연하게는 음악이 멈출 수 있으며, 미묘하게는 음상이 흔들린다거나 할 수도 있습니다.
이런 경우에는 dpc latency를 띄워놓고 device를 하나씩 제거함으로써 문제를 해결할 수 있습니다.
사용자마다 다르지만, 네트웍 device가 이러한 drop-out의 주체라면 랜선 뽑았더니 음질이 좋아졌어요. 할 수도 있겠죠.
2.
cpu는 하나인데, 동시에 여러가지 일을 처리하는 것을 멀티 프로세싱이라고 합니다.
서버는 cpu의 갯수만큼 실제로 멀티 프로세싱이 가능하지만, pc는 진정한 멀티 프로세싱을 하는 것이 아닌, 멀티 스레딩을 합니다. 인텔의 하이퍼 스레딩 기술도 그렇습니다. 보다 전문적인 내용은 skip.
어쨌든. 음악 재생 소프트웨어는 real-time으로 계속 프로세싱이 진행되어야 하는데, 자세히 까보면 예를 들면, DAC에게 1초에 해당하는 PCM을 0.1초만에 보내놓고 대기 해야하는 동안 cpu가 지맘대로 다른 일을 처리해버린단 말이죠.
문제는 정확히 0.9초 후에 음악 재생 소프트웨어가 재생이 재게되지 않을 수도 있다는 것입니다.
그렇게 구현하려면 OS가 cpu의 클럭이 아닌 진짜 RTC에게서 시간 정보를 받아올 수 있어야 하고, 이 시간 정보를 정확히 지정된 시간에 보내주는 것이 다른 모든 것보다 우선해야 하며, real-time을 제공받길 원하는 소프트웨어는 이것을 언제 받을지 매번 지정해줘야 합니다. 0.9초 마다 지정하는거라면. 흠. 그런대로 돌아갈겁니다.
0.1초로 지정해주면 평범한 PC는 뻗습니다.
왜냐면 0.1초 텀의 delay의 시간 동안 다른걸 처리해야 하는데. 그걸 처리하려고 한 순간 다시 0.1 텀이 돌아와버리기 때문입니다.
0.1초도 그러한데, 0.01초는. 뻔하겠죠.
(10년 전에 해본겁니다. 요즘 PC는 0.1초도 스무스하게 처리할지도 모르죠. 중요한건 맥락이니 별도로 다시 테스트해보진 않겠습니다.)
그러므로. PC에서 RT는 그다지 효과가 없는 것입니다.
이러한 프로세스를 별도의 칩으로 넘기고 지 혼자 알아서 하거나, cpu가 real하게 2개를 두고, 하나는 재생 소프트웨어에게 전담시키고 나머지 하나로 일반적인 처리를 하게 해야겠죠.
(리얼타임OS가 없냐면. 그건 아닙니다. 겁나게 비쌉니다. 몇천 수준이 아니라 몇십억 수준입니다. 국내에선 만드는 회사도 없고. 전세계로 쳐도 HP나 IBM 정도나 만들어냅니다. 국내에선 금융기관에서도 특정한 부분에서만 사용하고. 나머지 공항이나 항만 쪽에서도 사용할 거 같긴 한데 모르겠습니다. 그쪽에선 일을 안해봐서요. 리눅스가 RT kernel을 제공한다고 해서 그게 정말 RT로 돈다고 생각하면 곤란합니다. 하드웨어가 받쳐줘야 합니다. 왜 그런지는 위에서 설명했습니다. 이해가 안되셔도 더 이상의 설명은 곤란합니다. 저도 제 시간 투자해서 적고 있는건데 벌써 30분 넘어갔습니다. 이해가 꼭 중요한건 아니잖아요. 그냥 그런갑다 해주세요. ㅠㅠ)
그러므로.
죽자고 cpu가 나만 바라보게 해야합니다.
다른건 왠만하면 딜레이 시켜야 합니다.
그렇게 하는걸 우선권이라고 하며, 가장 탐욕적으로 우선권을 차지하는게 가능한게 MS의 OS입니다. 선점형 멀티 태스킹이라는 기술이 그것입니다.
보통 프로그램 작성에서 우선권 제어하면서 프로그램을 작성하는 경우는 거의 없습니다. foobar가 그러합니다.
cplay는 우선권 처리를 했다고 하던데 확인해보지 않았습니다.
jriver는 우선권 처리를 세심하게 하는 것 같습니다.
그래서 jriver가 foobar보다 짱 좋냐.
대신 jriver는 한 프로세스에 상당히 비대한 기능을 집어넣었습니다.
foobar는 간단합니다.
비대한 기능 또한 cpu 연산을 차지하며, 간단한 프로그램은 cpu 연산을 적게 차지하며, cpu가 다른 일을 보다 수월하게 처리할 수 있게 해줍니다.
결국. 간단하면서 우선권을 잡고 왠만하면 잘 안 놓는 프로그램이 유리하겠죠.
이 의미는 jriver 실행시키면 이상하게 마우스 포인터 이동이 느려지고, 타이핑한게 1초 후에 화면에 떠요. 왜그러죠. 와 같은 현상이 발생될 수도 있다는 것과 같은 의미입니다. 유리하긴 한데 못써먹을 수도 있는 프로그램이 되는거죠.
이것을 의도적으로 조정하는 유틸리티가 있습니다.
high fidelity였던가요. 제가 pc-fi 게시판에 소개했었던건데요. 다운받아서 써보시는 것도 괜찮겠죠.
3. 여기까지가 usb adaptive mode일 경우입니다. 광/동 출력도 마찬가지입니다.
다 해당되는 얘기입니다.
문제는 usb async mode의 경우 위의 사항의 중요성이 떨어지며, aync mode를 구현한 DAC이 cpu와는 완전히 별개로 작동하도록 구현이 되면. 그다지 설득력이 없겠죠.
DD-1이나 MA-1을 들이고나서 비교하면서 테스트해봐야 하는데. 안해봤습니다.
제 귀에 듣기 좋으면 그걸로 땡인 주의라서요.
누군가 민감한 청각의 소유자 분께서 확인해봐주시면 좋겠는데 말이죠.
4. 그럼에도 차이가 난다면.
남은건 구현체를 발로 구현했거나.
(말이 쉽지. 제대로 구현한다는 것은 언제나 어려운 일입니다.)
어차피 선들이 전기로 엮여 있으니 그냥 전기적인 신호 잡음이 소자들에게 영향을 미쳐서 음질에 차이가 나는 것 같더라. 로 퉁쳐서 생각할랍니다.
이러한 문제에 대한 해결책도 곧 나오겠죠.
디지털 도메인의 문제는 시장만 커지면 매우 빠르게 기술이 발전하는 경향이 있으니까요.
김중호님께서 2011-11-16 11:11:07에 쓰신 내용입니다
: 인가요............
:
: 그게 또 궁금해지네요
:
:
: 아날로그 파형은 dac에서 만들어지고
:
: 2진의 파일은 pc에서 usb케이블로 보내지는데
:
:
: 어느 한정된 프로토콜로 보내져야지 dac에서 받아 들일 수 있는 것 아닙니까??
:
: 한정된 프로토콜로 보내지는데
:
: j리버 / 푸바 / cplay 등등은 왜 차이를 보일까요?
:
: 여기서 말하는건 그냥 알송급의 플레이어들과 위에서 언급한 플레이어간의 차이를 묻고 싶은게 아니라
:
: 비트 퍼펙트가 충분히 지원되는 상황에서 할 것 다 해주는 플레이어들이
:
: 음질의 차이를 보이는 것이 궁금합니다.
:
: 그렇다고 01 로 된 2진의 음원파일을 전송할때 착색하기 위해서 본음원은 건드리지
: 않을 것 이라고 생각 됩니다. (본음원을 건드린다면 이글은 바로 삭제를 해야겠네요)
:
|
제목
