落胆がらくた街

Dr.Rootはサポート終了製品です。

Vscode+PlatformIOでIntelliSenseが変なもん参照する時の覚書

前置き

f:id:suzumodoki:20171125212155j:plain
画像はVS codeにPlatform IOという拡張をぶち込んで
Mbed lpc1114fn28向けのプロジェクトを立ち上げた時の一コマ。
一見1114向けのヘッダが見事に読み込めているように見えるし、ビルドもちゃんと通るのでとっても快適。

f:id:suzumodoki:20171125221448j:plain
ところが、実はこんな明らかにヘッダファイルを読めているにも関わらず、IntelliSenseが1114のピンネームマクロ「dp14」を候補に出してくれない。
コンパイル・ビルドが通る以上ビルドツール向けのパスの設定はちゃんと出来ているので、問題はプロジェクトフォルダのc_cpp_properties.jsonという事になる*1
で、c_cpp_properties.jsonがどうなってるかというと…

イヤーッ!
f:id:suzumodoki:20171125212815j:plain
グワーッ!

これは「configurations」属性の直下の「includepath」属性なので、コンパイラに渡すインクルードパスと同じだ。
ここの設定は正しいのだが、何故かIntelliSenseはこのインクルードパスを参照してくれず、果には「mbed.hなんて無いよ」とか言い出す。
で、下の方を見てくと、「browse」というタグがあり、やはりその下にはpath属性があって似たような記述がずらっと並ぶ。
browse属性は何をしているかというと「fazzyモード(厳格ではない、多少のエラーは気にせずコード解析するモード)」で候補を出すときのインクルードパスだ。
最初にVs codeでプロジェクトを起こした時、インクルードパスを何も設定してないせいで#includeプリプロセッサに緑の線が引かれるが、あれは「参照が解決できないのでファジーモードで候補出すよ」という記号だ。だから緑の線が無くなるまできっちりインクルードパスを書いてやったのだが何故か逆に何も読んでくれなくなった(原因不明。誰か教えてください)。

コンパイラに渡すインクルードパスと違い、「browseのpath属性」にIntelliSenseが検索をかける時はサブフォルダまで舐め回すように探すので、
このずらーっと並んだ書き方は恐らく無駄でしか無い。
例えば1114が参照するのは「targets/TARGET_NXP/TARGET_LPC11XX_11CXX」以下なんかにあるファイルだが、
ドタマに「C:/Users/admin/.platformio/packages/framework-mbed/.」が書かれている以上、その下にある全く関係無い他のデバイス用の同名のヘッダも全部読む。
そして名前の衝突が起こった場合、本来ならばIntelliSenseは複数の候補があると言ってくるのだが、「複数の候補が存在するa.hからやはり複数の候補が存在するb.hをインクルード」というシチュエーションの時、どうやらb.hで名前がぶつかっている候補をIntelliSenseは見つけてくれない。

f:id:suzumodoki:20171125214129j:plain
PlatformIOはMbedプラットフォームを選択した時点で対応しているライブラリを全てダウンロードして手元に置く。
その為、たとえ存在を知らないような、BEETLEとかいうわけのわからんボードのAPIも手元にある。これは2017/11/25時点でMbedプロジェクトフォルダのアタマに置かれている(framework-mbed\targets\TARGET_ARM_SSG以下。)
で、ビルドツールは設定されたマクロに従い、図の右下の1114用ライブラリをきっちり読み込んでくれるのだが、ファジーモードのIntelliSenseはそんなマクロ知ったこっちゃないので、まずDevice.hで競合する(図中とりあえず①)。この時はまだ「競合してるよ」的なウィンドウを出してくれるのだが、ここから更に読み込んでいるヘッダに関しては「競合が解決されない以上は仮に一番上のヘッダを読んでおく」事になっているらしい。つまり、「TARGET_ARM_SSG\TARGET_BEETLE\PinName.h」をPinName.hの代表として読むわけだ(図中とりあえず②。図ではobjects.hが一例)。
かくして1114の為のPinName.hは読み飛ばされ、候補にdp14というマクロは出なくなる。纏めると、
「厳密な解析モードだと何故か何も表示してくれない。ファジーモードだと何もかも読み込み衝突を起こす」。


解決策

ようはbrowseタグのpath属性でサブフォルダを読まないようにすればいい。
vscode-cpptools/c_cpp_properties.json.md at master · Microsoft/vscode-cpptools · GitHub
リファレンス曰く、「パスの末尾が/*か\*ならそれ以降読まない」との事。なので、このずらっと並んだ部分を選択して、置換コマンドで
「",」を「/*",」に置換してやる。これだけ長ったらしく前置きをした挙句やることがこれだけって…。
f:id:suzumodoki:20171125223000j:plain

なお、今回はMbedの話だが、多分どのプラットフォームを選んでも似たり寄ったりじゃないかと思うので、状況は違えど現象が同じなら同じやり方でなんとかなると思います。
いやわかんないけど。めっちゃ対症療法だし。

*1:インクルードパスなどを設定する、プロジェクトフォルダ毎の設定ファイル

例大祭14戦利品

今回買った中で特に良かったもの。自分向け。太字は今年初めて買ったサークル。
敬称略。


・べにしゃけ/poprication 初恋に捧ぐ
レイマリ。いつも通り文句なしの傑作。もう殿堂入りみたいなもんだし割愛。

いな/Inadahime 床伏の君。
レイマリ。文章力がないので上手く書けないがとても良かった。次回レミフラ描くらしいのでそっちにも期待。

・よぬりめ 雨音が結ぶ
レイマリ。ここも殿堂入りみたいなもんだし割愛。ところでよぬりめさん体調の方はもう大丈夫なんだろうか。

電派絵師団/しろし 科学世紀小噺
SF色強め。個人的にはかなりアタリ。秘封。

あみだ屑 秘封倶楽部モノ
漫画を描く技術が頭一つ飛び抜けてる。構成や描き込みの技術が魅せる。

・romi/あじさい通り 蓮子が落ち着かない話。
前から好きなサークルなので割愛でもいいんだけど今回はいつもより甘めかもしれん。蓮メリ。
秘封ってシリアスな話多いんだけどここのはダダ甘でいいね。

にくにくみっく ふきのとうは甘く
サニーとスターのR18。作者は間違いなく筋金入りのロリコンだと思う。幼児体型へのこだわりが尋常ではない。

・杏飴/こいんとす おかしが食べたいっ
まぁここも毎年買ってるし有名だし殿堂入りっすね。割愛。


全体として豊作だったけど古明地姉妹がちと不作だった。ここ数年言ってるけどサークルスペースが変わらないままキャラやジャンルが増えたので好きジャンルの本の絶対数が下がっている。そろそろ新ジャンルを開拓しないと…

LPC11u35 DIP化基板を試す

ついき
LPC11U35 DIP化基板で遊ぶ | 落胆がらくた工務店
新ブログの方でわかりやすく書き直した。なんで今さら書き直したかって?プルアップ抵抗の記述がすっぽ抜けてて自分で1日悩んだからだよ。ファック!

0.2017年秋も終わり頃の追記
LPC11U35マイコンボードキット (LPC11U35 QuickStart Board互換): マイコン関連 秋月電子通商-電子部品・ネット通販
今気づいたんだけど今年の6月(つまりこの記事の本文を書いたひと月後くらい)にこんなんが出てた。
マイコン、回路、周辺回路、その他諸々でお値段850円也。
これを買えば手間暇回路をあれこれする必要は全く無い

つまりこの記事の存在価値もまったくない。

一応残しますが、資料として真新しい要素は無いし、お安くMbedでUSBdeviceが叩きてぇようって人は黙ってこれ買えば良いと思います。
あ、それと、一応850円基盤の方は11U35の足が一部オミットされてるので、「11U35の足を全部くまなく使う予定があるんじゃ」という人にはいいかも。いるのか?

結論。もう一月早く出してくれ。

          • 追記ここまで------

秋月でこんなのが売ってた。
LPC11U35 DIP化モジュール: マイコン関連 秋月電子通商-電子部品・ネット通販
LPC11u35を単体で試せるとのこと。お値段500円也。
11u35はUSBを搭載したマイコンで、プログラムの書き込みもMbedでお馴染みのマスストレージとして認識されるアレが出来る。
ただしその為にはちょっと回路を組まなきゃならないよ、ということで参考になったサイトなんかを纏めておく。
(ようはトラ技ARMライタを自前でやっちゃおうという話)

1.いるもの
マイコン単体だけではどうにもならんので必要な資材を挙げる。
・12Mhzクリスタル
・クリスタル用コンデンサ20pf 2個
・USBコネクタ
・3.3V出力のレギュレータ
・レギュレータ用コンデンサ
ISPモード用のスイッチ(必須ではない)
といった具合。最初1114みたいに内部の発振器が使えると思い込んでて延々悩んでたけど外部にクリスタルが要る模様。

2.回路
実は同じようなことを自前で既にやってらっしゃる方がいる。
mbedクラウド対応CPUボード
ここにある「回路図」がまんまやりたいことなので、参考にさせていただく。
ただし、USBDeviceとしてのみ使う場合は外部電源の存在を気にしなくて良いので、PIO0_6 USB_CONNECTあたりの端子は不要になる。
秋月の商品画像とマイコンのデータシートを加工して(勝手にやった。万が一怒られたら消す)ピンアサインっぽいのを作った。
f:id:suzumodoki:20160917204419j:plain
これを見ながら組んでいく。
注意点としては、
・左右にVDDが一つずつあるが、別に内部で繋がってたりはしない。どちらも3.3Vに繋ぐ必要がある。
・データ線に直列で入ってる33Ω抵抗とかは無くても動く。勿論一応あった方が良いに越したことはない。
・VBUSには文字通りUSBからの5Vをブチ込んでやる。抵抗は入れても入れなくても良い。
・何か知らんけどリセットが効いてるんだか効いてないんだか。USBを指し直さないとリセットが効かない?


f:id:suzumodoki:20160917204224j:plain
組み上げたところ。ブレボでやったら結構ごちゃっとしたからもしかしたら基板組み上げちゃった方がいいかもしれない。
USBを繋いで、マスストレージデバイスCRP Disabled」が表示されたら成功だ。本来ISPピンをLOWにしながらリセットした場合だけこのモードに入れるが、初期出荷時はデフォルトでここに入るらしい。
11u35については以下のページが詳しい。
家庭用コンピュータ環境の模索:(トラ技ARMライタ基板:2014年2月)TG-LPC11U35-501 活用


3.あそびかた
恐らくMbedを使ったUSBDevice対応マイコンとしては現時点で最安の選択肢になる(次点でNucleoか?性能はダントツだがサイズがね…)。
USBDevice - USB device stack | Mbed
こいつを一発コンパイラにブチ込んで、試しにUSBSerialを書き込んでやろう。書き込んでからリセットをかければ、Mbed virtual serial portがインストールされ…ない。
どうもドライバが要るらしい。
直リン:https://developer.mbed.org/media/uploads/samux/serial.zip
デバイスドライバの不明なCDCドライバを更新する→上記infを読みこませるとやればドライバが入…らない。セキュリティ証明書が無いらしい。ファック!
セキュリティ証明を無効にして再度ドライバをインストールしてようやく成功。TeraTermからデバイスが見え、500円マイコンからPrintfが出来た。


ちょろっと電子部品がいるので、500円で済むとは言えないのだが、それでもあれこれあわせて7,800円で組み上がる。
それでもNucleoの半額くらいなので、USBDeviceを作りたい人にはいい選択肢なんじゃなかろうか。特に私のような貧乏人には良い商品だと思った。ありがたや秋月。

Nucleoでタッチセンサを自作した

タッチセンサの仕組みは
建築発明工作ゼミ2008: Arduino タッチセンサ
を参照。これをMbed環境でやりたい…という話。その際に出た問題を覚書。

1.青bedでやったらダメだった
このタッチセンサはMbedで言うDigitalInを使う。出力ピンと入力ピンを2MΩくらいの抵抗で繋ぎ、出力をHighにしてから入力がHighになるまでの時間を計測するわけだ。
ところが青bed及びLPC1114はDigitalInの入力閾値電圧が微妙に高く(Analogでいう0.75くらいだったと記憶しているから2.5Vくらい?)これだけ大きい抵抗を通すといつまで経ってもDigitalInはHighにならない。一応AnalogInを使えば解決するのだが、同時に6ピンしかタッチセンサに出来ないのは余りに寂しい。
そこでNucleo F401REを使ったところ一発で上手くいった。同じARMのCPUだろうにここらへんの仕様が違うんやなぁ。

2.値がめっちゃふらつく
こんな感じの回路で
f:id:suzumodoki:20160907182247j:plain

こんな感じのソースを実行すると

#include "mbed.h"

#define NUM 3

DigitalIn in[]= {D14,D15,D12};
DigitalOut dout(D7);


int ret_us(int pin)
{
    Timer t;
    dout=0;
    while(in[pin]==1);
    t.reset();
    wait_us(10);
    t.start();
    dout=1;
    while(in[pin]==0);
    return t.read_us();
}

int main()
{

    while(1){
        printf("%d,%d,%d\r\n",ret_us(0),ret_us(1),ret_us(2));
        wait(0.2);
    }
}

こんな感じの結果が得られる。

10,10,10
10,10,10
9,10,10
10,11,11
11,11,9
10,11,9
10,10,9
9,10,11
10,11,8
9,177,10
18,2,12
19,2,11
9,149,12
12,2,15
18,2,12
12,29,12
13,2,14
16,2,13
18,2,8


赤字の部分が真ん中のピンを触った時の挙動だ。これを見ると、
1.タッチされた時、応答速度は早くなるか、極端に遅くなる
2.自分以外の誰かがタッチされていても応答は若干ふらつく。具体的には若干遅くなる。

という事がわかる。触られた時に応答速度が遅くなるという予想に反した結果だが、何度やってもこうなる。
ちなみに2つ以上を同時にタッチしてもこの法則に基づくようだ。

この2つのルールをうまい具合に判定しないといけない。

最終的なソースコードは以下。

#include "mbed.h"

#define NUM 3

DigitalIn in[]= {D14,D15,D12};
int num[NUM]= {0};
DigitalOut dout(D7);
DigitalOut led(LED1);

int ret_us(int pin)
{
    Timer t;
    dout=0;
    while(in[pin]==1);
    t.reset();
    wait_us(10);
    t.start();
    dout=1;
    while(in[pin]==0);
    return t.read_us();
}

int main()
{
    led=1;

    //初回でレンジ出す
    int range[NUM],buf;
    for(int i=0; i<NUM; i++) {
        range[i]=ret_us(i);
        for(int j=0; j<50; j++) {
            buf=ret_us(i);
            if(range[i]>buf) range[i]=buf;
        }
    }
    
    int fil[NUM]= {0};
    int cnt=0;
    const int loop=10;
    const int border=5;
    while(1) {
        memset(fil,0,sizeof(int)*NUM);
        for(int k=0; k<loop; k++) {
            for(int i=0; i<NUM; i++) {
                cnt=0;
                for(int j=0; j<5; j++) {
                    if(range[i]>ret_us(i)) {
                        cnt++;
                    }
                }
                if(cnt>=2)fil[i]++;
            }
        }
        for(int i=0; i<NUM; i++){
            if(fil[i]>border)printf("1:");
            else printf("0:");
        }
        printf("\r");
    }
}

ようは複数回判定する事で、時間解像度を犠牲に判定の精度を上げるわけだ。
この方法でも「中途半端に触ってる時」なんかは判定がふらつくが、その場合用途に応じて判定回数を増やしたりすればいい。
ちなみにこれ、出力ピンが共通だからこんな事になってしまっているが、ケチらず出力ピンと入力ピンを一対一で用意してやればもう少し判定は楽になる。
…が、それでも「複数回判定して例えば分散を見る」みたいにした方がいいのは変わらない。


RH6010?久々に棚から出したら死んでたよ。

パナ改とやらを作った

~~~~~~
2017年年末の追記
この記事はクソいい加減なクソ記事です。
もう少しマシな内容はこっちに
もうちょっと真面目にパナ改を作った - 落胆がらくた街


~~~~~~

ファンタム式パナ改マイクロホン|ShinさんのPA工作室
これを組み上げただけ。
f:id:suzumodoki:20160724060203j:plain


…なのだが、回路図の単純さに対してやたら手間がかかったので、注意点をあれこれ書いておく。
尚、ハウジングは見ての通りまだだし、そもそも余り物で安く作るのが目的だったので
コンデンサはセラコンを容赦なく使う
・ケーブルのコネクタの中に入れるのはやらない。ケースはフリスクケースを使う。
・一部の抵抗の数値変更
なんかをやっている。音質はそれでも十分すぎるくらいだった。音声は追って上げる。


【注意そのいち】
f:id:suzumodoki:20160724060708j:plain
マイクは必ず表面実装の方を買うこと。リード線タイプのはベタグラウンドでどうしようもない。
マイクのハンダ付けはそこまで難しくない。
赤線の部分をカッターでパターンカットし、線をくっつけてあげる。
マイクの外側部分が本当に繋ぎたい部分なんだが、素材的に絶対ハンダが乗らないので、あくまで面実装のランド部分にくっつけるわけだ。
言われてる程簡単には外れないが、エポキシで固定したほうが良いのは間違いない。
ただ、詳しくはわからないんだが瞬間接着剤をエポキシ代わりに使ったらマイクがぶっ壊れて使い物にならなくなった。
何でだか不明。中で外れたのかな?
そんなわけなので、エポキシで固定するんなら全ての配線が終わって動作確認が出来てからで良いと思う。

【注意そのに】
回路図の1.5KΩと2.2KΩは1KΩで十分だった。入手性としてもこちらを推奨する。
コンデンサは、拘るんならWIMAのよさそうコンデンサを使うらしい。自分はそんなのどうでもいいのでセラコンを使った。安いは正義。
それからFETの向きに注意。最後まで残った回路図のミスがこれだった。分かってても間違える(池沼)
実はあれこれ失敗に失敗を重ね、マイク石を5つもゴミにしてしまった。なので、回路は回路で作っておき、最後にマイクを繋いで動くか確認したらハンダ付け、がいいだろう。マイク石は、壊れやすい(ハンダ付けはコツさえ掴めば難しくないが、コツを掴むまでに何個か焼く。どうせ一個50円なので多めに買ったほうが良いだろう)。




というわけで、単純かつ安価に結構な性能のマイク?が手に入ってしまった。いや高性能なマイク使ったこと無いのでわからないんだが、少なくとも無音時のノイズみたいなのがびっくりするほど小さい。ここまでとは。
実際に作る場合は予め予備のマイクを買い込んでおいて、FET2つに余り物の抵抗とコンデンサでせいぜい300~500円だ。

CubaseでMediaBayを開くとクラッシュする時の対処法覚書

一時はマジでどうなる事かと思った

環境:Cubase artist 7.07 64bit
OS:Windows 8.1
症状:プロジェクトファイルの如何を問わず、Mediabayを開いた数秒後にアプリケーションが応答を停止する。
対処法:C:\Users\[USERNAME]\AppData\Roaming\Steinberg\Cubase [version]内にあるmediabay3.dbってファイル(バージョンによっては微妙に名前が異なるのかも?)をふっ飛ばせば解決。

参照元:www.steinberg.net • View topic - Mediabay Crash

日本語の記事がなさ気だったので書いた。治ってよかったー

ht82v739とNjm4580でギターアンプを自作した

エレキギター云々の過程でオペアンプ回路をちと学んだのでギターアンプも作ってみた。
結果から言うと、何故か?電源を入れてからちゃんと音が出るまでタイムラグが出るというか、ディストーションのツマミをぐりぐりしないと音が出ないという変な感じになってしまったのだが、それに目を瞑ればまぁまぁなブツが出来上がった(挙動からするにコンデンサがいかんかったかなぁ)。
改善の余地はあったもののとりあえず完成させちまえ、という事で組み上げた。

回路図
f:id:suzumodoki:20160325144521j:plain
最早雑さ汚さには触れるまい。

注意!記事の最後の方で触れてるけどこいつ電源とGND逆に描いてます このままやると火花散るけど回路図修正するのめんどいんで電源だけ逆にしてねごめんね

黄色枠の部分が信号入力と増幅部分、つまりこの回路の心臓。
なんか手元にオーディオ用の220ufがあったから直列につけてみた(コンデンサ自体は必須)けどこれでかすぎた。
入力抵抗10k、帰還抵抗が10k+(0~500k)なので最大51倍の増幅を行う基本的な反転増幅回路。

赤色部分はバイアス電圧生成部(この表現正しいか不明)、オペアンプを単電源で使うための回路。
前回のギターモドキ回路と同じもんだけど、ようは電源USB5Vを47k2つで分圧したげてオペアンプにブチ込む。実はオペアンプの勉強はそんなしてないので何故これでうまくいくのかわからない(よく見かけるのは入力信号に電圧をかけて非反転加算回路っぽくするやつだけどこれは微妙に異なる)。何でもするので誰か教えて下さい。

青枠は出力部。オペアンプ出力直後のマイラコン0.047ufと10Ωの直列はZobelフィルタとかいう奴?らしくてLM386の参考回路にあったやつを試しに入れてみたらノイズが減ったので採用。これもよく分からんおまじないみたいな回路だが、高周波帯に負荷をかけて安定させる?らしいぞ。何だそりゃ。
その後の回路はバンドパスフィルタとダイオード二個による電圧リミッタ回路。このダイオードの順方向電圧Vfが0.3Vというのは結構重要で、後段のオーディオアンプの入力の絶対最大定格に等しい値である。「絶対最大定格と等しい電圧に抑えこむ」ってのはあんま良くないんだけど(もっと余裕をもたせるべき)、データシートみたらこの回路の電流じゃ0.3Vを下回るっぽいので善しとした。ちなみに一般にショットキバリアダイオードはVfが0.3~0.5Vくらいで、0.3Vを上回るようなら抵抗を直列に入れればいい。
バンドパスフィルタ、つまりLPFとHPFの合わせ技だが、こいつらはそれぞれオペアンプの出す2.5Vのバイアス電圧と広域のノイズを取り払う役目をしている。
この定数だと幾つだったか忘れたけど確か数十ヘルツと3kヘルツくらいだったかな?がカットオフになる。確か。

で下の緑がオーディオアンプHt82v739、手前に音量調整ボリュームがある以外はデータシートに載ってたアプリケーションノートそのままである。
ちなみに音量調整ボリュームは意図があってこの位置に置いたんだけど案の定裏目に出た。大人しくオペアンプの手前に置くべきだった。

~~~

さてギターアンプは一種のスピーカーなので、箱に取り付けてしまわなきゃならん。
というわけでハンズで木の板(200円)と百均の升(100円)を買ってきた。蓋のが箱より高いってなんやねん!
f:id:suzumodoki:20160325232523j:plain
後ろに電源用のUSB口を出す穴を開けて、
f:id:suzumodoki:20160325232809j:plain
基板もちゃちゃっと組み上げて(スピーカーは秋月で300円だった 在庫限りらしいっすよ@20160325)
f:id:suzumodoki:20160325234051j:plain

音は…ちゃんとした(?)アンプの音を知らないので良し悪しの判断が付かないが、この程度のシンプルな回路ではそうそう良くはないだろうと思う反面、思ったより"らしい"音は出てるんじゃないかというのが感想。残念ながら録音機材を持っていないため(Zenfone5のマイクはゴミ)、一番肝心の音は追って、という事に。だらしねぇ。


余談。
ネットでギターアンプ自作を調べると、大抵、というか、ほとんどが、LM386(及びその互換品NJM386)を使用している。
そのため当初はこれで作る予定だった。NJM386も買った。作ってみた。なんじゃこりゃ。
9Vかけてるのに音量は大したことない、というか最大倍率の200倍をかけると割れる割れない以前に発振しまくって使いものにならない、音も大して良くない、というかとにかく発振発振アンド発振でまるで話にならない!
そもそもギターのディストーションはある種の副産物というか、電源電圧まで音量を上げる事によるクリッピングが大本なんだが、実際はそんな無茶はせず前述のダイオードみたいな感じで入力信号の段階で電圧を頭打ちさせた方が色々と都合がいい。オーバードライブは何かと副作用が多く、その一つが高利得過ぎる事によるオペアンプの不安定化だった。この点を386はどうしてもクリアできなかった(というか何故386を使った作例がこんなにあるのか理解不能。何でみんな上手くいくんですかね?)。勿論オーバードライブに拘って作られた高度な回路ではその点がクリアされてるわけだ。でも今回の目標において拘るべき部分は手軽さと値段であった。
ちなみにこのアンプは結構お値段してしまった。回路部品はコンデンサだ抵抗だを幾ら買った所でせいぜい200円程度なのだが、
スピーカ300円
板200円
箱100円
ボリュームとキャップ 2セット300円
トグルスイッチ100円
フォーンジャック100円
電源用USBコネクタ100円
…でその他諸々の諸経費込で1500円程してしまっている。
これならジャンク屋で壊れた小さいアンプを買って治したほうが安上がりだったかもしれない…。



追記:20160709
コメントの存在にまるで気が付かんかった。

SIGNALの後ろにつないでいる可変抵抗はSIGNALとGRANDの間に入れて真ん中の矢印をアンプの入力に入れるほうが良いと思います。

SIGNAL --

<--- ---

GRAND 220uF

ごもっともである。そうした方がいいです(めんどいので回路図は修正しない)
あとバイアス電圧作ってる赤枠の100ufコンデンサ、無いほうがいいかもしんない。抵抗を通ってきたバイアス電圧はハイインピなんで、ここに容量でかいコンデンサがあると貯まるのにかかる時間がべらぼうに増えて前述の問題が加速する。こうなるとノイズ低減のメリットをデメリットが上回る。なんでもやりゃいいってもんじゃないっすね…


追記:20170509
やはりコメントをまるで見ていなかった。

HT82V739のGNDとVDDが逆ですよw

うわぁ、本当だ…
厳密にはピンアサインの名前はあってるんだが繋いでるものが真逆だ。この通りにつなぐと最悪火花が散る。なんでもするから許して!


追記190207 コメント返信

お世話になります。僕もHT82V739を使って遊んでいます。お聞きしたいのはHT82V739の1番ピンには1μFを繋ぐのが普通ですが22μFを使っておられます。これを大きくすると壊れると言われていますが、今まで問題はなかったですか?
僕もこれを大きくして低音を利かせたいと考えています。ご意見を貰えたら嬉しいです。

コメント頂きありがとうございます。1番ピンには~とありますがおそらく2番ピンの事ですね。
データシートによる2番Aud In端子の記述をまとめると、

  • 絶対最大定格は-0.3[v] ~ +0.3[v]
  • アンプはこの端子の入力を増幅して吐く

ということで、ここには極端な話-0.3~0.3Vまでの電圧しか入らないならコンデンサが何であろうが良いという事になります。
公式の参考回路では1uFのコンデンサを介して信号を入れてますが、直流カットという目的では何Fでも構いません。
また前段の出力部にあるダイオードクリッパ回路でプラスマイナス0.3Vをクリッピングしている為、数値は割と何でも問題ありません。

おそらく「RC ハイパスフィルタ」とかで調べるとより詳しく幸せになれます。面白いものが完成したら教えてね!