フレクトのクラウドblog re:newal

http://blog.flect.co.jp/cloud/からさらに引っ越しています

Remote Audio forwarding with PulseAudio with complete setup

This is Shuochen from R&D research division from Flect. In this blog I would like to demonstrate how to setup PulseAudio so you can forward audio from local PC to the remote instance.

Introduction

What is audio forwarding? Why do we need it?

First of all, I would like to explain what is audio forwarding. Audio forwarding is the act of redirecting the sound stream from one device to another device​. The way to achieve audio forwarding depends on the Operation System (OS), in this blog we focus on Linux based systems and Mac OS because PulseAudio is designed for the Linux system.

Now to answer the question on why do we need audio forwarding. Imagine you live in a two floor house and you have two laptops. One laptop is upstairs and one laptop is downstairs. Suppose you want both laptops to play the same music. How would you achieve that? This is done by audio forwarding, we are redirecting the audio output from one laptop to another laptop so both laptop can play the same music. The same idea can be extended to a remote device anywhere in the world that is connected to the internet.

Now suppose we have a remote cloud instance. The remote instance could be a Google instance, an AWS instance or an Oracle instance. However, they share the common characteristics of not having a sound card or microphone. Even if they do have a sound card, you cannot hear them due to physical distance is too far away! If you are developing an audio application, how can you hear what is playing on the remote instance? Again we can achieve this with audio forwarding. We stream the audio output from the remote instance to the local computer so we can hear it. It is also possible to do the reverse: we can stream our microphone input from the local computer to the remote instance.

There are multiple softwares which allow audio forwarding, with PulseAudio being one of the possible choice. The reason that I chose PulseAudio is that it is installed by default on Linux computers.

Types of audio forwarding

Before moving to explain on how to achieve audio forwarding, it is necessary to understand that there are 2 types of audio forwarding. Audio forwarding within the same network and audio forwarding for different networks.

Audio forwarding within the same network is the first example which we share the audio between laptops in the same house. The devices could be further away (for example same building), but the idea is the same. They are connected to the same network. When in the same network, the device can access to each other directly using the private IP address. Therefore, audio forwarding within the same network is easy. There are multiple ways to achieve audio forwarding: direction connection, tunneling, mDNS services and RTP protocol. In this blog I will focus on setting up audio forwarding in different networks.

Usually, it is common for devices to be in different networks. It is common for our devices at home to join a router and then connect to the internet. This means the devices are typically behind NAT (Network address translation)​. In other words, it is not directly accessible from the internet. This is desired for security reasons but it creates a problem for audio forwarding. If it is not directly accessible then we cannot forward any sound stream.

Therefore the first step for audio forwarding is to establish a connection between the remote instance and the local PC. There are 2 ways this can be achieved and I will explain each of the method in the next section.

Setting up connection

Port forwarding

The first method, which is straightforward in the concept but more complicated in the setup is to use port forwarding. You may already have done port forwarding before for certain games (for example Minecraft).

It is not a good idea to allow any traffic to access your local computer without any restrictions. What we will do instead, is to allow the internet to access the local computer only on one port. Because PulseAudio uses the port 4713 by default, this will be the port that will be port forwarded. Basically this means, any request for the port 4713 to your public ip address will be forwarded to your local computer.

Unfortunately, the steps of port forwarding depends on the router so there is no universal guide. The website https://portforward.com/, has a good comprehensive summary for how to do port forwarding.

After you have completed the port forwarding, please do check for the firewall and allow for access to the port 4713. The firewall setting includes both the firewall list of the router and the firewall options of the OS.

To test for connection, type telnet ip_address 4713 in the remote cloud instance.

SSH

SSH is the secure alternative for establish connection between the remote server and the client. In particular we will use SSH -R option to establish a reverse tunnel from the remote server back to the client. Normal SSH establishes the connection from the client to the server. However, we also require the reverse process for PulseAudio to work. That is, establish the connection from the server to the client. This is not difficult because usually remote instance requires SSH to connect to it anyway. We are just including additional parameters to also create a reverse tunnel.

In order to set up a reverse tunnel, run the command ssh –R port1:127.0.0.1:4713 username@ip_address when connecting from the client to the server. Port1 can be any port number of your choice, as long it is not used. 127.0.0.1 means local host, because we are forwarding the request from the localhost of the server back to the client. Finally, 4713 is the default port number used by PulseAudio. Unless you have a good reason to change it, use this port number.

Again to test the connection, type telnet ip_address 4713 in the remote cloud instance.

Installing required modules​

Installing required modules should be rather simple. The required modules are SSH and PulseAudio itself. Both SSH and PulseAudio should be installed by default. If for some reason PulseAudio is not installed on the distribution, install it with sudo apt install pulseaudio

For Mac OS, install it with brew install pulseaudio

Setting up the server

Just to be clear, when I use the term server here it means the PulseAudio server, not the SSH server which you connect to. PulseAudio server needs to be the device with the actual sound device on it, otherwise we will not hear any sound output.

Edit the configuration file

After installing PulseAudio, we need to edit the configuration file. We edit the configuration file with sudo nano ~/.config/pulse/default.pa. In this file (default.pa), enable the line load-module module-native-protocol-tcp auth-anonymous=1​. In other words, delete the * sign in front for the line to take effect. auth-anonymous=1​ means we do not restrict on who can connect to the server. You can set the IP of the client to only allow the remote instance to connect it.

Restart the service

After changing the configuration, it is necessary to restart the PulseAudio service. For Mac OS, type brew services restart pulseaudio in the terminal.

For Linux distrubutions, first type pulseaudio -k, then type pulseauido --start

Setting up the client

Now we need to repeat the same steps to set up the PulseAudio client. In this case, PulseAudio client is the the device on the remote client, which will connect to the PulseAudio server. It is possible for multiple clients to connect to the same server, should it be required.

Edit the configuration file

Again, we need to edit the configuration file with sudo nano ~/.config/pulse/default.pa. In this file (default.pa), enable the line load-module module-native-protocol-tcp​. In other words, delete the * sign in front for the line to take effect. auth-anonymous=1​ is no longer required because the client side does not perform authentication.

In addition, 2 additional modules should be enabled. Module-tunnel-source and module-tunnel-sink. Module-tunnel-sink-new provides audio forwarding for the sink, which is the speaker output from the remote cloud instance (client), back to the server (local computer). Module-tunnel-source-new provides the audio forwarding of the microphone input from the server to the client.

To enable module-tunnel-sink-new module, enable the line load-module module-tunnel-sink-new server=127.0.0.1:6666 sink_name=Sound​. This is assuming you have provided a reverse tunnel in SSH with the port number 6666. In the case of port forwarding, the server argument would your global IP of your local computer and the port number should be 4713.

For the load-module module-tunnel-source-new module, enable load-module module-tunnel-source-new server=127.0.0.1:6666 source_name=Mic.

Both the argument sink_name and source_name are optional. Restart the service as before.

Test the connection

That is all the steps required to set up the PulseAudio. Now any audio you play on the remote client will be forwarded back to the local computer and the any microphone input from the local computer will be forwarded to the remote client. This is very convenient for developing audio applications on the remote client.

Optional adjustment

If the PulseAudio server has multiple devices. It is possible to specify which device to use for audio forwarding. We can select the device by its index (the information is shown by pacmd list-sources or pacmd list-sinks) in this way:​

pacmd set-default-sink 1, pacmd set-default-source 1

Restart the PulseAudio on both the server and client to take effect​.

Reference links

Complete guide on port forwarding
https://portforward.com/
PulseAudio wiki
https://wiki.archlinux.org/title/PulseAudio#Networked_audio
PulseAudio official page
https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Modules/#module-cli-protocol-unixtcp

Amazon Chime SDKの新機能 背景置き換え機能(≒仮想背景機能)を使ってみた

こんにちは。研究開発室の岡田です。

先日(2022/1/25)、Amazon Chime SDK for Javascript に待望の背景置き換え機能が追加されましたね。

aws.amazon.com

これまで、Amazon Chime SDKアプリ開発者は独自の方法で仮想背景機能を作成する必要がありましたが()、AWS 公式での今回の機能追加によって、よりシンプルに仮想背景機能を作成することができるようになりました。

また、この機能は以前より提供されていた Amazon Chime SDK for Javascript の Video Processing API を使用して実現されているので、この機能を使用していた開発者(例えばBackground Blur)にとっては、ほとんど追加の学習なく使用できるようになっています。

それでは、どのような感じで動くのか、仮想背景機能を作成して試してみましょう。作成した仮想背景機能の動作は次のような感じになります。 ezgif com-gif-maker

続きを読む

MuleSoft開発 Salesforceを使用してSSOを実現する - OpenID Connect編

こんにちはCI事業部の川瀬です。

前回に引き続きSalesforceを使用してSSOを実現したいと思います。今度はOpenID Connectを使用します。前置きは省略し実際にやっていきましょう!

では、Salesforceの設定から実施していきましょう。途中までは、前回のSAML編と同じです。

1. Salesforceで「私のドメイン」を設定する。

f:id:k2-flect:20220115121228p:plain

2. Salesforceで「IDプロバイダの有効化」を有効化する。

f:id:k2-flect:20220115110936p:plain

3. Salesforceで「接続アプリケーション」を作成する。

下記の画面で、「接続アプリケーション名」、「API 参照名」、「取引先責任者 メール」に対し、任意の値を設定してください。 f:id:k2-flect:20220115111718p:plain

下記の画面で、「OAuth 設定の有効化」をチェックしてください。 f:id:k2-flect:20220115200922p:plain

3.1 「コールバック URL」の設定

コールバック URLには何を設定するのでしょうか?どこを探してもそのような記事はないです。そうなんです、この時点では設定すべき値はどこにも存在しないので、「https://hoge.hoge.com」で大丈夫です。

3.2 「選択した OAuth 範囲」の設定

選択した OAuth 範囲には何を設定するのでしょうか?全部設定してしまうことが簡単ですが、気になりますよね。これもどこを探しても、何を設定すべきかを記載している記事はないです。
ここでは次の2つを設定すれば大丈夫です。
・ID URL サービスにアクセス
・一意のユーザー識別子にアクセス
設定したら、「保存」ボタンを押します。

3.3 「コンシューマ鍵」と「コンシューマの秘密」

保存ボタンを押すと以下の画面に遷移します。そうしたら、「コンシューマ鍵」と「コンシューマの秘密」を保存しておいてください。後で使います。 f:id:k2-flect:20220115202552p:plain

4. 「Identity Provider」の設定

ここからは、Anypoint Platformの作業になります。 Access Managementの「Add Identity Provider」→「OpenID Connect」を選択します。 f:id:k2-flect:20220115114127p:plain

4.1 「Use manual registration」の設定

以下の図で「Use manual registration」をクリックします。 f:id:k2-flect:20220115203052p:plain

そうすると、次の図のようになります。 f:id:k2-flect:20220115203322p:plain

4.2 「Name」の設定

はい、適当に任意の値を設定してください。

4.3 「Client ID」の設定

手順3.3で取得した「コンシューマ鍵」を設定してください。

4.4 「Client ID」の設定

手順3.4で取得した「コンシューマの秘密」を設定してください。

4.5 「OpenID Connect Issuer」の設定

https://≪MYDOMAIN≫.my.salesforce.com/services/oauth2​/clients
≪MYDOMAIN≫は手順1で取得した値です。

4.6 「Authorize URL」の設定

https://≪MYDOMAIN≫.my.salesforce.com/services/oauth2/authorize

4.7 「Token URL」の設定

https://≪MYDOMAIN≫.my.salesforce.com/services/oauth2/token

4.8 「User Info URL」の設定

https://≪MYDOMAIN≫.my.salesforce.com/services/oauth2/token
はい、ここまできたら「Save Changes」を押してください。

4.9 「redirect URI」の取得

保存したら、再度、開いてください。図のようにredirect URIが設定されています。 f:id:k2-flect:20220115204307p:plain

5. Salesforceに「コールバック URL」を設定する

手順3.3で「https://hoge.hoge.com」を設定しましたよね。これを手順4.9で取得した値に置き換えます。

6. SSOの確認

Anypoint Platformにログインしている場合は、一旦、ログアウトし、下記のURLブラウザに入力してください。 https:/anypoint.mulesoft.com/accounts/login/DOMAIN-NAME
DOMAIN-NAMEはAnypoint Platformaのドメインです。組織ドメインは以下の図の箇所で確認できます。 f:id:k2-flect:20220115112822p:plain

Salesforceのログイン画面がでてきてログインできましたか?成功するとAnypoint Platformのユーザーに以下のようなユーザーが登録されています。

f:id:k2-flect:20220115121353p:plain

前回に引き続き、「OpenID Connect」を使用したSSOの設定方法を紹介しました。分かると簡単なのですが、「コールバック URL」など肝心なところの説明、設定方法が欠落しておりイライラしてしまいます。

なんでこんなことを紹介したかというと、勿論Salesforceを導入しているならそちらでアカウント管理したほうが便利ですよね。更に、API Community Managerなるものがあり、こちらの事前設定で必要になるのです。

docs.mulesoft.com

次回は、「クライアント認証」か「Standalone」について説明するつもりです。

MuleSoft開発 Salesforceを使用してSSOを実現する - SAML編

こんにちはCI事業部の川瀬です。

今回はSalesforceを使用してSSOを実現したいと思います。具体的はAnypoint Platformにログインするときに「Salesforceアカウントを使用」しますということになります。

具体的には以下のサイトを手掛かりに設定を行うのですが、よく分からないので、図で示しながら、簡潔に説明していきます。 docs.mulesoft.com

では、Salesforceの設定から実施していきましょう。

1. Salesforceで「私のドメイン」を設定する。

f:id:k2-flect:20220115121228p:plain

2. Salesforceで「IDプロバイダの有効化」を有効化する。

f:id:k2-flect:20220115110936p:plain

3. Salesforceで「接続アプリケーション」を作成する。

下記の画面で、「接続アプリケーション名」、「API 参照名」、「取引先責任者 メール」に対し、任意の値を設定してください。 f:id:k2-flect:20220115111718p:plain

下記の画面で、「SAML の有効化」をチェックしてください。そうすると、いくつかの項目は自動で生成されるのでそのままで大丈夫です。 次に、「開始 URL」、「エンティティ ID」、「ACS URL」に対し値を設定していきます。 f:id:k2-flect:20220115111951p:plain

3.1 「開始 URL」の設定

https://anypoint.mulesoft.com」を設定してください。

3.2 「エンティティ ID」の設定

Anypoint Platformの組織ドメインをDOMAIN-NAMEとすると、「DOMAIN-NAME.anypoint.mulesoft.com」を設定してください。 組織ドメインは以下の図の箇所で確認できます。 f:id:k2-flect:20220115112822p:plain

3.3 「ACS URL」の設定

私がいろいろ調べたのですが、よく他の記事では「ACS URLはサービスプロバイダで取得した値を設定してください。」と記載されています。じゃ、MuleSoftの場合は何ですか?となります。 どこかに記載してあるのかもしれませんが、この段階では実は存在しないのです!ここがポイントです。 なので、適当に「http://hoge.hoge.com」で最初は大丈夫です。この状態で「保存」ボタンを押します。

3.4 「メタデータ」のダウンロード

下記の画面(アプリケーションマネージャで作成した接続アプリケーションのManageを選択)で「メタデータのダウンロード」を選択し、Salesforceの設定情報をダウンロードし保存します。 f:id:k2-flect:20220115113741p:plain

4. 「Identity Provider」の設定

ここからは、Anypoint Platformの作業になります。 Access Managementの「Add Identity Provider」→「SAML 2.0」を選択します。 f:id:k2-flect:20220115114127p:plain

4.1 「メタデータ」のアップロード

手順3.4でダウンロードしたメタデータを「Chose file」を選択しアップロードします。 f:id:k2-flect:20220115114459p:plain

4.2 「Name」、「Sign Off URL」、「Audience」の設定

アップロードとすると、以下の図のようになります。アップロードしたほうが遥かに簡単です。 f:id:k2-flect:20220115115755p:plain

「Name」は適当に設定してください。
Sign Off URL」は「≪Issure≫/services/auth/idp/saml2/logout 」と設定してください。
≪Issure≫はメタデータをアップロードした時に設定されています。4.1の図を見てください。

「Audience」は手順3.2と同じで「DOMAIN-NAME.anypoint.mulesoft.com」となります。 設定したら、「Save Changes」を押します。

4.3 「ACS URL」の取得

保存したら、再度、開いてください。図のようにACSが設定されています。 f:id:k2-flect:20220115120434p:plain

5. Salesforceに「ACS URL」を設定する

手順3.3で「http://hoge.hoge.com」を設定しましたよね。これを手順4.3で取得した値に置き換えます。

6. SSOの確認

Anypoint Platformにログインしている場合は、一旦、ログアウトし、下記のURLブラウザに入力してください。 https:/anypoint.mulesoft.com/accounts/login/DOMAIN-NAME
DOMAIN-NAMEは手順3.2で確認したもの

Salesforceのログイン画面がでてきてログインできましたか?成功するとAnypoint Platformのユーザーに以下のようなユーザーが登録されています。

f:id:k2-flect:20220115121353p:plain

今回は、SAMLを使用しましたが、次回はOpenID Connectで設定する方法を紹介します。こちらも、少しクセがあります。

Bolt for JavaScriptと静的なコンテンツ、REST API, SocketIOを共存させる

本記事は Slack Advent Calendar 2021 の 23 日目の記事です。

こんにちは。研究開発室の岡田です。

はじめに

今年の Advent Calendar では、Slack について7 日目の Slack 通話の内容を Slack 上で見えるようにしようと、AWS について18 日目の Amazon Chime SDK for JavaScript で Among Us Automute とゲーム実況配信 その2を執筆しました。

そして、本記事が今年ラストの Advent Calendar への投稿となります。

上記の AWS Advent Calendar18 日目の 記事を執筆した後、そこで紹介した機能を Slack から起動できるように拡張しました。本記事では、その際に必要となった、 「Bolt for JavaScript の Web サーバ(Express)と、静的なコンテンツ、REST API, Socket.IO を共存させる方法」をご紹介します。

image

続きを読む

Amazon Chime SDK for JavaScript で Among Us Automute とゲーム実況 その2

本記事は AWS Advent Calendar 2021 の 18 日目の記事です。

こんにちは、フレクトの Among us 部所属の岡田です。

はじめに

今回は、Amazon Chime SDK for JavaScript(以降 Amazon Chime SDK と略す)を使って Among Us の Automute 機能+画面配信機能を作った話です。以前のブログでもご紹介したのですが、いくつか改良すべき点があったので、それについてお話しします。

ところで、ちょっとした宣伝ですが、弊社は日本企業で最初の Amazon Chime SDK のパートナーです。また、Amazon Chime SDK について AWS のサイト上でGuest ブログを執筆させていただいていたりもしています。今回の内容は(半分執筆者の趣味で)ゲームを題材としてますが、オンラインビデオを活用した真面目な(?)サービス開発の実績もございますので、興味を持たれましたらぜひ弊社にご相談いただければと思います。1

image


  1. ゲームが不真面目というわけではありません。執筆者はこの記事も本気で書いています。

続きを読む

Slack通話の内容をSlack上で見えるようにしよう

本記事は Slack Advent Calendar 2021 の 7 日目の記事です。

はじめに

こんにちは。研究開発室の岡田です。

ここ数年で多くの企業がリモートワークを導入するようになりました。このような企業では、Slack をはじめ、業務を効率化するために様々なコミュニケーションツールを活用していると思います。しかし、それでも会話や雑談が不足して様々な問題が発生している状況のようです。

参考:会話と雑談の不足で 7 割以上が心的不調

一方で、オフィスのように雑談が突発的に時間を選ばずに発生するような環境のほうが嫌だという人も一定数いそうです。仕事に集中したい時に、近くで面白そうな話を雑談されていると気になって困ることもありますし(自分の意志が弱いだけです。。)。

とはいうものの、やはり楽しそうに話している雑談や興味のある話をしている雑談には混ざりたいです。おそらく、"雑談の内容が面白そうレベル"が"仕事に集中したいレベル"を超える場合があり、そういったときに意識的に参加できるというのがストレスのない環境なのではないでしょうか。

ところで、私の職場では Slack に雑談用のチャネルがあり、そこで Slack 通話を用いて雑談をすることが多いです。Slack 通話を始めてしまうと参加者以外は雑談の内容を一切知ることができません。オフィスで業務している時であれば、雑談の内容が漏れ聞こえてきて、面白そうなら参加するといったこともできました。しかし、Slack 通話の場合は内容がわからないので、私のような引っ込み思案の人たちは参加していいものか迷ってしまいます。もし、Slack 通話の内容を参加者以外が知ることができれば、このような人たちが雑談に加わる機会が増えるかもしれません。また、オフィスでは耳栓でもしないと雑談を完全にシャットアウトするのは難しいです。しかし、Slack 通話の内容を Slack 上で見えるようにする方法であれば意図的に雑談用のチャネルを開かなければ雑談に気を散らされることなく仕事に集中できそうです。

そういうわけで、今回は Slack 通話の内容をチャネル内に表示する "speech-to-text-chat" という Slack App を作ってみましたのでご紹介します。 実際の動きとしては、下図のように Slack 通話の内容がテキストで投稿されるようになります。 image

続きを読む