Intel MacでのLogicProの不具合＜レイテイシー＞

問い合わせされた方ののもとへ、昨日、AppleCareから連絡が入り、中間的な経過報告がありました。
１）アメリカの検証でも現象は確認されている。
２）intel Mac　全機種で確認されている。
３）現象の原因は特定されていず、現在も検証中で、答えは出ていない。
４）バッファサイズ512か1024で安定の傾向がある。
５）結果が出次第、連絡をする。
４）ですが、とりあえずはそれでやってくれと言いたいみたいでしたが、「安定の傾向」という言い方でした。私の検証では、使える程度には安定していませんでした。
とのことですした。
今現在、 intelMacではLogicProを正常に使用できないということです。
購入を検討されている方は、apple careで確認されることをお進めします。

ロジックが対応しているということで、３月にMacBookProを購入、すぐにそのためのアップグレードを購入。そして、５ヶ月が過ぎ、まともに使えていない状態。
新しい機種に全てが対応するのには、時間がかかるということは、理解はしていますが、タイミングがずれるなんていう基本的な機能をちゃんと検証もしないで、”対応”とうたうのはいかがなものでしょうか。
まともに使えることがわかるまでは、β版で配布するとか、少し、配慮するべきでは？
MacBookProの必要性は、僕にとっては、 logicの使用のみ。
そして、時期MBPのうわさもちらほら。
トラブルへの検証、問い合わせ、などの時間的損失や、経済的損失は、大きいです。
殿様商売になってますよ、最近の appleさん！

うーん Intel Mac は持ってないので、検証などはできませんが、、。
以前から、Logic のサンプルエディタの波形表示は、ルーラと実際のデータの位置がずれていたり、編集中に突然数サンプル分、表示が前後に動いたり、と、かなりいい加減という印象しか無いんですが、そういう表示だけの異常ではないんですか？　録音されたオーデイオファイルを Logic 以外の波形表示ベースのサウンドエディタ（Peak とか）で開いても、同様にずれてるんでしょうか？
また、１回の録音でも、ずれの度合いが刻々と変化しているようですが、それはつまり波形が伸び縮みしているということになりますね。ということは、タイミングと同時にピッチもわずかに揺れてるはずですが、それは感じないんですか？

＞翡翠さん
すみません。うっかり、しばらく投稿を見逃しておりました。
表示だけではないのです。明らかに、遅れております。メトロノームと録音をしたものを同時再生すると、タタン、タタン、となるくらい遅れることもあるほど酷いものです。
＞１回の録音でも、ずれの度合いが刻々と変化しているようですが、それはつまり波形が伸び縮みしているということになりますね。ということは、タイミングと同時にピッチもわずかに揺れてるはずですが、それは感じないんですか？
これに関しては、私自身の症状ではないのですが、この方の情報では、『内蔵スピーカと内蔵マイクの録音ではレイテンシーの値が録音するたびに違う現象は起きるのですが、「揺れ」はおきません。しかし外部ADをつなげると常に揺れる状態になります。」ということです。
他の方の情報まで書き込んでしまったので、混乱を起こしそうですね。
すみません。

効果のほどは分かりませんが、
Logic Pro 7.2.2 がリリースされたので適用されてみてはいかがでしょうか？

こんにちは、面白そうな検証なのでやってみました。
ものすごく長くなりますが、以前から、sampleとMIDI分解能の整合について興味があったもので…
MacBook/os10.4.7/Logic7.2.1/内蔵音源/48k/tempo120
ただ、検証にあたってメトロノーム音は微妙だと思ったので、EXS24を使いました。
メトロノーム音は、内蔵スピーカから出力やポリフォニッククリックができることから、
厳密な発音タイミングを保持しているか不安だったので…
アナログシンセエミュレーションのES1等も、
厳密なオシレータのリトリガータイミングの疑問があったので、
問題を切り分けるためにも、単純に波形をトリガーするEXS24がわかりやすいと思いました。
EXS24の最初のインストElectric Grandで、
波形が分かりやすいように最高音サンプルのKeyNote C6を使いました。
このサンプルは20sampleから音がたちあがりますが、
StartFrame（フレーム？）が14なので6sampleのずれということです。
また、トリガーに影響をあたえる可能性があるので、
LFO1,2,3、モジュレーション、ADSRもすべて0、
Glide等もすべてoff、発音はmono、
オプションのレートコンバートは最高、サンプル保存は32bitフロートにしました。
個人的な経験から、とりあえずI/Oバッファは標準の512のみ検証しました。
MacBookの内蔵オーディオはPowerBookに比べて、
安定度、質が極端に落ちたように感じてます。
スペック上は遥かに良くなったはずなのに…
レコーディングカウントインも標準状態の１小節のままで、
その他特に環境設定はさわっていません。（たぶん）
確認に使用したLogicのサンプルエディタは、サンプル＆サンプル値で表示し、
さらに実データを見るためにサンプル＆ホールド表示にしました。
続く

というわけで本題
結果
１．
レイテンシーはありましたが、極端ではなかったです。
さらにレイテンシーはすべて一定の値と言って良い範囲でした。
CPUバッファ
大290sample
中284sample
小294sample
ということでした。
マイクは液晶上部、スピーカーは本体下部で反射を利用しているので、
液晶の角度も固定、20cm≒30sample程度の遅れなら納得できるのですが…
ドライバーのレイテンシー報告が厳密なものでないのかもしれないです。
改善して欲しいですが、
後で、もうすこしまともなインターフェイスで検証してみます。
ただ、何度も検証していく中で一度だけ400sample程度の遅れがありました。
この波形にはDCオフセットがあり、
その後、試しにサージ対応等の電源周りをかえてからは再現しませんでした。
また、CoreDuoのCPU速度変化が問題の可能性もあるので、
一度バッテリーを外した1Ghz固定の状態でも検証してみようと思います。
（あくまで参考ですがCoreDuoTempのSpeedItでも不具合経験があります）
２．
録音開始場所を1,2,3,4,5,99,100,101,102,103小節目と変えてみましたが、
レイテンシーの変化はありませんでした。
もちろん長時間RECでもレイテンシーの変化（MIDI発音タイミングの揺れ）は、
まったくありませんでした。
ですが、
ここからが僕の興味のあったところで、あくまで推測ですが、
３．の問題とも関係あるかもしれません。
サンプリングレート48k、テンポ120であれば、
MIDI分解能960最小値が25sampleちょうどで割り切れるのですが、
44.1kだと22.96875sampleとなり割り切れません。
こういう辻褄あわせをどの単位で補正するかということで、
Logicは２小節単位で補正してるのではないかということです。
よって44.1kでは、偶数小節と奇数小節での遅延の違いが起こるのかと思います。
ちなみに僕のところでは、4sampleのズレ。
同様に48kに設定できないPoweBook12inchでも同じ結果がでました。
ただ、これは音楽的な解決方法の一つであると思います。
問題は切り分けないとダメですが、
この問題は、数sample程度の誤差の話です。
DAWのサンプリングレートは実時間に対して絶対的ですが、
テンポは実時間と相対的で、この整合性をどこでとるのかというのは、
デジタルでは避けられない問題だと思います。
たとえばMIDI分解能＝サンプリングレートというのはレコーダーとしては、
現実的な対応ですがシーケンサーとしては疑問もあるということです。
音楽的なテンポを基準にするのか、
絶対的なサンプリングレートを基準にするのかという問題です。
Logicでsample単位での編集の裏技でもありますが、
MIDI分解能960というのは48kならテンポ3000に相当します。
つまりテンポ6000であればサンプリングレートを超えたMIDI編集も可能だということです。
Audio-MIDI同期の問題があるので、
発音タイミングはサンプリングレートに引っ張られるとしても、
音楽的テンポにたいして相対的な編集ができるというのは、
トランスフォームやエンバイロメントから見ても有効なアプローチなのではと思います。
（もちろん、もっと良いアプローチがあると思いますが）
この弊害？として数サンプル程度の誤差があるのではないかという推測です。
というわけで、出先なので厳密な検証ではないですが、
時間がとれればさらに検証するということで許してくださいまし。

情報ありがとうございます。
今日、明日、時間がありませんが、試してみてご報告いたします。

ありがとうございます。 massivaさん。大変参考になります。
同じ、検証状況で、検証したいと思います。（明日は時間がありませんので、少し、時間がかかると思いますが）
EXSでの検証では、異常というほどのものではないということですね。
一定のレイテンシー（レイテイシーだと思い込んでいました。恥）であるなら、
レコーディングディレイで調節できますね。
私の行った検証方法では、内蔵クリック音の発音タイミング自体が、かなり怪しいと考えてみるべきですね。内蔵音源をたくさん使った曲へのレコーディングでは、かなりの遅れが発生していたのですが、これは、どういうことなのか、もう１度、プラグイン補正など、チェックしなおす、必要がありますね。この問題を検証するまで、僕自身は、プラグイン補正をおこなったままでも、ちゃんとロジック側が正しい位置に、オーディオを録音してくれるものとばかり思っておりました。
再度、いろいろなことを確認して、検証を行いたいと思います。
お時間ください。
ありがとうございます。

みなさん、ありがとうございます。
質問をしておいて、なかなか、検証もできずにおりますが、この問題について、
http://www.naoxlogic.com/
こちらの掲示板“熱く語れ”のスレッド
AUDIO録音が遅れる
続AUDIO録音が遅れる
続AUDIO録音が遅れるpart2
でいろいろな方のご意見、検証の情報交換が行われております。
ご参考に。。。

えっと、他の掲示板でも話題になってるようですが…
どちらに書き込んで良いのか分からないので、
混乱を避けるためにも僕はこちらということにします。
まだ深い検証をしていないので、
書き込むべきではないと思っていたのですが、
誤解を生んでいる気がしたもので…
まず、検証時の説明を追記しておきます。
メトロノーム音の厳密な発音タイミングについて
メトロノーム音がLogicのオーディオドライバーとは別に、
内蔵スピーカーからもポリ出力できてしまうということから、
Logicのオーディオ出力とは別に出力を扱っている可能性があります。
たとえば、Logicを48kで使用していても、
44.1k（システムサンプリングレート）で出力できることから、
ビットレート等も含めてなんらかのリサンプリングが行われ、
位相ズレが生じる可能性があるのではないかという不安があり、
さらに精度についてもMacのシステムに一度出力を預ける形になっているので、
Logicシーケンス以外にも問題を挟む可能性もあり、
問題の切り分けのためにも使用は避けました。
シンセのオシレータのリトリガーについて
オシレータ自体を厳密にリトリガーしているか疑問というのは、
オシレータ自体はリトリガーしない、単純にアンプのリトリガーの可能性、
さらに位相干渉などの音痩せを防ぐパルス幅変調方式や、
オシレータシンクでマスターオシレータ固定などの可能性があると思ったので避けました。
というわけで、EXS24の波形のスタートフレーム、ADSR等も厳密にして、
単純な波形のトリガーを見る検証をしたということです。
続く

ここから本題、補正アルゴリズムについて。
前回、書き足りない点があったようなので補足します。
本来違う基準軸であるMIDIとオーディオの時間管理をあわせるための補正が、
絶対位置を優先するのか相対位置を優先するのかという問題です。
音というのはどちらかというと相対的なものだと思います。
数学的な話になりますが、
何に対して正確性を求めるかによって、割り切れない数値の対処が違います。
たとえば、MIDIをサンプル解像度（絶対時間）基準で扱うアルゴリズム、
つまり絶対的位置を優先するアルゴリズムでは補正位置が変化します。
ここが僕の興味のあった部分で、
理想的な補正はどういうものかを考えてみたいなと…
例として、KGさんのあげられたサイトのホロロさんの検証結果を見てみますと、
１拍目（０サンプル）−１サンプル
２拍目（22050サンプル）＋１３サンプル（22064）
３拍目（44100サンプル）＋１１サンプル（22048）
４拍目（66150サンプル）＋９サンプル（22048）
５拍目（88200サンプル）＋７サンプル（22048）
６拍目（110250サンプル）＋５サンプル（22048）
７拍目（132300サンプル）＋３サンプル（22048）
８拍目（154350サンプル）＋１サンプル（22048）
９拍目（176400サンプル）−１サンプル（22048）
（ ）内は音符間のsample数
ここで相対関係、つまり音符間のsample数に注目してもらいたいのですが、
もし、絶対位置優先のアルゴリズムで、2拍目を22050に置くと、
8分音符が11025となり、16分音符で補正が入ってしまいます。
つまり音符間のsample数が交互に変化するということです。
32分音符を考えるとさらにバラバラになります。
厳密に言うならば、リズムがよれるということです。
ここで音符間の相対関係を考えると、
上記検証の音符間のsample数（22048）は、限りなく22050に近く、
且つ、約数の多い数字になっているのではないでしょうか。
これは、16分音符、32分音符と、音符間を分割する中でも、
音符間のsample数をできるだけ均等に保つような数値になっています。
つまり、この補正は音符間の時間均等を優先したアルゴリズムなのではないでしょうか。
これは単純にタイミングだけの問題ではなく、音源のポリ発音に影響します。
シンプルなオシレータを考えてみると分かりやすいと思いますが、
前音と次音の音符間のsample数が違うと、重複部分の音質変化を起こします。
この音質変化を最小限にする手法として、
アクセントとなる部分に変化をまとめてしまうというのが、
音楽的な解決方法の一つではないかと言うことです。
また、編集時における位相干渉問題からみても、こういう補正は、
音痩せを防ぐPWMやオシレータシンクに似たアルゴリズムだと思います。
現実的に、サンプルレートでちょうど割り切れる位置に音符があることは少ないわけですから、
補正位置が相対時間を基準にした音楽的な位置にあるというのは、
絶対時間基準の数学的には不自然に見えても、
人間の耳には正しい補正なのかもしれないということです。
そういうことを把握した上でないと、
sample単位での検証というのは誤解を生むのではないかと思いました。
とはいえ個人的には、レコーダー機能優先派として、
絶対位置優先補正になるほうがよいですけども…。

とここまで書いて今、軽く検証してみましたが、
44.1kで絶対位置優先で補正されていました…
つまり、メトロノーム（KlopGeistも同様でした）の発音がオシレータのリトリガーではなく、
アンプのリトリガーである可能性があるようです。
いうなればメトロノームの発音はオシレータシンクしているようなので、
さらに検証してみます。
可能性を指摘しておきながら、自分自身がハマっていました。申し訳ありません。
たしかに44.1kの２小節単位のズレの検証の際は、メトロノームを使用していました…
僕の考察が無駄でした…

何度もすみません
手っ取り早く検証できる方法として、
ES1を立ち上げ、なにも触らない状態で下部のAnalogを0%にすると、
きちんとオシレータをリトリガーする設定になるようなので、
奇麗に絶対位置の補正になりました。

massivaさん、論理的な考察と説明、ありがとうございます。理解出来ないところが、ありますが、頑張って理解しようと努めております。（汗）
今日は、少し時間があったので、まずは、クリックに問題があるということを、自分で確かめたかったこともあり、ずっと、そのことに時間を裂いておりました。
内蔵スピーカーから出るメトロノームには、「内蔵クリックを使用」場合と、「klopGeist」を使う場合、そしてまた、設定により（ポリフォニックですか）両方出せるということさえ、今回知りました。
そして、その二つを同時にならすと、二つがずれているのですが、そのずれ幅が違うので、音色がどんどん変わります。
ひとつづつを、内蔵スピーカーから鳴らし、内蔵マイクで録音しました。
内蔵クリックを使用したばあい、その遅延幅は、１拍づつかなりランダムになります。
サンプルエディターでの正確なサンプルの数え方があやふやかもしれませんが（直接波形のところで選択してそこに現れる表示で見ているのですが）だいたいこんな感じです。
-----1小節目
1拍目 　466
2拍目 -75
3拍目 -112
4拍目　-146
-----2小節目
1拍目 　-181
2拍目 -212
3拍目 265
4拍目　229
-----3小節目
1拍目 　194
2拍目 162
3拍目 131
4拍目　96
-----4小節目
1拍目 　58
2拍目 25
3拍目 39
4拍目　96
僕には、ランダムとしか思えませんでした。
klopGeistは、
１回目は、+460サンプル付近の遅延で４小節。
２回目以降は、-50サンプル付近の遅延で4小節（その後、安定して-50サンプル付近でした）
１回だけ、 460などという、問題外の遅れが起きておりますが、その後は、-50の遅れで安定しており、
どちらかをクリックとして使うならklopGeistなのかな、と思っております。
ただ、 このklopGeistも、 MIDI（プラグイン楽器の）のデータがある
シーケンスの上に、同じことを行うと、2000サンプル遅れてしまいます。
ここまでが、今のところの僕の、つめの甘いものですが、検証です。
----------------
OS 10.4.7
logic7.2.2
MacBookPro1.83 memory=2G
プリロール１小節
●環境設定＞オーディオ＞ドライバー
プラグイン補正　オフ
ドライバー　内蔵マイク　
I/Oバッファーサイズ　512
レコーディングディレイ　0
プロセスバッファーレンジ　ミディアム