음악을 PCM 샘플로 디코딩하고 테이프 이동과 이펙트 랙을 거쳐 Android 오디오 출력으로 보냅니다. 시스템과 이어폰에서도 대기, 리샘플링 또는 인코딩이 일어날 수 있습니다. 한 버퍼의 크기는 손가락 조작부터 소리가 들릴 때까지의 전체 지연이 아닙니다.

PCM 프레임은 같은 시점의 모든 채널 샘플을 담고, 처리 블록은 여러 오디오 프레임을 묶습니다. 프레임 수를 시간으로 바꾸려면 샘플레이트가 필요합니다. 화면 프레임률이나 처리 블록 하나를 그대로 청감 지연으로 볼 수 없습니다.

실시간 조작에는 유선 이어폰을 권장합니다. 개발자 테스트에서는 유선으로 바꾸자 Bluetooth 경로에서 들리던 휠과 흔들림 조작의 뚜렷한 지연이 해결됐습니다. 실제 반응은 휴대폰, 시스템과 출력 기기에 따라 달라집니다.

전경 출력은 기기의 최소 버퍼 요구량을 하한으로 삼고 약 30 ms의 요청량을 함께 적용해 출력 대기열을 줄입니다. 테이프 조작이 이후 소리에 더 빨리 반영되도록 하기 위한 방식입니다.

재생은 최대 네 개의 미리 읽기 창과 필요에 따라 사용하는 최대 16 MiB의 디코딩 재사용 캐시를 사용합니다. 반복 디코딩을 줄이면서 메모리 사용을 제한합니다. 곡 전체나 그만큼의 데이터를 이어폰 출력 대기열에 넣는다는 뜻은 아닙니다.

미리 읽기 범위, 디코딩 결과 캐시와 출력 기기 버퍼는 역할이 다릅니다. 이 단계를 구분하지 않고 메모리 용량을 실제 출력 지연으로 곧바로 환산할 수 없습니다.

이펙트 체인은 오디오 블록 경계에서 갱신하며 약 20 ms 동안 이전 체인과 새 체인을 전환해 소리를 잇습니다. 이때 처리 부하가 잠시 늘 수 있지만 이것만으로 잡음의 원인을 단정할 수는 없습니다. Android가 블록 일부만 받으면 이미 처리한 나머지를 이어서 보내며 이펙트를 중복 적용하지 않습니다.

바이패스는 들리는 결과를 바꾸지만 인스턴스는 상태 유지를 위해 계속 연산합니다. 처리 부하를 줄이려면 당장 필요 없는 인스턴스를 제거하세요.

지직거림이 생기면 체인 출력 피크를 확인하고 지나친 이펙트 게인을 낮춰 진폭 클리핑을 살펴보세요. 이어서 불필요한 이펙트를 제거해 처리 부하를 비교하세요. 오디오 공급이 재생을 따라가지 못하는 버퍼 부족과 과도한 피크의 클리핑은 다른 문제입니다. 과부하 표시등은 피크를 나타내며 버퍼 부족을 확인해 주지 않습니다. 이 과정은 범위를 좁힐 뿐 확정 진단은 아닙니다.

백그라운드에서는 정상 1배속으로 PCM을 묶어서 제출하고 랙 처리는 유지합니다. 빈 랙은 약 200 ms, 이펙트가 있는 랙은 약 600 ms 버퍼를 요청하며 할당된 용량의 제한을 받습니다.

더 큰 백그라운드 버퍼는 시스템 스케줄링 변동을 흡수할 여유를 줍니다. 처리가 계속 재생 속도를 따라가지 못하면 여전히 언더런이 발생할 수 있습니다. 전경으로 돌아오면 작은 버퍼 설정으로 복구되지만 이미 대기열에 들어간 소리는 소모되어야 합니다.

휠 그리기는 최신 상태만 유지하고 대기 중인 그리기를 최대 하나로 제한해 오래된 상태가 쌓이지 않도록 합니다. 화면 갱신과 오디오 출력은 별도 경로입니다. Bluetooth의 가청 지연으로 화면 프레임 손실을 직접 설명할 수는 없습니다.

앱이 백그라운드로 전환되거나 화면이 꺼지거나 해당 기능을 끄면 관련 방향 센서 읽기와 감시를 중단합니다. 동적 반사는 빛을 바꾸고 소리는 바꾸지 않습니다. 흔들림 시뮬레이션의 소리 변화는 별도 스위치로 제어합니다.

현재 공개한 내용은 유선과 Bluetooth 출력에 대한 개발자의 정성적 관찰입니다. 전체 조건을 기록한 재현 가능한 종단 간 지연, 처리 부하 또는 소비 전력 수치는 아직 공개하지 않았습니다.

비교에는 휴대폰 모델, 시스템 버전, 출력 기기와 연결 방식, 샘플레이트, 효과 체인, 동일한 시험 구간이 필요합니다. 요청량과 버퍼 목표는 실측을 대신할 수 없습니다. 열 개의 슬롯은 구성 용량이며, 모든 조합의 원활한 실행이나 고정 지연, 일정한 절전율을 보장하지 않습니다.