KONA LinuxのDiretta ALSA bridgeで確認したbuffer capacity挙動について
まいまいオーディオ
さて、その開発過程で、KONA Linux の Diretta ALSA bridge のMMAP対応について、再生またはALSAデバイスのprobe後に、次回OPEN時のPCM buffer capacityが前回ストリームのbuffer sizeまで縮小する現象を実機で確認しました。
MaiMai Audio LinuxでHQPlayer NAA + Diretta ALSA MMAPの対応を検証中にこの現象を発見し、原因を追ったところKONA Linux側でも同じ状態遷移を再現できました。
MaiMai側ではbuffer capacityとactive buffer sizeを分離する修正を行い、MMAPでの実再生を含めて問題が解消していることまで確認できています。
■ KONA Linuxで確認した現象
通常起動後にDiretta ALSAをprobeすると、
period_size_max = 220
periods_max = 32
buffer_size_max = 882
となっていました。
最初はログイン時の起動音を疑い、ログイン音を完全に無効化して再起動しましたが、220 / 882のままでした。
次にログイン音を無効にしたままPulseAudioのservice/socketもmaskし、PulseAudioを起動させない状態で再起動しました。
するとfresh boot後の最初のALSA OPENでは、
period_size_max = 4800
periods_max = 32
buffer_size_max = 153600
まで正常に戻りました。
さらにこのfreshな状態から、ログイン音を無効のままPulseAudioだけを起動し、その後PulseAudioを停止して再度probeすると、
period_size_max = 220
periods_max = 32
buffer_size_max = 882
へ再び縮小しました。
つまりKONA実機上で、
fresh boot / PulseAudioなし
4800 / 153600
↓
PulseAudioのみ起動
↓
PulseAudio停止
↓
220 / 882
というA/B再現が成立しました。
このことから、PulseAudioそのものが根本原因ではなく、ALSAデバイスをOPEN/probeすることでbuffer state leakを発火させるクライアントになっているように見えます。
この状態が残ると、その後MMAPでPCMをOPENした際にも、縮小した値がDMA area capacityとして使われるため、MMAP再生時に大きな影響が出ると考えています。
■ ソース上で気になった箇所
KONA側の
/usr/local/etc/kona/update/diretta/alsa_bridge.c
を確認すると、playback_open() に、
substream->runtime->dma_area = node->buffer;
substream->runtime->dma_bytes = node->bufuse;
があります。
一方、prepare() では、
node->bufuse =
node->info->bufuse =
frames_to_bytes(runtime, runtime->buffer_size);
となっています。
このため node->bufuse が、
・現在ストリームで実際に使用するring buffer size
・次回OPEN時のDMA area capacity
の2つの意味を兼用しているように見えました。
playback_close() では node->bufuse を元のallocation capacityへ戻す処理も見当たりませんでした。
そのため、
PREPARE
node->bufuse = active buffer size
↓
CLOSE
↓
次回OPEN
runtime->dma_bytes = node->bufuse
となり、前回ストリームのactive buffer sizeが次回OPENのDMA capacityとして引き継がれているのではないかと考えました。
MMAPではALSA coreがruntime->dma_area / dma_bytesをmapping可能領域として扱うため、このstate leakが特に問題になったと考えています。
■ MaiMai Audio Linux側でも同じ問題を再現
MaiMai側のDiretta ALSA MMAP対応ドライバでも、同じ問題を再現できました。
fresh boot直後：
period_size_max = 4800
buffer_size_max = 153600
ここで44.1kHz / S32_LE / 2chとして、
period_size = 4410
periods = 8
buffer_size = 35280
を設定してcloseすると、修正前は次回OPEN時に、
period_size_max = 4410
buffer_size_max = 35280
まで縮小しました。
NAAとは無関係に、
snd_pcm_open()
→ snd_pcm_hw_params()
→ close
→ reopen
だけでも再現できました。
そのためNAAやHQPlayer側ではなく、Diretta ALSA bridge内部のbuffer state管理が原因と判断しました。
■ MaiMai側で行った修正
MaiMai側では、bufuseを単純にresetするのではなく、
「確保済みbuffer capacity」と
「現在streamのactive buffer size」
を別管理するように変更しました。
nodeに、
size_t buffer_capacity_bytes;
を追加し、buffer確保時に、
node->buffer_capacity_bytes = size;
として保持します。
そしてPCM OPEN時には、
substream->runtime->dma_area = node->buffer;
substream->runtime->dma_bytes =
node->buffer_capacity_bytes;
としました。
node->bufuse は従来どおり、現在再生しているストリームの実ring buffer sizeとして使用します。
つまり、
buffer_capacity_bytes
= allocation lifetime
= PCM OPEN / MMAP時のDMA capacity
bufuse
= stream lifetime
= 現在streamのactive buffer size
として役割を分離しました。
■ 修正後の確認
修正版MMAPドライバではfresh boot時、
period_size_max = 4800
buffer_size_max = 153600
の状態から、
44.1kHz
period_size = 4410
periods = 8
buffer_size = 35280
をHW_PARAMSだけ適用してcloseしても、次回OPENは、
period_size_max = 4800
buffer_size_max = 153600
を維持しました。
さらに、
HW_PARAMS
→ PREPARE
→ 音声writeなし
→ CLOSE
→ 再OPEN
まで行っても、
period_size_max = 4800
buffer_size_max = 153600
のままでした。
■ HQPlayer NAA + MMAPでの実再生確認
最後に、修正版MMAPドライバ上でHQPlayer NAAを実際に再生して確認しました。
同じnetworkaudiodプロセスを再起動せず、
44.1kHz：
rate = 44100
period_size = 4410
buffer_size = 35280
で正常再生。
STOP後も、
period_size_max = 4800
buffer_size_max = 153600
を維持しました。
そのまま同じNAAプロセスで192kHzへ切り替えると、
rate = 192000
period_size = 4800
buffer_size = 38400
で正常再生できました。
192kHz再生終了後も、
period_size_max = 4800
buffer_size_max = 153600
を維持しています。
修正前に発生していた、
低レートの小さいbuffer
↓
次回OPENのcapacityまで縮小
↓
高レートMMAP再生で必要なperiod sizeを確保できない
という状態は、修正後には再現しなくなりました。
そのためKONA側でも、もし同じ認識であれば、
substream->runtime->dma_bytes = node->bufuse;
の node->bufuse をPCM OPEN時のcapacity authorityとして使わず、allocation時に決まったcapacityを別フィールドに保存して、それを runtime->dma_bytes に使用する形にすると解消できる可能性が高いと思います。
node->bufuse はprepare後のactive ring sizeとして残した方が、既存のcopy / pointer / mute処理への影響も少ないと思います。
HQPlayer NAA + MMAPの検証中に偶然見つけた問題ですが、KONA Linux実機でもPulseAudioの有無だけで
4800 / 153600
↓
220 / 882
を再現できたため、参考になればと思い情報共有します。
必要であれば、MaiMai Audio Linux側で行った修正差分や再現用のALSA probeコードもお送りします。
kona cofee
kona cofee
まいまいオーディオ
KONAさん
以前こちらで報告した api.alsa.headroom = 2048 の件について、buffer capacity修正後の状態で改めて確認してみました。
当時はPipeWire経由の44.1kHz再生で、最初に一瞬だけ音が出たあと停止する症状があり、DirettaのALSAノードに
api.alsa.headroom = 2048
を設定すると正常に連続再生できるようになっていました。
https://groups.google.com/g/konalinux/c/LsQ7HCQQ_Jg/m/Sho-HCL0BgAJ
今回、先日報告したbuffer state / capacity問題の修正後のKONA Linuxで確認したところ、現在もWirePlumber側にはこの headroom=2048 の設定が残っており、実際のDirettaノードにも2048が適用されていました。
そこで、buffer修正後の状態はそのままにして、api.alsa.headroom だけを 2048 → 0 に変更して再検証しました。
現在の条件は、
- api.alsa.headroom = 0
- api.alsa.disable-mmap = false
- buffer capacity問題修正後のDiretta ALSA bridge
です。
この状態でPipeWire経由の44.1kHzを再生したところ、以前の「一瞬だけ鳴って停止する」症状は再現しませんでした。
pw-play で44.1kHzを再生し、pw-top ではDiretta Sinkも44100Hz、ERR=0を確認しています。
さらに、
- 44.1kHzを3回連続でOPEN / 再生 / CLOSE → すべて正常
- 44.1kHz → 192kHz → 44.1kHz → すべて正常
- Spotifyの実再生 → 正常
まで確認できました。
そのため、少なくとも現在のbuffer capacity修正後のKONA Linuxでは、44.1kHz再生のために api.alsa.headroom=2048 は必須ではなさそうです。
時系列から考えると、以前 headroom=2048 で改善していた症状には、後から見つかったbuffer state leakが関係しており、headroom設定がその影響を回避するworkaroundとして効いていた可能性もあるように思います。
もちろん当時から現在までに他の変更も入っているため、これだけで単一原因と断定はできませんが、少なくとも現在は headroom=0 のまま44.1kHzネイティブ再生、レート切替、Spotify再生まで正常でした。
もし現在のKONA側で headroom=2048 を以前の対策として残しているのであれば、buffer修正後は不要になっている可能性がありますので、参考までに追加報告します。
まいまいオーディオ
KONAさん
先ほどの件ですが、追加で確認したところ訂正があります。
buffer capacity修正後のKONA Linuxで api.alsa.headroom = 0 にして確認したところ、最初は44.1kHz再生、連続OPEN/CLOSE、44.1→192→44.1kHzの切替、Spotify再生まで正常だったため、一旦はheadroom設定が不要になった可能性を考えていました。
ただ、そのまま使用を続けたところ、以前と同じ「最初に一瞬だけ音が出て、その後止まる」症状が再発しました。
再発時のPipeWireログでは、
spa.alsa: hw:0p: snd_pcm_avail after recover: Broken pipe
が繰り返し出ていました。
その後、WirePlumberのDiretta用設定を元の
api.alsa.headroom = 2048
に戻してWirePlumberを再起動したところ、Spotify再生もすぐ正常に戻りました。
そのため、今回確認した範囲では、
・buffer capacity / state leakの問題
・PipeWireで必要になる api.alsa.headroom = 2048
は別の問題として考えた方がよさそうです。
buffer capacity修正後でも headroom=0 では同じ症状が再発したため、KONA Linux側では現在の headroom=2048 設定は残しておいた方がよいと思います。
途中で「capacity修正後はheadroom不要かもしれない」と考えましたが、継続確認で再発したため訂正します。
参考までに、再発時はMMAP有効（api.alsa.disable-mmap=false）でした。