コグノスケ

Raspberry Pi - まとめリンク

目次: Raspberry Pi

Raspberry Pi 3 model Bオーディオ周りの話のまとめ。

編集者:すずき(2024/10/24 23:31)

コメント一覧

コメントはありません。

この記事にコメントする

Raspberry Pi 3のオーディオその1 - 波形観察

目次: Raspberry Pi

何気なく使っていたRaspberry Pi 3のアナログオーディオ出力ですが、少し調べてみたところ、かなり変な動きでした。音は出ますが、まともなオーディオ用の回路には見えません。変な点はとりあえず3つ見つけました。

変な点1つ目。サンプリング周波数（fs）の半分、つまり1/2 fsのSin波（fs = 48kHzなら24kHz）が出ません。無音です。オーディオ用のDACならば、1/2 fsのSin波を出すときに波形が崩れることはあろうとも「無音」はあり得ません。この時点でRasPi 3のオーディオ出力は変です。どこかで音が出なくなる周波数がありそうですが、上限の周波数までは調べ切れていません。

変な点2つ目。サンプリング周波数（fs）が44kHz系でも48kHz系でもありません。1/4 fsの矩形波を入力すると出力はSin波になります（フーリエ変換が理想的だった場合、2014年11月20日の日記参照）。他の波形と違い歪みがわかりやすいので、私がオーディオ機器をテストする際によく使います。

本来はSin波になるはずなのにfs = 44kHzでも48kHzでも、Sin波とは程遠い歪んだ波形になります。同じデータをCreative Sound Blaster X-Fi Go! Proで出力するときれいなSin波になります。やっぱりRasPi 3のオーディオ出力はおかしいです。

fs = 44kHz, 1/4 fs = 11kHz Sin波の波形（Raspberry Pi 3）

fs = 48kHz, 1/4 fs = 12kHz Sin波の波形（Raspberry Pi 3）

fs = 44kHz, 1/4 fs = 11kHz Sin波の波形（Sound Blaster X-Fi Go! Pro）

変な点3つ目。なぜかGPUを制御しています。RasPi 3はSoCにBroadcom BCM2837を使っています。サウンドドライバはlinux/drivers/staging/vc04_services/bcm2835-audio/ の下にあるんですけど、このドライバの実装を見るとVideoCore 4と呼ばれているGPUにデータを投げつける実装になっています。

GPUのはずのVideoCore 4にサウンドデータを投げつけると音が再生される、謎の仕組みです。Videoじゃないのに……？？

編集者:すずき(2024/10/24 23:31)

コメント一覧

コメントはありません。

この記事にコメントする

Raspberry Pi 3のオーディオその2 - 周波数スペクトル

目次: Raspberry Pi

引き続きRaspberry Pi 3のオーディオ出力波形がグニャグニャしている謎を調べます。サンプリング周波数の1/4の矩形波を再生（理想的な周波数変換がなされるとSin波になるはず）を出力した際の周波数スペクトルを見ます。パワーを合わせるために波形の最大値を3.2Vくらいに合わせて測ったつもりです。が、RasPi 3の波形は歪んでいてピークがわからないので、合っているか自信ありません。参考程度です。

Raspberry Pi 3のオーディオ出力です。ピークの11kHz以外に15.5kHzや37kHzなど、多数の高調波が出現します。高調波は安定して出現するので、波形の崩れは外乱やノイズではなさそうです。

fs = 44kHz, 1/4 fs = 11kHz Sin波の周波数スペクトル（Raspberry Pi 3）

続いてfs = 48kHzで12kHzのSin波を再生した場合です。12kHz、36.5kHz、60kHz、85kHz付近、つまり3次、5次、7次……のように奇数倍の高調波が出ます。なんだこれ？

fs = 48kHz, 1/4 fs = 12kHz Sin波の周波数スペクトル（Raspberry Pi 3）

Creative Sound Blaster X-Fi Go! Proのfs = 44kHzで11kHz Sin波出力です。きれいに「11kHzのみ」にピークが出ます。オーディオ機器ならこれが普通ですよね。

fs = 44kHz, 1/4 fs = 11kHz Sin波の周波数スペクトル（Sound Blaster X-Fi Go! Pro）

矩形波を周波数領域に変換すると1f, 3f, 5f, ... のように奇数次にスペクトルが出ます。Raspberry Pi 3のオーディオ出力も同じ傾向がありますから、おそらくPWM波形をフィルタしてオーディオ出力を作っているのだろうと予想が立ちます。

編集者:すずき(2024/10/24 23:31)

コメント一覧

コメントはありません。

この記事にコメントする

2021年5月5日

permalink

編集する

ぶきあつめコンプリート

目次: ゲーム

The World is Your Weaponをコンプリートしました。2018年にふりーむ！で公開されたフリーゲーム「ぶきあつめ」のSteam移植版です。ふりーむ！版でも十二分に遊べますが、作者さんを応援したいってことで購入しました。

ぶきあつめコンプリート

Steam版はダンジョン探索ゲームが追加実装されていますが、本筋と関係ないうえ非常に長いです。私はほとんどやってません……。

一応、ふりーむ！へのリンクも貼っておきましょうか。
ぶきあつめ〜なんでも武器になるRPG〜 - ふりーむ！

ぶきあつめでは、近づけるものはほぼ何でも（モノ、人、モンスターなど）武器にできます。RPGをやりなれている人は、スルーしてしまいそうな壁や床といった意外なものまで武器にできます。常識を捨ててプレイしましょう。私のお気に入りは地面の穴、ヘイワ村、海ですね。「ええっ！？それ取れるんだ？？」と思わず笑ってしまいます。しかも案外強いです。海なんてほぼ最強ランクじゃないですかね？

このゲームは剣や杖など普通の意味での武器の形をしているものを除けば、基本的に大きなものほど強い傾向があります。ただし大きなものは上側の視界を塞ぐので非常にゲームがやりづらいトレードオフがあります。特にヘイワ村や海などは上半分がほぼ見えなくなるため、気づかないうちに上からモンスターに殴られることがあります。

エンディングは4つ（通常）＋1つ（シークレット）ですが、Steam版はシークレットエンドが実装されていないのか、条件を満たしても発生しませんでした。ちょっと残念。

メモ: 技術系？の話はFacebookから転記しておくことにした。大幅に追記。

編集者:すずき(2023/09/24 13:30)

コメント一覧

コメントはありません。

この記事にコメントする

2021年5月7日

permalink

編集する

LLVM - まとめリンク

目次: LLVM

一覧が欲しくなったので作りました。

編集者:すずき(2023/09/24 09:15)

コメント一覧

コメントはありません。

この記事にコメントする

2021年5月8日

permalink

編集する

Raspberry Pi 3のオーディオその3 - ボリューム調整

目次: Raspberry Pi

Raspberry Pi 3のオーディオ出力はハードウェアPWMを使っているみたいです。適当にPWMのFIFOレジスタにデータを書き込むと、オーディオ出力に変なスパイクが出ました。さらにPWMのFIFOモードを解除して各PWMチャネルを直叩きすると、LeftがPWM1でRightがPWM0と対応していることもわかります。Raspberry PiのSchematicsとも一致しますし、おそらく間違いないでしょう。

RasPiのAudio OutとHW PWMの出している信号を同時に見たかったので、GPIO Function Selectを直接弄ってGPIO13ピンにPWM信号を同時に出して（※）みました。黄色のCh1がAudio Outで、水色のCh2がPWMの信号です。

fs = 44kHz, 30Hz Sin波の周波数スペクトル（Raspberry Pi 3）

（※）やり方はGPFSEL1のFSEL13（bit 11 - 9）を0b100にするだけです。GPFSEL1はアドレス3f200004にあるので、例えば元の値が0x24000だとしたら0x24800に変えればOKです。

クリッピングの末に

30HzのSin波を再生していますが、頭が欠けたような変な波形になっています。最初は理由がわからなかったのですがFacebookで色々コメントいただいたりして調べているうちに原因がわかりました。ボリュームが大きすぎでした。

先程の波形を取得したときのボリューム設定では0.4dBのゲインが掛かっています。この設定だとSin波の頂上付近がクリッピングされてPWMの出力が100％固定になっています。

ボリューム設定、0.4dBゲイン

fs = 44kHz, 30Hz Sin波の周波数スペクトル（Raspberry Pi 3）0.4dBゲインあり

次がゲインを解除した設定です。PWM波形が100％に張り付いている時間が大幅に減って、オーディオ出力も割と綺麗なSin波になります（実は拡大するとうねってますけど…）。

ボリューム設定、ゲインなし

fs = 44kHz, 30Hz Sin波の周波数スペクトル（Raspberry Pi 3）ゲインなし

色々な周波数を試したところ1kHz, 2kHzくらいまでは割ときれいです。

fs = 44kHz, 1kHz Sin波の周波数スペクトル（Raspberry Pi 3）

fs = 44kHz, 2kHz Sin波の周波数スペクトル（Raspberry Pi 3）

ところが4kHz, 8kHz辺りになってくると波形がウニョウニョし始めます。

fs = 44kHz, 4kHz Sin波の周波数スペクトル（Raspberry Pi 3）

fs = 44kHz, 8kHz Sin波の周波数スペクトル（Raspberry Pi 3）

11kHzになるともはやSin波には見えません。

fs = 44kHz, 11kHz Sin波の周波数スペクトル（Raspberry Pi 3）

編集者:すずき(2024/10/24 23:31)

コメント一覧

コメントはありません。

この記事にコメントする

2021年5月9日

permalink

編集する

Raspberry Pi 3のオーディオその4 - オーディオ出力回路

目次: Raspberry Pi

Raspberry Pi 3のオーディオ出力はHW PWMの出力（矩形波）を何らかのフィルタ回路を通しているのでは？疑問を解決するため、オーディオ出力回路を調べます。

会社のみなさまに回路をシミュレーションするツールLTspiceを教えていただいた（ありがとうございます！）ので、Raspberry Pi 3のSchematics通りに回路を組んで回路シミュレーションをしました。Spiceは聞いたことありましたけど、使うのは初めてです。

私が使っているのはRaspberry Pi 3 model B rev 1.2ですので、rpi_SCH_3b_1p2_reduced.pdfの回路図が該当します。オーディオ出力回路だけ抜粋すると下記のとおりです。

Raspberry Pi 3 model B rev 1.2のオーディオ出力回路

（5/17訂正）
オーディオ出力回路が微妙に違う回路図だった（C58, C60の番号が違う）ので上げ直しました。

前段がRCローパスフィルタ回路、後段がRCハイパスフィルタ回路と思われます。この回路の1ch分をLTspiceで組んでAC特性をシミュレーションしますと、こんな感じになりました。

オーディオ出力回路のAC特性解析

参考までにゲインが -3dBになる周波数（フィルタのカットオフ周波数）に線を足しています。低いほうが1.7〜1.8Hz辺り、高い方が21〜22KHzくらいに見えます。素人目にはfs = 48KHzのとき再生帯域24KHzですから、発生してはならない不要な高周波を落としているフィルタに見えます。

過渡応答特性

フィルタのAC特性はわかったので、矩形波を入れたときにどんな波形になるかも見ておきたいと思います。主に回路の入力やシミュレーション方法をミスっていないか確認のためです。初めて使うので、これで合っているのか？と何かと不安なんです……。

V1の設定を変更して12.5kHzの矩形波を出す設定に変えます。RasPiのPWMは変調速度が少なくとも50MHzはありそう（※）なので、立ち上がり立ち下がりは20nsにしています。

（※）PWMで0と1が交互に出力されるであろうDuty比1/2にすると50MHzとオシロ様がおっしゃっているので、変調速度は50MHzだと思うのですが、本当はもっと速いけど我が家のオシロTektronix TBS 1052Bの測定限界（50MHzモデル）を超えていて、正しく測れていないだけかもしれません。

我が家のオシロは信号の周波数20MHz辺りから波形がミミズみたいになって、何が表示されているのかわからなくなるので、HW PWM信号を直接見るのは無理です。仮に正しく表示できても波形から値を読み取るのは困難ですし、波形の正確性は気にしなくて良いのです。

電圧源の設定

12.5kHz矩形波に対する過渡応答解析

対して実際の出力がこんな感じです。PWMが矩形波に近くなっている中央部分の波形を見ると、オシロの波形とシミュレーションの波形がほぼ同じ波形になっています……よね？

fs = 48kHz, 12kHz Sin波の周波数スペクトル（Raspberry Pi 3）

不明点

Rasberry Pi 3のHW PWMはレジスタに設定した値をDuty比だと思ってずっと出力し続けます。最大値（0x800、設定で変えられる）を書き込むとずっと3.3V、0を書き込むとずっと0V、半分の値を書くと3.3Vと0Vを交互に出力します。特に不思議なところはありません。

Raspberry Pi 3のオーディオ出力はPWMのDuty比を100％に固定すると、なぜオーディオ出力が減衰していくのか？が良くわからないままです。以前、ボリューム設定をミスっていたときの波形がわかりやすいです。数カ所でPWM出力がDuty比100％に張り付いていますが、なぜかオーディオ出力は上限値に張り付かず減衰します。

fs = 44kHz, 30Hz Sin波の周波数スペクトル（Raspberry Pi 3）0.4dBゲインあり

LTspiceの過渡応答シミュレーションの結果ではDuty比100％が続いたら0.9Vに張り付いており、減衰するような波形にはなりません。何かシミュレーションをミスっているんでしょうか？それともまだ隠し要素があるんでしょうか……？

編集者:すずき(2024/10/24 23:31)

コメント一覧

コメントはありません。

この記事にコメントする

2021年5月10日

permalink

編集する

Raspberry Pi 3のオーディオ番外編 - PWMと我が家のオシロの限界

目次: Raspberry Pi

Raspberry Pi 3のHW PWMは意外と変調速度が速く、最もON/OFFが頻発するDuty比50％にするとこのような波形になります。PWM信号はもっとエッジが急峻だと思われますが、我が家のオシロスコープが測れる帯域（50MHz）の限界に達しており、波形がすっかり丸くなっています。

RasPi 3のPWM信号波形（Duty比50％）

RasPi 3のPWM信号波形（Duty比25％）

もっと性能の良いオシロを買えば良いだけですけど、値段が高すぎるんですよね。200MHzを測れるオシロはエントリーモデルTBS 1202Cでも20万円！高すぎでしょ！？10万円超えはホビー向けは高すぎだと思いますし、企業や研究所向けとしてはTBS 1202Cのスペックでは足りないでしょう。誰向けでしょうね？学校かなあ？Tektronixの値付け方針がいまいち理解できません。

メーカーにこだわらなければ同じ予算でもっと良いオシロが買えることは知っています。最近だとRIGOLやOWONが人気なんですかね？テック系のYouTuberが使っているのをたまに見かけます。でも憧れのAgilentやTektronixのオシロ欲しいじゃないですか……。そんなことないですか？

編集者:すずき(2021/05/11 00:51)

コメント一覧

コメントはありません。

この記事にコメントする

2021年5月11日

permalink

編集する

Raspberry Pi 3のオーディオその5 - シミュレーションと実測値の差

目次: Raspberry Pi

Raspberry Pi 3のAudio Outの残された謎がいくつかあります。

実測だと電圧がマイナスになるのに、シミュレーションだと電圧がマイナスになりません。
実測の電圧とシミュレーションの電圧が10倍違います。
PWMのDuty比100％を維持したときに減衰する速度が異なります。

一部は解決しましたが、最後の謎が良くわからないままです。

電圧がマイナスにならない問題

端的に言えばシミュレーション時間が不足していました。シミュレーション時間を0s〜0.05sではなく1s〜1.05sにしたところ、-500mV〜500mVの間で振れるようになりました

Audio Out回路の長時間シミュレーション結果

0s〜1sのシミュレーション結果を見ると、数百msかけて負の電圧側に移行していくようですね。

電圧が10倍違う問題

オシロの設定ミスでプローブを繋ぐときの設定（感度x10）になっていて、実測の電圧が10倍に見えていただけでした。実測（400mV）とシミュレーション（500mV）のスケールは合いましたが、電圧は微妙に合っていない点が気になりますね。うーむ。

減衰する速度が違う問題

これはまだ真相がわかりません。未解決です。PWMのDuty比100％を維持したときに減衰する速度が異なります。シミュレーションでも減衰はします（500mV → 450mV程度）。

Audio Out回路のシミュレーション結果（125Hz矩形波を入力に設定）

ですが実測の方がはるかに速く減衰します（400mV → 248mV）です。なんでですの……？？

Audio Out回路の実測値（黄色Audio Out、水色PWM信号125Hz矩形波）

編集者:すずき(2021/05/11 01:28)

コメント一覧

コメントはありません。

この記事にコメントする

2021年5月12日

permalink

編集する

Raspberry Pi 3のオーディオその6 - 回路図間違ってる？疑惑

目次: Raspberry Pi

Raspberry Pi 3 model B rev 1.2のSchematicsが間違っていて、ハイパスフィルタ側のコンデンサが47uFではなく4.7uFが実装されていると仮定すると、シミュレーションと実測の辻褄が割と合うことに気づきました。4.7uFでシミュレーションするとAC特性はこのような感じになります。拡大図も載せておきます。

Audio Out回路のAC特性（コンデンサ容量4.7uF）

Audio Out回路のAC特性（4.7uF、縦軸方向に拡大）

もしRaspberry Pi 3のAudio Out回路のコンデンサ容量が4.7uFだとすると、30Hz Sin波と100Hz Sin波にゲインの差が生じるはずです。グラフを見た限り30Hzだと約1.2〜1.3dB程度カットされてしまうはずです。

Sound Blasterで30Hzと100HzのSin波を同時に鳴らした出力の周波数スペクトルを見ると、30Hzと100Hzにゲインの差はほとんどないです。

Sound Blaster X-Fi Go! Proにて30Hz, 100Hz同時再生時の周波数スペクトル

Raspberry Pi 3で30Hzと100HzのSin波を同時に鳴らすと、30Hz, 100Hz同時再生時の周波数スペクトル30Hzと100Hzにゲイン1.2dBほどの差が生じています。

RasPi 3にて30Hz, 100Hz同時再生時の周波数スペクトル

RasPi 3で30HzのSin波と100HzのSin波をそれぞれ単独で鳴らしても30Hzの方がピーク電圧が低いですし、ハイパスフィルターに引っかかってカットされてるような動きに見えます。

波形も比較

フィルタのAC特性だけでなくて、出力波形もかなり実測に近くなります。

Audio Out回路のシミュレーション結果（125Hz矩形波）

Audio Out回路のシミュレーション結果（125Hz矩形波、コンデンサ容量4.7uFに変更）

RasPi 3の実測値（黄色Audio Out、水色PWM信号125Hz矩形波）

かなり良い線行ってますよね。やっぱりコンデンサ容量4.7uFじゃないか？と思うんですけど。

どうやって調べたものか

ボードに実装されたコンデンサの容量を測れたら一発でわかるんですけど、ボードを壊してコンデンサを剥がす以外に何か良い方法はないのかなあ。うーん……？？

補足（2021年6月17日）

この推測は間違っていて、ケーブルに抵抗が入っていたことが原因でした。その8（2021年6月17日の日記参照）をご覧ください。

編集者:すずき(2021/06/19 01:24)

コメント一覧

コメントはありません。

この記事にコメントする

2021年5月13日

permalink

編集する

Raspberry Pi 3のオーディオ番外編2 - 仕様がわかりにくい

目次: Raspberry Pi

Raspberry Piは何も苦労せず動くので最高に便利ですけど、今回みたいにハードを直叩きしたいケースや、もう少し発展させてカーネルやドライバ開発用に使うことを考えると最高とは言えないですね。ちょっとボードとSoCの仕様がわかりにくいです。

ボードの仕様についてはSchematicsは公開されているものの、コネクタ近辺しか記述がなくGPIOピンと信号名の関係がわかりません。SoC（BCM283x）の仕様は歯抜け（Broadcomが一般人に見せたくない部分を削っている？）で意味不明な点がチラホラあります。

ARM系SoCの仕様公開

ちょっとイマイチ感はあるもののBroadcom並の情報公開をしてくれるのは、ありがたいことです。他のベンダーですとAllWinner, Amlogic, Rockchip辺りはセットトップボックス（STB）向けSoCの仕様を公開しています。非常にありがたいです。

仕様がオープンなだけあって、シングルボードコンピュータ（SBC）ではほぼこの3社のSoCが採用されます。あとはSamsungが採用されるくらいかな？

我らが日本ベンダーはSoCの情報をほぼ公開しません。SBCに日本のSoCが採用されることもほとんどありません。一般開発者が日本のSoCに触れる機会はあまりないです。仕様書がないのか、仕様公開するメリットを感じないのか、SBCのような小規模顧客を相手する余裕がないのか……、真相は知りませんけどちょっと残念ですね。

編集者:すずき(2021/05/13 01:34)

コメント一覧

コメントはありません。

この記事にコメントする

2021年5月14日

permalink

編集する

Raspberry Pi 3のオーディオその7 - 高い音が出ない謎

目次: Raspberry Pi

その1 - 波形観察（2021年5月2日の日記参照）でRaspberry Pi 3では高い音が出ない現象が発生していました。この原因について調べたメモです。結論だけ言えば、PWMのハード的には出せるはず、でも根本原因はわかりませんでした。

PWMの素性を調べる

RasPi 3のHW PWMは出力Duty比を約20usごとにしか変更できないようです。確認方法は下記のようにしました。

FIFOを有効にする: CTL（アドレス3f20c000）のUSEFx（ビット5と13）をセット
DMAを無効にする: DMAC（アドレス3f20c008）のENAB（ビット31）をクリア
FIFO空きをチェックする: STA（アドレス3f20c004）のFULL1（ビット0）がクリアされるまで待つ
FIF1（アドレス3f20c018）に左右両チャネルのデータを書く、つまり2回Writeする
FIFO空きチェックに戻る

これにより最速でPWM Duty比を変更することができます。下記は設定例です。

PWMのレジスタダンプ

3f20c000  00002121 00000032  00000303 70776d30
3f20c010  00000800 00000000  70776d30 70776d30
3f20c020  00000800 00000800  70776d30 70776d30

Duty比は何でも良いですけど、0％100％が一番波形が見やすいと思います。この設定例で言えば0x000, 0x000と0x800, 0x800を交互に書きます。

最高速度でPWMのDuty比を切り替えたときの波形（黄色1chオーディオ出力、水色2ch PWM出力）

上記操作をしたときのPWMの波形を見ると約20usに一度しか波形が変わっていません。従ってRasPi 3のオーディオ出力は25kHz程度が上限です。

クロックとの関係

なぜ20usに一度しか変更できないか気になりますが、BCM2835の仕様書には一切記載がありません。試行錯誤してみた結果、clk_pwm_domainのクロック周波数を早くすると変更間隔も速くなるみたいです。

PWMのクロック設定はPWMCTL（アドレス3f1010a0）とPWMDIV（3f1010a4）にあるようです。これも仕様書には載っていませんので、Linuxのクロックドライバdrivers/clk/bcm/clk-bcm2835.cから読み取るしかありません。イマイチな仕様書ですね……。

クロック制御部のレジスタダンプ

3f1010a0  00000096 00005000  00000200 00000000
3f1010b0  00000000 00000000  0000636d 0000636d

クロックドライバの実装をみるに、CTLレジスタのビット0〜3がクロック源です。6なのでクロック源にPLLD_COREが選択されているようです。ビット9が分周するかどうかの設定です。上記の設定だと有効でも無効でもクロックの速度が変わりませんでした。デフォルトが5分周なのか？どこかでデフォルトの分周比を設定しているのか？どちらなのかは良くわかりません。

DIVレジスタは分周比を表すようです。仕様がイマイチわかりませんが固定小数点のようで、上位ビットが整数部分、下位12ビットが小数点以下を表しているようです。上記の設定だと5分周を意味しているはず。

最高速度でPWMのDuty比を切り替えたときの波形（黄色1chオーディオ出力、水色2ch PWM出力）分周比設定0x4000

分周比を0x4000に変更するとDuty比の変更速度も5/4倍になって、16us間隔になるので、上位ビットが整数部分であることはほぼ間違いなさそうです。ちなみにクロック制御部のレジスタを変更する際は、上位16ビットに0x5a00をORしてwrite しないといけません。

クロック源の周波数をdebugfsから確認すると500MHzみたいです。5分周だから100MHz駆動でしょうか？

クロック源の周波数

# cat /sys/kernel/debug/clk/plld_core/clk_rate
500000006

チャネル数は2ch、FIFO幅は32bitですから、100MHz / 2 / 32 = 1.5625MHzつまり0.64us間隔ならまだわかるんですが、どうしてその30倍もある20us間隔になるんでしょう。さっぱりです。

残った謎

PWMの能力的にはギリギリ24kHzも再生できるはずですが、以前示したように通常のオーディオ出力経路（CPU → GPU → DMA → PWMの経路と思われる）を使うと、24kHzが再生できません。24kHzどころかfs = 32kHzでの16kHzでさえ再生不可能です。

PWM以外に、例えばGPU側で何かPCMデータを弄っているなど、高音を再生する際の制約があるのかもしれません。

編集者:すずき(2024/08/10 13:02)

コメント一覧

コメントはありません。

この記事にコメントする

2021年5月15日

permalink

編集する

Google先生と擬人化画像

艦これが流行ったあとくらいでしたか、Googleで「赤城」を検索すると空母やプラモデルの写真ではなく、艦これの絵がたくさん出てきて空母が出てこなくなりました。

ところが最近（？）Google検索結果の傾向が変わったとTwitterで見たので、試してみました。少なくとも「赤城」は空母が出てくるようになっています。

検索結果が擬人化キャラで埋め尽くされようと、世の中のトレンドの一部ですし間違いとはいえません。Googleはそんなこと気にしないのかと思っていましたが、あえて変えたってことは、内心ダメだこりゃって思ってたんですかね……？

その他の空母

赤城だけ特別扱いか？全部擬人化を排除したか？どちらか気になったので、試しに歴代空母をGoogle画像検索で探して、擬人化率を調べました。結構違っていて面白いです。

瑞鶴: 86％（19/22）
鳳翔: 92％（23/25）
赤城: 5.9％（1/17）
加賀: 67％（14/21）
龍驤: 88％（21/24）
蒼龍: 86％（19/22）
飛龍: 22％（4/18）
翔鶴: 91％（21/23）

以下はカウントに使った検索結果のキャプチャ画像です。

赤城だけ特異的に擬人化の絵の結果が少ないです。何か限られた対象だけ特殊処理が働いているとかですかね？

2021年5月16日

permalink

編集する

OpenCLのOSS実装poclを調べるその1 - 動かしてみよう

目次: OpenCL

最近OpenCLのオープンソース実装poclについて調べています。わかったことのメモです。

OpenCLはclGetDeviceIDs() を呼ぶときにデバイスの種類を指定します。KhronosのAPIドキュメント（clGetDeviceIDs(3) Manual Page）を見ると、デバイスの種類は4つ定義されています（DEFAULTとALLはデバイスの種類ではないので除外）。

CL_DEVICE_TYPE_CPU: OpenCLデバイスはホストCPUです。ホストCPUはシングルもしくはマルチコアCPUでOpenCLプログラムを実行します。OpenCLでマルチコアCPUの並列プログラムを書く人は居るのかな。あまり聞いたことがないですね……。
CL_DEVICE_TYPE_GPU: OpenCLデバイスはGPUです。GPUはOpenCLプログラムだけではなくて、OpenGLやDirectXのような3DグラフィクスAPIも高速に実行できます。GeForceやRadeonはこちらですね。
CL_DEVICE_TYPE_ACCELERATOR: OpenCLデバイスはアクセラレータ（例えばIBM CELL Blade）です。これらのデバイスはホストCPUとペリフェラル接続（PCI Expressなど）を使用して通信します。
CL_DEVICE_TYPE_CUSTOM: OpenCLデバイスはアクセラレータですが、OpenCL言語でカーネルを書くことができないタイプです。FPGAなんかが該当するんですかね？

これらのうちpoclがサポートしているのはCPUとGPUです。GPUはNVIDIAのCUDAとAMDのHSAに対応しているようです。全部LLVMがビルドしてくれるわけで、すごいよLLVMさん。ACCELERATORはテンプレート実装のみで、そのままでは動作しないので、注意が必要です。

ビルド、インストール

CPU（pthread版）、GPU（CUDA版）、ACCELERATORを有効にしたpoclのビルド、インストール方法は下記のとおりです。実際に動かすときはACCELERATORを無効にしてください。でないと初期化時にエラーが発生して動かないです。

poclのビルドとインストール

$ cmake -G Ninja \
  -DCMAKE_INSTALL_PREFIX=`pwd`/_install \
  -DENABLE_CUDA=ON \
  -DENABLE_ACCEL_DEVICE=ON \
  ../

$ ninja
$ ninja install

基本的には必要なオプションがあればONにするだけですから、ビルドとインストールはそんなに難しくないはずです。

実行

実行方法はややクセがあります。OpenCLは実装がたくさんあるので、直接OpenCLライブラリをリンクするのではなく、ICD Loaderと呼ばれるライブラリ（2020年7月14日の日記参照）を間に噛ませることが多いです。

ソースコードは Oak Ridge大学のサイトとほぼ同じです。行数を減らしたのと、OpenCL 2.2に合わせて使うAPIを一部変えている程度です。

OpenCLのテスト用ソースコード


#define CL_TARGET_OPENCL_VERSION 220

#include <stdio.h>
#include <stdlib.h>
#include <math.h>
#include <CL/opencl.h>
 
// OpenCL kernel. Each work item takes care of one element of c
const char *kernelSource =                                        "" \
"#pragma OPENCL EXTENSION cl_khr_fp64 : enable                    \n" \
"__kernel void vecAdd(__global double *a,                         \n" \
"                     __global double *b,                         \n" \
"                     __global double *c,                         \n" \
"                     const unsigned int n)                      \n" \
"{                                                               \n" \
"    // Get our global thread ID                                 \n" \
"    int id = get_global_id(0);                                  \n" \
"                                                                \n" \
"    // Make sure we do not go out of bounds                     \n" \
"    if (id < n)                                                 \n" \
"        c[id] = a[id] + b[id];                                  \n" \
"}                                                               \n" \
                                                                "\n" ;
 
int main(int argc, char *argv[])
{
    // Length of vectors
    int n = 100000;
    size_t bytes = n * sizeof(double);

    cl_platform_id cpPlatform;
    cl_device_id device_id;
    cl_context context;
    cl_command_queue queue;
    cl_program program;
    cl_kernel kernel;

    // Device input/output buffers
    cl_mem d_a, d_b;
    cl_mem d_c;

    // Allocate memory for each vector on host
    double *h_a = (double *)malloc(bytes);
    double *h_b = (double *)malloc(bytes);
    double *h_c = (double *)malloc(bytes);
 
    // Initialize vectors on host
    for (int i = 0; i < n; i++) {
        h_a[i] = sinf(i) * sinf(i);
        h_b[i] = cosf(i) * cosf(i);
    }

    // Number of work items in each local work group
    size_t localSize = 64;

    // Number of total work items - localSize must be devisor
    size_t globalSize = ceil(n / (float)localSize) * localSize;

    cl_int err;

    // Bind to platform
    err = clGetPlatformIDs(1, &cpPlatform, NULL);
    if (err != CL_SUCCESS) {
        printf("%s:%d err:%d\n", __func__, __LINE__, err);
        return 0;
    }

    // Get ID for the device
    err = clGetDeviceIDs(cpPlatform, CL_DEVICE_TYPE_CPU, 1, &device_id, NULL);
    if (err != CL_SUCCESS) {
        printf("%s:%d err:%d\n", __func__, __LINE__, err);
        return 0;
    }

    // Create a context 
    context = clCreateContext(0, 1, &device_id, NULL, NULL, &err);
    if (err != CL_SUCCESS) {
        printf("%s:%d err:%d\n", __func__, __LINE__, err);
        return 0;
    }

    queue = clCreateCommandQueueWithProperties(context, device_id, 0, &err);
    if (err != CL_SUCCESS) {
        printf("%s:%d err:%d\n", __func__, __LINE__, err);
        return 0;
    }

    // Create the compute program from the source buffer
    program = clCreateProgramWithSource(context, 1,
                                        (const char **)&kernelSource, NULL, &err);
    if (err != CL_SUCCESS) {
        printf("%s:%d err:%d\n", __func__, __LINE__, err);
        return 0;
    }

    // Build the program executable
    err = clBuildProgram(program, 0, NULL, NULL, NULL, NULL);
    if (err != CL_SUCCESS) {
        printf("%s:%d err:%d\n", __func__, __LINE__, err);
        return 0;
    }

    // Create the compute kernel in the program we wish to run
    kernel = clCreateKernel(program, "vecAdd", &err);
    if (err != CL_SUCCESS) {
        printf("%s:%d err:%d\n", __func__, __LINE__, err);
        return 0;
    }

    // Create the input and output arrays in device memory for our calculation
    d_a = clCreateBuffer(context, CL_MEM_READ_ONLY, bytes, NULL, NULL);
    d_b = clCreateBuffer(context, CL_MEM_READ_ONLY, bytes, NULL, NULL);
    d_c = clCreateBuffer(context, CL_MEM_WRITE_ONLY, bytes, NULL, NULL);

    // Write our data set into the input array in device memory
    err = clEnqueueWriteBuffer(queue, d_a, CL_TRUE, 0,
                               bytes, h_a, 0, NULL, NULL);
    if (err != CL_SUCCESS) {
        printf("%s:%d err:%d\n", __func__, __LINE__, err);
        return 0;
    }
    err = clEnqueueWriteBuffer(queue, d_b, CL_TRUE, 0,
                               bytes, h_b, 0, NULL, NULL);
    if (err != CL_SUCCESS) {
        printf("%s:%d err:%d\n", __func__, __LINE__, err);
        return 0;
    }

    // Set the arguments to our compute kernel
    err = clSetKernelArg(kernel, 0, sizeof(cl_mem), &d_a);
    if (err != CL_SUCCESS) {
        printf("%s:%d err:%d\n", __func__, __LINE__, err);
        return 0;
    }
    err = clSetKernelArg(kernel, 1, sizeof(cl_mem), &d_b);
    if (err != CL_SUCCESS) {
        printf("%s:%d err:%d\n", __func__, __LINE__, err);
        return 0;
    }
    err = clSetKernelArg(kernel, 2, sizeof(cl_mem), &d_c);
    if (err != CL_SUCCESS) {
        printf("%s:%d err:%d\n", __func__, __LINE__, err);
        return 0;
    }
    err = clSetKernelArg(kernel, 3, sizeof(unsigned int), &n);
    if (err != CL_SUCCESS) {
        printf("%s:%d err:%d\n", __func__, __LINE__, err);
        return 0;
    }

    // Execute the kernel over the entire range of the data set 
    err = clEnqueueNDRangeKernel(queue, kernel, 1, NULL,
                                 &globalSize, &localSize, 0, NULL, NULL);
    if (err != CL_SUCCESS) {
        printf("%s:%d err:%d\n", __func__, __LINE__, err);
        return 0;
    }

    // Wait for the command queue to get serviced before reading back results
    clFinish(queue);

    // Read the results from the device
    clEnqueueReadBuffer(queue, d_c, CL_TRUE, 0,
                        bytes, h_c, 0, NULL, NULL);

    //Sum up vector c and print result divided by n, this should equal 1 within error
    double sum = 0;
    for (int i = 0; i < n; i++) {
        sum += h_c[i];
    }
    printf("final result: %f\n", sum / n);

    clReleaseMemObject(d_a);
    clReleaseMemObject(d_b);
    clReleaseMemObject(d_c);
    clReleaseProgram(program);
    clReleaseKernel(kernel);
    clReleaseCommandQueue(queue);
    clReleaseContext(context);

    free(h_a);
    free(h_b);
    free(h_c);

    return 0;
}

poclの実行

$ gcc a.c -g -O0 -Wall -lOpenCL -lm

★ICD Loaderにpoclのライブラリ名を教える必要がある

$ cat /etc/OpenCL/vendors/pocl_test.icd
libpocl.so.2.7.0

$ LD_LIBRARY_PATH=/path/to/pocl/build/_install/lib \
  ./a.out

final result: 1.000000

動作しました。良かった。

OpenCLのAPIはICD Loaderが提供し、OpenCLの実装は各ICDが提供します。呼び出し関係はApp → ICD Loader → ICDです（詳しくは 2020年7月14日の日記参照）。一見すると煩雑ですが、アプリケーションはICDのことは知らなくても良いのが利点です。今回の例でいえばアプリケーションはlibpocl.soをリンクせずとも、poclの実装を使うことができます。

デバッグ

これだけだと面白くないし、何が動いているかすらわからないので、デバッグ出力を全開にして観察します。POCL_DEBUG環境変数を使います。その他のデバッグ方法はPoCLのドキュメント（Debugging OpenCL applications with PoCL）が参考になります。

poclのデバッグ出力（CUDA版）

$ LD_LIBRARY_PATH=/path/to/pocl/build/_install/lib \
  POCL_DEBUG=all \
  ./a.out

** Final POCL_DEBUG flags: FFFFFFFFFFFFFFFF
[2021-03-13 07:05:14.074169726]POCL: in fn pocl_init_devices at line 571:
  |   GENERAL |  Installing SIGFPE handler...
[2021-03-13 07:05:14.128006157]POCL: in fn pocl_cuda_init at line 287:
  |   GENERAL |  [CUDA] GPU architecture = sm_61
[2021-03-13 07:05:14.128050269]POCL: in fn findLibDevice at line 560:
  |      CUDA | looking for libdevice at '/usr/lib/nvvm/libdevice/libdevice.10.bc'
...

動作しました。よきかな。タイムスタンプの日付がかなりズレますね……？ま、実害はないし良いか。

編集者:すずき(2024/08/10 13:01)

コメント一覧

コメントはありません。

この記事にコメントする

2021年5月22日

permalink

編集する

ベンチマーク - まとめリンク

目次: ベンチマーク

一覧が欲しくなったので作りました。

メモリクリアでおなじみmemset()関数の自作。

Nクイーン問題の自作。

編集者:すずき(2025/02/12 00:33)

コメント一覧

コメントはありません。

この記事にコメントする

2021年5月23日

permalink

編集する

TRONが世界標準？？

Quoraのとある項目なぜTRON OSが「非常に優れていたが外圧で潰された」とか「組み込みで世界標準OSだ」とかいう誇張された伝説をいまだに信じている人が大勢いるのですか？ - Quora が話題になっていました。そんな話を信じている人が居るんですね。TRONが世界標準……私の知らない世界線でTRONが覇権を獲ったのでしょうか……。

松下電器（おそらく日本一のTRON推しの会社でした）に居た自分すら、そんなこと思ったことありませんでした。

その松下電器でさえBTRONはもちろんiTRONすらギブアップです。いまやレコーダーやテレビのOSはLinux/BSDカーネルを採用しています。iTRONアプリも残ってはいますが、過去資産の作り直しは面倒＆旨味がないのが理由だったと思います。

メモ: 技術系の話はFacebookから転記しておくことにした。

編集者:すずき(2022/04/05 12:00)

コメント一覧

コメントはありません。

この記事にコメントする

2021年5月28日

permalink

編集する

RISC-V 64 CPU第2号が我が家に来た

目次: RISC-V

SiFiveのHiFive Unmatchedを購入しました。現状、世界最速のLinuxが動作するRISC-V 64bit SoC とのことです。

ボードにはSDカードが付属しておりSiFive独自環境のFreedom USDKがインストールされています。ボード上にはUSB接続のシリアル端子があり、電源を入れればLinuxが起動し、ユーザroot、パスワードsifiveでログインできるようになっています。

ぱっと見はPCと同じmini-ITXマザーボードですけど、バックパネルを見るとSDカードの差し込み口、USBシリアル用のmicroB端子が出ていて、どちらかといえばSBC（シングルボードコンピュータ）です。PCっぽさがありません。

HiFive Unmatchedのバックパネル

本当はグラフィックカードを装着してGUIを使うべきですが、昨今のグラフィックカード品薄＆異常な値上がりのおかげで全く買う気が起きないので、しばらくシリアルコンソールで使おうと思います。

インストールされているカーネルは、
Linux unmatched 5.11.10 #1 SMP Wed Apr 7 17:37:34 UTC 2021 riscv64 riscv64 riscv64 GNU/Linux
でした。5.11はStableカーネルではあるものの、既にEOLです。まあ、開発用ボードだしこんなもんか。

購入時の同じ罠

Crowd Supplyから購入しました。本体 $679, 消費税が7,100円、合計で7万円くらいでした。HiFive Unleashedほどではないにせよ、SBCにしては良いお値段です。

UPSが米国→日本まで持ってきて、国内はクロネコヤマトが運びます。受け取りの際に、消費税を着払いでクロネコに払う必要があります。私は消費税のことを忘れていて、何だこの金は？？と混乱しました。Unleashedのときと全く同じでした。海外からものを買うことがほとんどなくて、消費税の存在をすぐ忘れちゃうんですよね……。

編集者:すずき(2024/08/10 13:00)

コメント一覧

コメントはありません。

この記事にコメントする

2021年5月29日

permalink

編集する

memsetのベンチマーク（RISC-V 64, U74-MC編）

目次: ベンチマーク

（参考）コード一式はGitHubに置きました（GitHubへのリンク）

Linuxが動くRISC-Vボードを買ったので、RISC-V 64でもmemsetをやってみました。環境はボードがSiFive HiFive Unmatchedで、SoCがSiFive Freedom U740で、コアがU74-MCです。動作周波数は書いてないですね。OSはSiFive独自？環境のFreedom USDKです。メモリはDDR4-2400のようです（Schematics hifive-unmatched-schematics-v3.pdfより）。

特徴的な点は、