ライブ再生のために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を使用することも良い考えではありません。また、ネットワーク受信機(この場合はnc
RPi)で使用される送信バッファサイズを制限する必要があります。全体として、これは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
:任意に選択できるc
a
オーディオ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を理解するプログラムなら完全に自由にお使いいただけます。