orange @[email protected]

それだとオレンジが実験したとおり「内部（デバイスドライバにたどり着く前）でどう処理されたかをチェックするぞ！＞＜」が出来なくなっちゃう＞＜（つまりどの段階でデータが破壊されたかがわからなくなっちゃう＞＜）

そんな変な実装にするメリットを無理やり考えるなら、「ループバックは出力の監視測定用なんです！」って発想で出力監視をしやすくした？＞＜；

もしかして、ミックスするタイミング変えたのも勘違いである可能性がある・・・？＞＜；
勘違いだとするとミックスしたあと音量下げて出力デバイスのフォーマットにあわせて一度ビットレート変換してからそれをもう一度32bit floatに戻したものをループバックデータにしてる？＞＜；
でも、そんなメリットもよくわからないめんどくさい実装なんてするかな？＞＜；

色々試したけど、内部で整数で処理してるっぽい挙動してる・・・・＞＜
もしそうなら音質というか精度的には一長一短というか、まともなアプリとすごいオーディオインタフェースの組み合わせの場合はある意味音質低下なんでは感＞＜

もしかして、内部処理がfloatじゃなくなった・・・？＞＜；

あれ？＞＜；
24bitのデータ再生しても測定結果が24bitにならない・・・？＞＜；

オレンジが前に作ったオーディオが整数精度相当で再生されてるかチェックするアプリ使って、Win 11のメディアプレイヤーで普通に再生したら整数精度相当って出た＞＜；
何か間違って無ければ、つまりたぶんWindows 11のオーディオエンジンはオレンジが前にわざわざ作った整数精度相当のデータを破壊しないように音量調節する音声再生するやつと同じ状態になってる・・・？＞＜；

Beがもしハードウェアを諦めずなおかつつぶれないで生き残ってたら、Threadripper積んでコア数増えすぎて前面がCM-5みたいになってるモンスターマシンを売ってたんだろうか？＞＜；

12年くらい前？に作ったBeBoxのblinkenlights(BeBox本体前面についてるLEDバーグラフのCPU負荷計)を模したCPU負荷メーターアプリ、12論理コアのマシンで動かしたらデスクトップ両脇に6本ずつバーグラフが現れて21世紀っぽさ＞＜

オシロスコープミュージックを見るために作ったXYオシロスコープアプリも、オシロスコープ部分にスケール調整機能をつけなかったので爆音再生しないと見れなくなった＞＜；

手抜きして作るなら、オーディオプレイヤーをライブラリとしてつくって、そのクラス2個作って、同時に再生すればあんまりずれなさそうだし、同期は遅い方にあわせるなら雑になら空白サンプル、ごまかすならてきとうにサンプル複製して遅らせる機能をつけとけばなんとかなりそう＞＜

軽量なバイトストリーム用リングバッファ、.NET側で標準で用意してほしい＞＜；
(数ヵ月前になんか記事見つけて読んだけど、バイトストリーム用リングバッファってバグなしに実装するのかなり難しいらしい・・・＞＜(実際難しかったしバグあるかわからない＞＜))

セッションごとのループバックは音量調節する前のなのかな？＞＜；

この変更で何が困るかと言うと、オレンジが今まで作ってきたリアルタイム音声解析とかループバック録音するアプリ群が、メインボリュームを大きくした状態じゃないと使えなくなったって事＞＜；
モニタ音量調整出来るオーディオインタフェースならそっちで下げればいいけど、ラップトップにイヤホン直挿しとかだと爆音＞＜；(アナログボリュームつき延長ケーブルとかが必要＞＜；)

完全に推測だけど、変更されたタイミングって、WASAPIループバックをセッション単位で出来るようになった(特定のアプリが出す音だけ選択してループバック録音できるようになった)タイミングで変わったのかも？＞＜

あとあくまでWindows Core Audioのミキサーの仕様変更の話であって、WASAPI排他モードとかASIOみたいなデバイス占有するタイプの再生は全く関係ない話＞＜(その場合はアプリ作る人の作り方で音質変わる＞＜(アプリ側で音量調整するので＞＜))
そうじゃなく普通にWindowsで音を出すアプリなら影響するはず＞＜