none
ATOM CPU 타블렛에서 웹에 있는 MP3를 들으려고 하면 초반 0~5초 사이에 꼭 끊김현상이 발생합니다. RRS feed

  • 질문

  • 이 문제를 재현해 보실 수 있는 샘플 프로젝트가 있습니다.

    샘플 앱을 실행하시고,
    WebFile 파트에 있는, Play 버튼을 누르시면 재현이 가능합니다.

    저는 이 문제가 발생하는 것을 2대의 삼성 ATIV 기기에서 확인하였습니다.

    또 Acer W510을 가지고 계신 분에게도 요청을 드려 테스트해 본 결과를
    아래 공유합니다.

    "처음 빌드 후 실행했을 때에 잠깐끊기고 다시 플레이 버튼 누르면 정상실행되구요 매번 빌드할 때마다는 처음 끊김현상은 계속나타나네요^^."

    이 문제가 ATOM CPU를 쓰는 타블렛에서 공통적으로 나타나는 문제일까요?
    또는 저가형 모델에서 사용하는 SSD가 문제가 될까요?

    혹시 이 문제에 관련된 내용을 알고 계시거나, 웹 상에서 발견하신 분은 알려주시기를 부탁드려요.


    Do it yourself!, Slow and steady wins the race!


    • 편집됨 Gilbok Lee 2013년 4월 16일 화요일 오전 8:01
    2013년 4월 15일 월요일 오전 10:41

모든 응답

  • 샘플 프로젝트를 다운로드 받아서 테스트해보았습니다.
    마침 ATIV 태블릿 PC를 저희 팀에서 가지고 있어서 일반 노트북과 비교해볼 수 있었습니다.
    사용해본 바 일반적인 노트북 PC에서는 샘플 프로젝트로 재현이 안 되므로 시스템의 성능 문제로 귀결될 것 같습니다.

    하드웨어에 문제가 있다면 원인을 알기는 어려운데 하나씩 짚어보면 다음과 같습니다.

    CPU
    비록 ATOM 프로세서가 성능이 떨어지는 것으로 널리 알려져 있지만 mp3 파일의 스트리밍 하나 처리하지 못할 정도는 아닙니다. perfmon으로 본 바로도 파일 다운로드 시점에 CPU 사용율이 튀는 현상이 보이지 않았습니다.

    네트워크
    ATIV에 유선을 연결할 수 없는 환경이어서 테스트 시 둘 다 무선으로 맞추고 비교를 해보았습니다. 다운로드 속도는 유선보다 다소 떨어졌지만 다운로드 진행률은 비슷했으며 버퍼링이 멈추는 현상은 없었습니다. 그러나 ATIV는 끊김 현상이 관찰되었고 일반 노트북은 그렇지 않았습니다.

    SSD
    MediaElement.DownloadProgress를 가공해서 %로 화면에 다운로드 진행률을 표시하게 하고 관찰한 결과 ATIV쪽은 다운로드 100% 되기 직전에 한번 소리가 끊기는 현상이 발생하였습니다. 일반 노트북에서는 문제가 없었습니다 (SSD, HDD 모델 모두). 파일을 다운로드 완료하는 시점에 순간적으로 병목현상이 있는 것으로 보이는데, 하드웨어와 관련이 있다면 이것이 좀 가깝지 않나 싶은 것이 개인적인 추측입니다.

    다른 앱의 케이스
    Music 앱(Windows Store app), Windows Media Player(Desktop app)로는 문제가 재현되지 않았습니다. 그러므로 하드웨어적으로 어느 부분에 성능상 제약이 있을 수는 있지만 프로그램에서 커버할 수 있다는 뜻으로 받아들일 수 있습니다. 앞서 SSD란에서 설명한 것과 Acer 제품 쓰신분의 소감으로 미루어볼 때 버퍼링 처리를 어떻게 하느냐에 따라 문제 해소의 방안이 있지 않을까 싶습니다.

    2013년 4월 19일 금요일 오전 8:35
  • 안녕하세요! 전만우 연구원님, 답변 정말 감사드립니다.
    친절하게 많은 테스트와 분석을 해주셔서 감사합니다.

    그런데 마지막의 <다른 앱의 케이스와 그에 따른 결론>에는 위험성이 있습니다.
    '프로그램에서 커버할 수 있다'라는 의견을 'Windows Store App 개발 영역에서 해결할 수 있다'라는 뜻으로 오해를 할 수 있다고 봅니다.
    말씀하신대로 하드웨어 만의 문제는 아닐 수 있습니다. 대신에 API의 문제일 수도 있기 때문입니다.

    저는 이것이 명확해지기를 바라고 있습니다.

    한편, 해당 문제는 Web 상의 mp3를 스트리밍 재생하려고 할 때 발생합니다.
    언급하신 '다른 앱의 케이스'에서 제시한 'Music 앱'의 경우는 제가 못찾은 것인지, URL로 열기 기능은 없는 것 같습니다.
    그래서 제가 생각하기로는 Local File로 재생테스트를 하신 것으로 짐작합니다.
    따라서 이 앱에서 잘 재생된다고 해서 해당 문제를 <스토어앱 개발자>가 해소할 수 있다는 증거가 되지는 않는다고 봅니다.

    Windows Media Player(Desktop app) 앱 또한 Windows Runtime API를 사용하고 있지 않기 때문에 이 역시
    <스토어앱 개발자>가 해소할 수 있다는 증거가 되지는 않는다고 봅니다.

    윈도우 스토어 앱에서의 미디어 재생을 위해 마이크로소프트가 공식적으로 지원하고 있는 오픈소스 프로젝트인
    Player Framework에서도 이 문제는 해결하지 못하고 있습니다.

    제가 시도해 본 워크 어라운드는
    HttpClient를 이용해서 해당 MP3를 로컬저장소에 먼저 다운로드시켜 놓은 다음 재생하는 것이었습니다.
    이 경우 ATIV에서도 끊김이 없이 재생은 됩니다만, 고객사나 사용자들이 원하는 방식은 아니었습니다.
    3~10 메가의 파일을 다 받을 때까지 음악은 시작조차 안 하기 때문입니다.

    또한, API 영역 내에서 버퍼링을 어떻게 잘 처리해서 문제를 해결할 수 있을 것 같지 않아 보입니다.
    C#/XAML 윈도우 스토어 앱 API에서 버퍼링을 활용하여 mp3를 재생하는 인터페이스는 오로지
    MediaElement.Source에 Uri로 mp3의 웹경로를 전달하는 방법 뿐인 것 같은데요.

    여러가지 테스트를 해봤지만,

    지금 테스트에 사용하고 있는 mp3의 경우,
    CurrentStateChanged를 출력하며 실험해 본 결과

    <아티브 스마트PC>에서

    Opening Buffering Buffering Buffering Buffering Playing Buffering Playing

    <Microsoft Surface Pro, Microsoft Surface RT, 일반 PC>에서

    Opening Buffering Buffering Buffering Buffering Playing

    이런식으로 재생을 시작해버린 다음 다시 버퍼링을 시작하는 이상한 현상을
    <아티브 스마트PC>에서만 보이고 있었습니다.

    이 현상을 코드로 피해 갈 수 있는 해결책이 없는 것 같습니다.

    --------------------------------------------------------------------------------

    만약 H/W문제가 아니라면, 그리고 API 수준의 문제도 아니라고 하면,
    url만 알면 간단히 할 수 있는 MP3 스트리밍을 ATIV 기종때문에 어느 누가 '고비용'으로 구현하고 싶어할까요.
    가볍게 넘어가야 할 곳에서 개발자의 발목을 잡고 귀찮게 하는 API는 플랫폼의 크나 큰 단점이 되지 않을까요?

    저는 H/W문제이기를 기대하고 있습니다.
    삼성 측에서 문제를 공유했는데 아직 답변을 받지 못하였습니다.

    또, 스토어앱 개발자 차원에서 커버할 수 있는 문제라면,
    그 증거를 얻고 싶습니다.

     

     

     


    Do it yourself!, Slow and steady wins the race!




    • 편집됨 Gilbok Lee 2013년 4월 19일 금요일 오후 1:59
    2013년 4월 19일 금요일 오후 1:53
  • 저는 "결론"을 내린 적이 없습니다. 정황으로 보았을 때 프로그램 내에서 커버할 수 있다거나 방안이 있지 않을까 하는 사견을 밝혔었을 뿐입니다.

    우선 유사한 보고 사례를 전혀 찾아볼 수가 없다는 점, 일반 노트북에서는 문제가 없이 동작하는 점 등을 들어 일단 문제가 없다는 가정 하에 접근을 해보았었습니다. 하지만 구체적 "증거"에 대해서는 답을 드릴 수 없었습니다. 의견 다는 것을 포기하려던 찰나에 사무실에 ATIV가 있는 것을 뒤늦게 확인해서 이것 저것 새로 테스트를 해보느라고 시간이 없어서 말이죠.

    각설하고, 오늘에서야 이것 저것 테스트를 해보았는데 다른 언어(JavaScript)로 만들어본 샘플 및 Web URL에 접근해서 파일을 열 수 있는 스토어 상의 앱들은 동일한 문제를 가지고 있었습니다. 여기서 이것이 시스템 성능의 문제냐 WinRT 플랫폼의 문제냐는 다시 탐색을 해봐야겠습니다.

    참고로 궁금해하실 것 같아서... 로컬 파일 재생에서는 문제가 없다는 것은 이미 알고 있습니다.

    Music 앱에서 돌리는 것은 제가 Web URL에 있는 것을 접근했다고 착각을 한 거라 잊으셔도 되겠습니다.
    Modern IE10에서 URL을 입력하고 접근을 시도했었는데 이것은 다운로드 받고 실행하는 형태라 어차피 로컬 파일 재생과 다를 바가 없으니까요.

    2013년 4월 22일 월요일 오전 9:29
  • 추가 답변 감사드립니다!

    Do it yourself!, Slow and steady wins the race!

    2013년 4월 26일 금요일 오전 7:49