これまでのところ、これは冒険のようでした。Ubuntu マシン上の Chrome と iPhone 上の iOS Safari 間でリモートデバッグを設定することができましたが、多くの困難がありました。しかし、厄介なことに、最も重要な「Network」タブが空白のままです。
preload="metadata" を設定すると、iOS Safari で最初のクリックでオーディオが再生されることがわかりました。一方、preload="none" に設定すると、実際にオーディオが再生されるまで「再生」→「一時停止」→「再生」のシーケンスが必要になります。
これを video タグでも試してみましたが、同様の問題が存在するようです。
preload="none" への変更は、こちらのバグレポート Secure media uploads expire に基づいて行われました。現在、私たちは少し厄介な「トワイライトゾーン」にいます。preload を metadata に戻すと、上記の問題が再発してしまうからです。最近、プレサイン済み URL の有効期限を 5 分に延長しました（https://github.com/discourse/discourse/pull/10160）。そのため、元のバグは 以前より 少なくなりましたが、まだ問題です。
私はまだこの件について考え、あれこれ試しています。両方の利点を兼ね備えられるかどうかはわかりません。セキュリティ保護されたメディアの表示に複数のクリックを要求するのは、理想的な体験ではありません。
編集：デバッガーの Network タブが機能するようになりました。内部 Discourse インスタンスにおける preload="none" の audio タグの例を示します：
-
再生ボタンを押す：GET /secure-media-uploads/dev/original/4X/6/1/8/618a6b19a07de18205cc9889cb604e414b30372b.mp3 → ステータスは Finished
-
一時停止ボタンを押す。
-
再生ボタンを押す：GET
presigned_url_here→ ステータスは 206 Partial Content、オーディオが正常に読み込まれる。
奇妙なことに、preload="metadata" の場合でも、再生を 1 回クリックするだけで、全く同じリクエストのシーケンスが発生します。Safari は最初の再生クリックでメタデータを取得し、その後にオーディオを再生するには一時停止と再再生が必要のようです。
これが他のデバイス（例：Android）でも発生するかどうかはわかりません。テストできるデバイスを持っていないためです。