入力データ

(batch_size, timesteps, features) が入力になる。batch_size はこのバッチ（学習・予測の1単位）中のサンプル数 (予測するデータの数) で stateless なら None (可変長) にできる、timesteps は与える時系列の長さ、features は特徴量。

features は 例えば1次元の波形データであれば 1 になる。3つのセンサーデータがある場合なら3になる。

timesteps は固定長にもできるし、可変長にもできる。可変長の場合は None を指定する。可変長といっても、単一バッチ中の timesteps の数は揃える必要がある。

timesteps を変えても RNN レイヤーのパラメータ数は変化しない。パラメータ数は features のサイズとRNNのユニット数に依存する。

timesteps とバッチ

stateless RNN の場合、RNN の内部状態はバッチごとにリセットされる。

1つのサンプルの出力は、与えた timesteps の数からしか影響されない。また、バッチ内の各サンプルは独立している。

例えば以下のような (3, 5, 1) なバッチを与えた場合、stateless RNN は、1つ目のサンプルに関しては [1, 2, 3, 4, 5] という情報をつかって 6 を予測するようになる。2つ目のサンプルも同様で、1つ目のサンプルとは内部状態が独立して (学習した重みはもちろん共有しているが) [ 2, 3, 4, 5, 6] から 7 を予測する。

# batch_input_shape = (3, 5, 1)
1 2 3 4 5 -> 6
2 3 4 5 6 -> 7
3 4 5 6 7 -> 8

stateful RNN

stateful の場合は手動でリセットしない限り、バッチの最後の内部状態はリセットされない。

極端な例だと1回のバッチで timesteps が1というこもありうる。混乱しやすいのでサンプル数1で例を示してみる。

以下のように3回のバッチにわけてstateful RNNへ入力を与える。すべてサンプル数 (batch_size) は固定。timesteps の数は任意。stateless ではリセットしていたバッチ最後の各サンプルの最後の状態を保持しているので、batch #2 では、1つのtimestepsを与えているだけだが、それまでの timesteps である 1 2 3 4 5 も考慮された状態で予測される。

# batch #1 shape = (1, 5, 1)
1 2 3 4 5 -> 6

# batch #2 shape = (1, 1, 1)
6 -> 7

# batch #3 shape = (1, 2, 1)
7, 8-> 9

stateless to stateful

statelessで学習させて stateful に予測させるということもできる。これらの違いは内部状態をバッチ間で共有するかどうかだけなので、十分に長い系列で学習しているならあまり問題はない。この場合は、学習時に与えたステップ数しか考慮されていないが、連続で推論して新しい系列を得たいときはstateless より早く予測できる (途中の状態を保持したままなため再度過去の時系列を与える必要がない)。

stateful で学習させるのは結構めんどうくさいので、stateless で十分に長い時系列を与えて学習させて、リアルタイム予測などで実際に使うときは stateful にするというやりかたはありかもしれない。

stateless to statefulの例

space = np.linspace(0, 1, 1000)
data = signal.square(2 * np.pi * 50 *  space) * signal.square(2 * np.pi * 30 *  space) / 2 + 0.5

def create_model(batch_size=None, timesteps=None, stateful=False):
    inputs = Input(batch_shape=(batch_size, None, 1))
    x = inputs
    x = GRU(32, stateful=stateful, return_sequences=False)(x)
    x = Dense(1, activation='sigmoid')(x)
    outputs = x
    model = Model(inputs, outputs)
    model.compile(optimizer=keras.optimizers.Adam(lr=0.01), loss='binary_crossentropy', metrics=['accuracy'])
    return model

model = create_model(timesteps = 100)
model.summary()

gen = keras.preprocessing.sequence.TimeseriesGenerator(data[:-10].reshape( (len(data)-10), 1 ), data[10:], length=100)
model.fit_generator(gen, epochs=30, validation_data=gen, shuffle=False)

tstart = time.time()
predict_len = 500

start = 207
result = []
for n in range(predict_len):
    predicted = model.predict( data[start+n-100:start+n].reshape( (1, 100, 1) ) )
    result.append(predicted[0])

result = np.array( result)

elapsed = time.time() - tstart
print('predict {}ms'.format(elapsed * 1000))

plt.figure(figsize=(10,10))
plt.subplot(211)
plt.title('expected')
plt.plot(data[start+10:start+500+10])
plt.plot(result)
plt.subplot(212)
plt.title('predicted (stateless)')
plt.plot(result)
plt.show()

result_stateless = result

model.save_weights('/tmp/param.hdf5')
model_stateful = create_model(batch_size = 1, stateful=True)
model_stateful.load_weights('/tmp/param.hdf5')
model_stateful.summary()

tstart = time.time()

start = 207
result = []
## preload same state with stateless
# model_stateful.predict( data[start-1-100:start-1].reshape( (1, 100, 1) ) )
for n in range(predict_len):
    # give just new 1 timestep
    predicted = model_stateful.predict( data[start+n-1:start+n].reshape( (1, 1, 1) ) )
    result.append(predicted[0])
    
result = np.array( result)

elapsed = time.time() - tstart
print('predict {}ms'.format(elapsed * 1000))

plt.figure(figsize=(10,10))
plt.subplot(311)
plt.title('predicted (stateless)')
plt.plot(result_stateless)
plt.subplot(312)
plt.title('predicted (stateful)')
plt.plot(result)
plt.subplot(313)
plt.title('predicted (stateful+stateless)')
plt.plot(result_stateless)
plt.plot(result)
plt.show()

input channel 数はちゃんと2なのに同じデータが入っている

モノラルになるとかじゃなく、ステレオ入力すると、デフォルトではモノラル結合されて、同じデータが2チャンネルにコピーされて流れてくる。

解決方法

echoCancelation が有効だとこういう挙動になるらしく、これを止めさせるとちゃんとステレオデータがとれる。getUserMedia で以下のように指定する。余計なことをできるだけ止めさせたい場合はいろいろ指定する必要がある。

const stream = await navigator.mediaDevices.getUserMedia({
        audio: {
                channelCount: {ideal: 2, min: 1},
                echoCancellation: { exact: false },
                noiseSuppression: { exact: false },
                autoGainControl:{ exact:  false },  
        }
});

ref

• https://bugs.chromium.org/p/chromium/issues/detail?id=387737#c4

こういう感じ

タスクは N=4096 の複素数のFFTをやることとした。rust 側のコードは rustfftを呼ぶだけ。

以下のような組合せで実行

• [wasm] instance wasm_bindgen
  • wasm_bindgen が生成した struct のJSブリッジを使って普通にAPIを呼ぶ
    • API呼び出し時に必ずJSからWASMにTypedArray のコピーが発生する
• [wasm] instance pointer
  • wasm_bindgen が生成した wasm を直接使って struct のポインタ、バッファのポインタを自力で管理する
  • WASMからメモリを確保して直接使っているのでコピーが減る
• [wasm] one func pointer, one func wasm_bindgen
  • rust 側の FFT インスタンスを使い捨てるバージョン。あまり意味はないが事前計算がどれぐらい重いのかわかる。
• [js] instance dsp.js
  • dsp.js の FFT インスタンスを使う場合。厳密には入力・出力が普通のFFTと違うので、参考程度 (入力が実数だけコピーもしてない、出力の振幅を余計に計算しているなど)

N = 4096
[wasm] instance pointer x 8,361 ops/sec ±0.23% (97 runs sampled)
[wasm] instance wasm_bindgen x 7,869 ops/sec ±0.23% (99 runs sampled)
[wasm] one func pointer x 2,730 ops/sec ±0.48% (95 runs sampled)
[wasm] one func wasm_bindgen x 2,753 ops/sec ±0.34% (97 runs sampled)
[js] instance dsp.js x 3,722 ops/sec ±0.74% (92 runs sampled)
Fastest is [wasm] instance pointer
+------------------------------+--------------------------+----------------------------+---------------------------------+-------------------------+---------------------------------+----------------------------+
| name                         | ops                      | vs [wasm] instance pointer | vs [wasm] instance wasm_bindgen | vs [js] instance dsp.js | vs [wasm] one func wasm_bindgen | vs [wasm] one func pointer |
+------------------------------+--------------------------+----------------------------+---------------------------------+-------------------------+---------------------------------+----------------------------+
| [wasm] instance pointer      | 8360.9ops/sec (+/-0.23%) | -                          | 6%                              | 125%                    | 204%                            | 206%                       |
+------------------------------+--------------------------+----------------------------+---------------------------------+-------------------------+---------------------------------+----------------------------+
| [wasm] instance wasm_bindgen | 7869.3ops/sec (+/-0.23%) | -6%                        | -                               | 111%                    | 186%                            | 188%                       |
+------------------------------+--------------------------+----------------------------+---------------------------------+-------------------------+---------------------------------+----------------------------+
| [js] instance dsp.js         | 3721.9ops/sec (+/-0.74%) | -55%                       | -53%                            | -                       | 35%                             | 36%                        |
+------------------------------+--------------------------+----------------------------+---------------------------------+-------------------------+---------------------------------+----------------------------+
| [wasm] one func wasm_bindgen | 2752.8ops/sec (+/-0.34%) | -67%                       | -65%                            | -26%                    | -                               | 1%                         |
+------------------------------+--------------------------+----------------------------+---------------------------------+-------------------------+---------------------------------+----------------------------+
| [wasm] one func pointer      | 2730.0ops/sec (+/-0.48%) | -67%                       | -65%                            | -27%                    | -1%                             | -                          |
+------------------------------+--------------------------+----------------------------+---------------------------------+-------------------------+---------------------------------+----------------------------+

https://github.com/cho45/wasm-fft-sketch/blob/master/sketch.js#L174

とりあえず何も考えずに pure rust のライブラリをコンパイルして呼んでいるだけなのに、wasm 版が早い (rustfft が良いのかもしれないが)。

計算の比重が高いからか、意外とメモリコピーしてていても差がでない。

wasm_bindgen の使い勝手がいい

wasm_bindgen と wasm-pack が大変使い勝手が良く、ほぼ悩むことなく即 Rust のコードを書きはじめて、またそれをすぐに JS から呼ぶことができる。内部的には Rust 側のブリッジ関数と JS 側のブリッジ関数を同時に作ってくれている。

少し効率的な実装に置き換える

ただ、wasm はメモリ空間が JS のメモリ空間と分かれているため、wasm_bindgenが生成するJS側のブリッジ関数は (便利ではあるが) 若干非効率な実装になっており、TypedArray の受け渡しではコピーが多くなる。

これを防ぐには、やはり自力で wasm 側のメモリ空間からメモリを確保して TypedArray をインスタンス化して使用し、必要なくなったら free するという、メモリ管理を自分でやる必要がある。

これはまぁまぁ面倒くさいが、生成されたJSコードを読めばどう呼べば適切かは容易にわかるので、とりあえずは難しいことではない。

メモリ管理は必要

生成コードをただ使う場合、関数呼び出しだけなら生成コード内でメモリのfreeが行われるので、あまり気にする必要はないが、struct に関しては生成コードをただ使っている場合でも、明示的にオブジェクトの free を呼ぶ必要がある。JS にはデストラクタがないので仕方ないが、注意がいる。

AudioWorkletNode と AudioWorkletProcessorの使いわけ

AudioWorkletNode と AudioWorkletProcessor をうまく使いわける必要があるのですが、今回は以下のようにしています

• AudioWorkletProcessor (audio スレッドで動く)
  • 入力をそのまま出力にコピーするだけ
  • 入力をバッファとして貯めこみ、port 経由で AudioWorkletNode にそのまま転送する
• AudioWorkletNode (メインスレッドで動く)
  • AudioWorkletProcessor からくるバッファを管理し、FFT 用のバッファを保持する
  • getFloatFrequencyData() に応じてバッファの内容をFFTして返す
  • 対数変換やUSB/LSBの並び換え(fftshift)も rust でやってます

こういう構成なので、wasm は普通にメインスレッドで読みこんでメインスレッドで使っています。Analyser の場合は audio スレッドで信号内容に手を加えるということはしないので、余計なことを audio スレッドでやらせたくないという気持ちがあります。

もともと WebAudio にある AnalyserNode とインターフェイスを似せようとすると同期的にしなくてはいけないので若干制約があります。全部非同期にすればもうちょいやりようがある気はします。

wasm_bindgen を使おうと思ったが…

wasm_bindgen の JS 側の実装は Uint8Array を文字列化するために TextEncoder を使っている。しかし TextEncoder は AudioWorkletGlobalScope には(今のところ)存在しておらず、エラーになってしまった。

自動生成されたコードに手を入れて使うのはあまりやりたくないのと、どっちにしろメモリ管理を自力でやる必要はあるので、wasm_bindgen の生成するJSコードは使わず、直接 wasm を呼びだすようにした。

なおエラーメッセージの転送などで、どうしても Uint8Array から文字列を生成したいケースはある。今回は ASCII 以外の文字が入ることは想定していないので TextEncoder の代わりに String.fromCharCode() でお茶を濁した。

wasm module を AudioWorkletGlobalScope に受け渡す

AudioWorkletGlobalScope にはそもそも fetch もないため、wasm のコードを AudioWorkletGlobalScope 内で直接読みこんでインスタンス化することができない。

どうするかというと、メインスレッド(など)で fetch を行い、wasm のモジュールを得てから、これを postMessage で transfer するという余計な手順が必要になる。

wasm module は postMessage ができるが、wasm の instance はできないので、instance 化は AudioWorkletGlobalScope 側でやる必要がある。

概要

無線機の出す I/Q 信号をサンプリングして 2ch (ステレオ) としてコンピュータに入力し、これを直接 WebAudio から扱って音声までデコードする。ソフトウェア側はブラウザだけで完結する。

実用レベルではないが SSB の復調まではできたので一旦記録しておく。

• レポジトリ https://github.com/cho45/webaudio-sdr

前提条件

何を作ればいいか

• IQ シグナルを受けとって復調周波数にバンドパスフィルタをかける
• フィルタした信号を音声周波数に周波数変換をする
  • USB なら 0Hz〜nHz、LSB なら -nHz〜0Hz に変換する
• 実信号に変換する
• オーディオ信号として出力

どちらのサイドバンドを復調するかはバンドパスフィルタの時点で選択して抽出する。その後適切に周波数変換して、real だけとれば音声として聞こえる。

デバッグのために

音声信号はそこそこ流量があるので、print デバッグみたいなことは難しい。せっかく WebAudio なので、適時ブラウザ上に可視化しながら実装をすすめる。問題に気付きやすいし、なによりそのほうが楽しい。

複素バンドパスフィルタ

複素バンドパス フィルター設計
- MATLAB & Simulink
- MathWorks 日本 この記事がわかりやすい。

• 実数ローパスフィルタは、負の周波数まで考慮すると0Hzを中心としたバンドパスフィルタとみなせる (実数フィルタは0Hzで折り返す)
• 実数ローパスフィルタに周波数変換をほどこすことで任意の周波数の複素バンドパスフィルタにできる

これによって -nyquistFreq 〜 +nyquistFreq の任意の範囲を取り出すことができる。

周波数変換 (複素ミキサー)

既に複素数の信号をさらに周波数変換する。LO (ローカルオシレータ) 周波数の cos/sin を複素数で元の信号に乗算する。

複素ミキサーの良いところは原理的にはイメージが発生しないというところ。普通のミキサーでは LO に対して -LO と +LO の信号が発生するが、それがない。

実信号に変換

周波数変換を経て ±n Hz 〜 0Hz の信号になっているので、real だけとって実数にする。これを出力すれば音声が出てくる。