Raspberry PiからmacOSにライブサウンドを送信する

Raspberry PiからmacOSにライブサウンドを送信する

ライブ再生のためにRaspberry Piに録音されたサウンドをMacBookにパイプしたいと思います。私は以下を試しました:

私のラズベリーパイから:

ポート3333でストリームを設定しようとしています。

arecord -D plughw:3,0 -f S16_LE 44100 -t raw | nc -l -p 3333

私のMacBookでは:

nc 10.10.1.1 3333 | play -t raw -b 16 -e signed-integer -r 44100 -c 1 -V1 -

これにより、Macでは何も聞こえませんが、端末では次のような出力が得られます。

-: (raw)

 File Size: 0
  Encoding: Signed PCM
  Channels: 1 @ 16-bit
Samplerate: 44100Hz
Replaygain: off
  Duration: unknown

In:0.00% 00:00:00.00 [00:00:00.00] Out:0     [      |      ]        Clip:0
Done.

ベストアンサー1

nc特定のケースでは、設定にどのような問題があるかを実際に話すことはできません。実際にデータを受信して​​いるか(たとえば、ファイルに書き込んだりパイピングして)、実際にキャプチャしていることをpv確認したいと思います。arecordサウンド(パイピングの代わりにファイルに書き込むことによってnc

また、44100Hzがエレガントなサンプリングレートであるかどうかは不明です。最近、ほとんどのハードウェアはデフォルトで48000Hzで動作するため、ALSAでそれを44100Hzに変換するだけです。

さらに重要なのは、受信側がストリーム形式自体を知り、時間を正しく整列させ、損失を補償し、損失を遅らせたり、パケットを並べ替えることを可能にする合理的なトランスポートフレーマーを使用することです。私は、デジタルビデオ放送や他のマルチメディアストリーミングプラットフォームのストリーミングフォーマットとしてMPEG Transport Streamを使用しています。

したがって、待ち時間の短い転送にTCPを使用することも良い考えではありません。また、ネットワーク受信機(この場合はncRPi)で使用される送信バッファサイズを制限する必要があります。全体として、これはarecord | nc 最高のストリーミング方法ではないかもしれません。さらに、アプローチでは、発信者が起きて接続する準備ができた後、受信者が開始するのに必要な遅延と少なくとも同じ遅延を得る。

一部のオーディオをすばやくキャプチャして別のコンピュータに転送する必要がある場合(主にWeb会議の目的で)、「マイクコンピュータ」で次のことを行います。

ffmpeg \
  -f alsa -channels 1  -sample_rate 24000 -i pipewire \
  -f mpegts -max_packet_size 1024 \
  -c:a libopus -b:a 64k -vbr off -packet_loss 10 -fec on \
  udp://127.0.0.1:1234

それを分析しましょう:

  • ffmpeg:私たちが実行しているプログラム、FFmpeg。ほとんどのプラットフォームでは、ほぼ標準のトランスコーディング/ストリーミング/デコードソリューションです。

入力オプション:

  • -f alsa:入力タイプ(「フォーマット」)はalsaです。つまり、alsaサウンドシステムからサウンドを取得します。
  • -channels 1:任意に選択できるモノラルサウンドだけが欲しいです。サウンドデバイス(おそらくステレオ?)を使用して提供されているすべての項目を無視するか、特に異なる数のチャンネルをキャプチャする場合は、別の値に設定します。
  • -sample_rate 24000:任意に選択できる私の主な関心事は音声です。この場合、24kHzのサンプリングレートは優れたオーディオ品質を得るのに十分です(私はまったくなく、私の声は1.2kHzを超えません...)。
  • -i pipewire:ALSAデバイスからキャプチャされましたpipewire。あなたの場合はplughw:3,0そうです。 (使用可能なキャプチャ装置を確認するために使用arecord -L

出力フォーマットオプション:

  • -f mpegts-i入力を説明した後、-f出力形式を説明します。 MPEG トランスポートストリームを転送中です。
  • -max_packet_size 1024:任意に選択できるストリーマーが1024バイトごとに1つのパケットをエクスポートするように強制します。これは発信者の待ち時間を制限します。

オーディオコーデックオプション:任意に選択できる

  • -c:a libopus:任意に選択できる caオーディオlibopusエンコーダで使用されるコーデックの略語, and here we use the 。 OPUSは、複雑さが低く、品質設定に優れた成熟したWeb標準オーディオエンコーダです。
  • -b:a 64k:任意に選択できるしかし、エンコードビットレートを64kb / sに設定しました。品質はかなり高いですが、コンピューティングのパフォーマンスはかなり良いです(コアの最大5%〜20%を考慮)。
  • -vbr off:任意に選択できる強制定数(v可変ビットレートとは対照的に)限られた帯域幅リンクを介してストリーミングする予定であり、高速で短いスパイクでエンコードを実行できない場合、これは意味があります。 LANでは省略しました。
  • -packet_loss 10:任意に選択できる10個のパケットのうちの1つが失われても問題にならないように、パケットの冗長性を設定してください。場合によっては、パケット損失が発生する接続(たとえば、一部のインターネット接続、一部の無線接続など)で強力になります。 LANでは無視します。
  • -fec on:任意に選択できる冗長度を設定した後、実際にこの重複の送信機能も有効にしようとします。F今後金利間違い修正目的。 > 0の場合にのみ意味があります-packet_loss

出力オプション:

  • udp://127.0.0.1:1234ストリーミングするIPアドレスとポート。注目!ここで、受信者はリスニング部分であり、送信者はUDPソケットなので、オーディオストリームを外部にプッシュして誰かが聞くかどうかは関係ありません。これの利点は、必要に応じて受信機を接続して切断できることです。

受信側ではリスニングソケットを開きます。

ffplay -f mpegts -nodisp -fflags nobuffer udp://127.0.0.1:1234

-nodisp-fflags nobuffer入力ストリームパーサーが古いコンテンツに追いつこうとしないように(たとえば、「遅いリスナー」の遅延を避けるために)、ディスプレイが回転します(ビデオをストリーミングしない)。

その場合はご注意ください。遊ぶendは(あなたがしたように)リスニングソケットを開くサーバーですnc -l。必要に応じて、以前に両側でzmq:tcp://使用した場所を使用してそれらを元に戻すことも、udp://サービス「ロガー」piに複数のリスナーを接続することもできます。

nc -u -l -p 1234 | … もちろんMPEG TSを理解するプログラムなら完全に自由にお使いいただけます。

おすすめ記事