名前付きパイプのarecord wavファイルサイズの制限

名前付きパイプのarecord wavファイルサイズの制限

想像する:

オペレーティングシステム:ラズベリーバスター

  1. 次のオーディオチェーンがありますUSBオーディオ入力->record->named Pipe->forked-daapd。現在の構成では記録そして フォークされたdaapd標準に応じてすべての設定システム提供する。
  2. 目標は、ターンテーブルからネットワークオーディオエンドポイント(SONOS)にオーディオを送信することです。
  3. パイプラインのレコード部分は非常に簡単です。arecord -Dplughw:1,0 -t wav -f cd /srv/music/phono-source
  4. mkfifoを使用して名前付きパイプ(「phono-source」)を作成してから起動すると記録そしてフォークDAAPサービス、すべてが期待どおりに動作しているようだった。
  5. 設定を実行しているが「アイドル」のままにすると、つまりカルーセルを使用しない場合、後で元の名前付きパイプオブジェクトの名前が「phono-source-01」に変わり、サイレント/ノイズを効果的に生成すると仮定して新しいオブジェクトの名前これが変わります。パイプされていない汎用ファイル「phono-source-02」が生成されます。 arecord は現在、予想される速度でサイズが増加する新しいファイルにデータを書き込んでいます。
  6. オーディオ出力がwavファイルの最大サイズに達したことに気づくまで、しばらく混乱しました。しばらく実行したところ、phono-source-02が2147483692バイトに達したときに、出力が新しい一般ファイルphono-source-03に戻ったときにある程度確認されました。
  7. 私はwavファイルに2Gig制限があることを漠然と知っていますが、これが物理ファイル制限であると仮定しています。この場合、パイプへの書き込みのため適用されません。明らかにそうではありません。ここでの無差別アプローチは、各アルバムがターンテーブルで再生された後にレコードサービスを終了し、新しいアルバムが起動したときにそれを開始することです。

パイプに他のタスクを実行するか、soxなどの代替オーディオグラバーを使用してこの問題を回避する戦略に関する提案がありますか?

どんなアイデアがありますか?

ベストアンサー1

ソースコードを見るとaplay.c/arecord.c、次の形式のテーブルが表示されます。

static const struct fmt_capture {
    void (*start) (int fd, size_t count);
    void (*end) (int fd);
    char *what;
    long long max_filesize;
} fmt_rec_table[] = {
    {   NULL,       NULL,       N_("raw data"),     LLONG_MAX },
    {   begin_voc,  end_voc,    N_("VOC"),      16000000LL },
    /* FIXME: can WAV handle exactly 2GB or less than it? */
    {   begin_wave, end_wave,   N_("WAVE"),     2147483648LL },
    {   begin_au,   end_au,     N_("Sparc Audio"),  LLONG_MAX }
};

したがって、WAVファイルのサイズは設計上制限されていることがわかります。

運が良いかもしれません-t raw(サンプルレートなどの追加パラメータが必要な場合があります)、または-t au(Sun Sparcオーディオファイル形式)forked-daapdこれを処理できると仮定すると(私は使用したことがありませんforked-daapd)。 64ビットシステムでは、LLONG_MAXは9223372036854775807で、ファイルがそのサイズに達するまでファイルシステムでエラーが発生する可能性があります。

WAVファイルが必要な場合、この形式のファイルヘッダーサイズは2 GBを超えることはできないため、ほとんどの実装には何らかの制限があります。最大ファイルサイズ。

私は、「ストリーミングモード」(私が知っている限り、実際にWAV仕様に違反している)があるレコーダーの特定の実装について知らず、意図的にこれを無視します。それはそれが存在しないという意味ではありません。

おすすめ記事