qemuだとround * bps * チャンネル数で確保してる。appbufszはrate * latency(これはQEMU内部での何かだろう) / 1000000になってるな。 https://patchwork.kernel.org/project/qemu-devel/patch/20200304145003.GB15649@humpty.home.comstyle.com/
OpenBSD(uaa@), Ham(JG1UAA), Ingress(Lv14, RES), Japanese(Sagamihara-city, Kanagawa)
Another side: https://social.tchncs.de/@uaa
npub1rarr265r9f9j6ewp960hcm7cvz9zskc7l2ykwul57e7xa60r8css7uf890
Messages from this Mastodon account can read via mostr.pub with npub1j3un8843rpuk4rvwnd7plaknf2lce58yl6qmpkqrwt3tr5k60vfqxmlq0w
qemuだとround * bps * チャンネル数で確保してる。appbufszはrate * latency(これはQEMU内部での何かだろう) / 1000000になってるな。 https://patchwork.kernel.org/project/qemu-devel/patch/20200304145003.GB15649@humpty.home.comstyle.com/
えー、sio_par.roundがあるのか…これ設定してないから不思議な挙動になるのかなあ。
ふーん
if (par->rate != ~0U && par->appbufsz == ~0U)
par->appbufsz = par->rate * 200 / 1000;
return hdl->ops->setpar(hdl, par);
appbufsz = ~0だと200msec分のバッファになるのか。
うーん、倍率を計算してはみたけど、どういう基準でこれ決めてるんだろう…?
8000Hz→80byte単位、max 1360 (x17)
11250Hz→113byte単位、max 2712 (x24)
16000Hz→160byte単位、max 5440 (x34)
22050Hz→221byte単位、max 10166 (x46)
24000Hz→240byte単位、max 12240 (x51)
32000Hz→320byte単位、max 21440 (x67)
44100Hz→441byte単位、max 40572 (x92)
48000Hz→480byte単位、max 48480 (x101)
とはいえ16bit 2ch(4byte/sample)と、8bit 1ch(1byte/sample)で、頭打ちになったappbufszの上限が同じっていうのもなんかよく分からんなーという気はしてる。8bit 1chでのappbufのサイズはこんな感じかなあ
8000Hz→80byte単位、max 1360
11250Hz→113byte単位、max 2712
16000Hz→160byte単位、max 5440
22050Hz→221byte単位、max 10166
24000Hz→240byte単位、max 12240
32000Hz→320byte単位、max 21440
44100Hz→441byte単位、max 40572
48000Hz→480byte単位、max 48480
ふーむ、OpenBSD sndioのappbufszの挙動って、サンプリング周波数の1/100…10msec単位で確保なのかなあ。確保するサイズはなんか頭打ちになるんだけど、上限をどう設定してるかはちょっと分からない(ソース見れば良いんだけど)。