まずあなたが本当に技術者?なのかすら怪しいのはおいといてよく文章を読みましょう。 >OS が Web アプリと同様の「ソフトウェアミュート」を可能にする API を実装し、VCA が API を使用してミュート・アンミュートを切り替えられるようにすることを研究者は推奨している。 空想の「研究者vs技術者(あなた?)」の対立構造作って非建設的な「どうしようもない」とか言ってないで、 相手がどういう意図で調査して、どういう非難は意図してなくて、どういう解決策を提示してるのかをちゃんと考えてから書き込みましょうね。
よくわからないけど? (スコア:0)
ウインドウズやアンドロイドのマイク許可とかの設定は表向きで
許可出さなくてもアプリ側でマイクのデータ取れるってこと?
Re: (スコア:3, 興味深い)
研究者が言いそうなことだな、というのが正直な感想
現場のエンジニアならこんなことはクチが割けても言えないこと
詳しいシーケンスは省くがアプリがOSを介してPCにつながったマイクに接続して音を出し始めるまでにだいたい1sec以上かかる
じゃぁ普通にやってアプリのボタンを押してから実際にマイクが音を拾い始めるまでのタイムラグを
ユーザーが許してくれるのか?ゼッタイにこれに関してクレームが来ないのか??
実際はこんなことクレームの嵐だし、それをなんとかしろと現場の技術者が一生懸命解決策を考えた結果に現状のシステムがある
リアルタイム性を確保するためには事前に音声をキャプチャしておくしかない
こんなことは2000年代に散々議論された話で、これはそのときの話の単なる蒸し返しにしか思えない
Re: (スコア:0)
まずあなたが本当に技術者?なのかすら怪しいのはおいといてよく文章を読みましょう。
>OS が Web アプリと同様の「ソフトウェアミュート」を可能にする API を実装し、VCA が API を使用してミュート・アンミュートを切り替えられるようにすることを研究者は推奨している。
空想の「研究者vs技術者(あなた?)」の対立構造作って非建設的な「どうしようもない」とか言ってないで、
相手がどういう意図で調査して、どういう非難は意図してなくて、どういう解決策を提示してるのかをちゃんと考えてから書き込みましょうね。
Re: (スコア:0)
そこの言いたいことが全く持ってわからんのだが、
webアプリの「ソフトウェアミュート」とやらはブラウザの機能で、ブラウザはマイクの音拾ってるんだろ。
やってることはデスクトップアプリと大して変わんねーじゃん。
ブラウザを安全安心と信じるか、VCAを信じるかってだけで、ユーザーからしたら何も変わらん。
Re: (スコア:0)
>webアプリの「ソフトウェアミュート」とやらはブラウザの機能で、ブラウザはマイクの音拾ってるんだろ。
違います。よく読みましょう。
Re: (スコア:1)
#4234435(および#4234267)だけど自分で言ってて変な感じしたので#4234435は取り消します。
ついでに元論文読んできました。タレコミ文も微妙なところがあるので論文読んだ上で(それと私の願望も加えて)説明しますが、(推敲しないので乱文失礼)
要するにOSレベルでマイクの音は常にサンプリングしつつも、
ネイティブアプリへの流入をOSレベルで遮断した状態にできるAPIをOSで提供して、それ使うようになるといいね、って話です。
プライバシーを重視する私もそうなってほしいですし、元コメが騒いでる1秒以上遅れる、とかいう問題も解決します。
(私としてはそもそも1秒も遅れ
測ってみたよ! (スコア:0)
横からだけど、超簡単に測る方法を思いついたので測って見ました(ちなみに私は #4234219 を書いた人)
結論から言うと306ミリ秒しか遅れない
ある楽曲を頭に空白を入れて流して、目を閉じて、「鳴った!」って瞬間に自作の普段使いの録音アプリ(※1)の録音ボタンを押すという、反射速度テスト的なことをしてみました
(※1 C# + NAudioの組み合わせで書いてあってWASAPI使用で、録音ボタンが押されてからデバイス初期化して録音を開始するタイプ)
で、実際にデジタルループバックして元の音源と比較するって手法で1サンプルのズレも無いように測ってみたら、正確に306ミリ秒(44.1kHz音源使用で13504サンプル)でした
#4234080の主張の通り初期化に1秒以上かか
Re:測ってみたよ! (スコア:0)
というかこんなに短いんだったら、喋ってるかの判定不要ならば普通にミュート時にサンプリングしない方式でも使えるのかもしれませんね。
大変参考になりました。