まずあなたが本当に技術者?なのかすら怪しいのはおいといてよく文章を読みましょう。 >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秒も遅れるのか疑ってますが検証してないのでそこはおいておきます)
こうすることで
今のブラウザとウェブアプリの関係はそれに近くて、WebRTC API経由でブラウザに指示して、ブラウザとJavascript間の音声を完全に遮断してます。
ただし、もちろんおっしゃるとおりブラウザの実装を信用するのと、ウェブアプリ側が正しくそれを呼び出してることは前提になります。
そして一般にブラウザの実装は信用が高いですし(プライバシーに慎重な私もそうです)、問題があればオープンソースなので誰かが騒ぎます。
後者は、ブラウザ側でインジケータを出すようにすれば解決できると私は考えます。
こうすると何が嬉しいかというと、OSないしブラウザを信用し、個々のアプリを信用しないで良くなるわけです。
またネイティブアプリで喋った時の検知云々が他スレで説明されてますが、実装的には生のシグナルをアプリが解析してるのではなくOS側からミュートか否かのフラグを利用しているようです。
なので、OSないしブラウザに対して、マイクをサンプリングしつつも、「アプリにシグナルを渡しているか明確にする」「シグナルは渡していないが解析内容は渡している(ミュートか否か)」「何も渡してない」
というふうなことができるようにすればいいでしょう。
よって技術的には完全に可能ですし、問題提起をしたこの研究は極めて参考になるものです(私も以前から気になってました)
既存のネイティブアプリも、ミュートか否かのフラグはつかいつつ、生シグナルを解析しているアプリがあるかの検証など、かなり色々とやってます。
申し訳ないですが、#4234080のような「現場の技術者」よりも圧倒的に技術力は高いです。
問題が提起されたら、問題が技術的に可能かを考えそれを実現するのが技術者です(そもそも優秀な技術者は問題の提起もできます。なぜなら技術的に自明だから)
そして、今回の件は技術で十分に可能ですし、さほど難易度も高くありません。
#4234080のように他人のコードを組み合わせていじくるのが仕事の「現場の技術者」のかたには見えないかもしれませんが、一定以上の技術を持っていれば本件は論文など読まなくても真っ当な問題提起であることがわかり、解決法も自明です。
測ってみたよ! (スコア:0)
横からだけど、超簡単に測る方法を思いついたので測って見ました(ちなみに私は #4234219 を書いた人)
結論から言うと306ミリ秒しか遅れない
ある楽曲を頭に空白を入れて流して、目を閉じて、「鳴った!」って瞬間に自作の普段使いの録音アプリ(※1)の録音ボタンを押すという、反射速度テスト的なことをしてみました
(※1 C# + NAudioの組み合わせで書いてあってWASAPI使用で、録音ボタンが押されてからデバイス初期化して録音を開始するタイプ)
で、実際にデジタルループバックして元の音源と比較するって手法で1サンプルのズレも無いように測ってみたら、正確に306ミリ秒(44.1kHz音源使用で13504サンプル)でした
#4234080の主張の通り初期化に1秒以上かか
Re: (スコア:0)
というかこんなに短いんだったら、喋ってるかの判定不要ならば普通にミュート時にサンプリングしない方式でも使えるのかもしれませんね。
大変参考になりました。