スポンサード リンク

T.Ishii's Software Library

HTML5 レトロ風ゲーム館

無料ブログはココログ

« 敢えてやらないという選択 | トップページ | Per-Monitor DPI対応 »

更に改良された

今は、Windows用AmuseGraphicsの開発フェーズなのだが、他ソフトの不具合対応も必要なので、中々、先に進まない。次は、Win版Mirror-DTC Ver1.3.1をリリース予定で、既に使いこみ中なのだが、使い込みで出た、ある問題に対応したので、新版は更に改良された。

ある問題というのは、クライアントが接続中に、クライアントマシン側の規定の再生デバイスを切り替えると、クライアントがフリーズする、という問題だ。

確か、この問題については、メールでクレームを貰った事はない筈なのだが、初版から発生していた問題だ。

にも関わらず、今まで対応せず、かつ、クレームも無かったのは、作者的にも、ユーザー的にも、そういうもんだろう、という認識をしていても、特に問題は無かったからかもしれない。

つまり、この問題は、規定の再生デバイスを切り替える、という積極的な行動を、Mirror-DTCクライアントの接続中には行わない、という事にするだけで回避できたので、もし、問題に遭遇しても、そんなもんだろう、という事で、次からそういう回避策を採る事にすれば良かったので、問題視されてこなかった、と、考えられる。

少なくとも、作者的にはそうだったので、上記の様な問題が発生する事は認識していたのだが、今日まで、この問題を修正しようとはしなかった訳だ。

もっとも、上記の問題が簡単に修正できる類のモノだったのなら、作者的にも、修正していた筈なのだが、上記の問題が何故発生していたのか、というと、Mirror-DTCクライアントが音声出力用に使っているAPIは、大昔からあるmmsystem系のAPIになるのだが、再生中に規定の再生デバイスを切り替えると、このAPI関数がフリーズしていたからだ。

つまり、作者的には、上記の問題を解決するためには、mmsystem系以外の、より新しいAPIを使って音声出力する必要がある、と、考えていたので、そんな事をするくらいなら、上記程度の問題には目を瞑ろう、という事にしていた訳だ。

しかし、作者的には、最近、USB接続のJBL製スピーカーを購入して使う様になったので、それを繋いでいるMac mini Late2014環境では、規定の再生デバイスを切り替える事が可能になった。

もっとも、この環境については、一度、設定してしまえば、設定を変更する事は稀かもしれないのだが、より大きな問題として、MacBook Pro 15インチ 2016モデルにBootCampでインストールしたWindows10環境では、イヤホンを接続すると、それだけで、規定の再生デバイスが通常の内蔵スピーカーからイヤホンに切り替わる格好になっていた訳だ。

つまり、MacBook Pro 15インチ 2016モデルの音声出力系は、ある意味、無駄に豪華なので、Mirror-DTC接続中にイヤホンを挿すと、イヤホンから音が出ないばかりではなく、Mirror-DTCクライアントがフリーズするオマケまで付いてきた訳だ。

以前に書いた事がある様に、作者的にはイヤホンは嫌いなので、作者個人としては、上記の問題もさほど致命的でもないのだが、普通に鑑みれば、イヤホンを挿すでけでフリーズするソフトというのは大問題な訳だ。

と、いう事なので、今回は、覚悟を決めて、上記問題に対処する事にしたのだが、結果的には、前述の様な、別系統の音声出力APIに変更する、というギャンブルに出る必要はなかった。

つまり、以前から使っているmmsystem系のAPIをフリーズさせる事なく使える様にする方法を見つけたのだが、その方法というのは、コールバック処理中にAPIを使うのをヤメた事だ。

具体的には、mmsystem系APIの場合、依頼していたバッファの再生が終わったら、その旨の通知が行われるのだが、その通知方法としては、主にWindowsメッセージ/コールバック関数があるのだが、作者的には、ずっと、コールバック関数を使ってきていた訳だ。

その理由は、音声出力処理のイベント通知用にウインドウが必要、というのは、音声出力系処理を自前ライブラリ化する時に大問題になるので、使えず、前述のコールバック関数を使う方法というのは、ネットで見ていてもサンプルコードが多かったからだ。

で、作者的には、ネットで今回の問題、つまり、waveout系関数がフリーズする問題について検索してみたのだが、同様にフリーズする問題の報告は何個か見つかったのだが、解決方法は無かった訳だ。

つまり、世の中的にも、そんなもんだろう、と、思っていたのかもしれない訳なのだが、前述の書き込み中には、この問題の発生原因はデッドロックにある、と、MSの人に言われた、みたいな書き込みはあった。

なので、作者的には、デッドロックが発生するとすると、コールバック関数が問題なんだろう、という事で、別スレッドを起こし、コールバック関数中では、送られてきたパラメータをそのスレッドのキューに渡すだけにした。

そうすると、問題は発生しなくなったので、やはり、mmsystem系の場合、コールバック関数中でmmsystem系のAPIを使うと、規定の再生デバイスを変更したりした特別な場合に限り、デッドロックが発生する様だ。

と、いう事で、今回、上記の問題にも対応したので、次バージョンでは、クライアント動作中に規定の再生デバイスを切り替えても、切り替えた先に音声出力が切り替わる筈だ。

なお、サーバー側についても、似たような問題があったので、今回、同様に修正した。なので、次バージョンでは接続中にサーバー側の規定の再生デバイスを切り替えても、切り替えた再生デバイスの音声が転送される様になる筈だ。

まあ、サーバー側の問題については、作者を含めて、困っていた人はいなかった、かもしれないのだが。

ちなみに、同様の問題は、作者製ソフトの全てにあったのだが、AmuseGraphics系ソフト、つまり、AGMPlayerだとかAG-ムービーカッターについては、次バージョンで同様の対策を打つ事になる筈なので、問題は無くなる筈だ。

WaveClipperについても、同様の対策は可能なのだが、こちらについては、新バージョンを出したばかりだし、用途的にも、再生中に規定の再生デバイスを切り替えたりする事は、まず、無い筈なので、同様の変更は、その他の変更が必要になった時に合わせて行う、という事にする予定だ。

« 敢えてやらないという選択 | トップページ | Per-Monitor DPI対応 »

トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/534482/65976020

この記事へのトラックバック一覧です: 更に改良された:

« 敢えてやらないという選択 | トップページ | Per-Monitor DPI対応 »

2018年4月
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30          

広告

プライバシーポリシー

  • 当サイトでは、第三者配信による広告(Google Adsense)サービスを利用しています。

    Google を含む第三者配信事業者は、Cookie を使用して、ユーザーのウェブサイトでの閲覧履歴に基づく広告を配信します。 Google 広告 Cookie を使用することにより、Google や Google のパートナーは当サイトや他のサイトへのアクセス情報に基づく広告をユーザーに表示できます。

    Cookieを無効にする設定およびAdsenseに関する詳細については、以下のリンクを参照下さい。

    広告 - ポリシーと規約 - Google