raspi系シングルボードコンピュータのハイレゾ音源化再び

1/13のエントリーで書いたraspberry piに5102AハイレゾDACをつないで鳴らなかった件の顛末と対策

初代のraspberry piはI2Sのピンが用意されてなくて2x4の8ピンのピンヘッダをはんだ付けする必要があったのに知らなくて適当にraspi3のピン配列（のように）つないだので鳴らなかったようだ。
そのうえ初代のraspberry piにはvolumio2は重過ぎるのかNAS上のフォルダの認識などで問題も出ていたしいざ曲の再生をしてみるとレスポンスも悪くて音も途切れがちでちょっとゆっくりと音楽鑑賞とはいかない感じだった。volumioのバージョンを1.55に戻したら安定したのでこれくらいがシングルコアのarm＠700MHzには良い負荷なのかもしれない。
今後の方針として5102aのDACを再生させるのに2つの方針が考えられる。
１）raspberry pi2以降とvolumio2の組み合わせ
２）raspberry pi zeroとvolumio1.55の組み合わせ

１）だとハイパワーになったSoCのために今までよりも強力な電源を用意したりSoCの放熱の問題を考える必要が生じる
２）はNASへの接続のことを考える必要がありそうで悩ましい

目標はNAS上の音楽データを出来うる限り安定して良音で再生する環境を構築することなので現状での選択肢は１）が有力
SoCに何を選択するかが次なる問題となるが候補は各々RaspberryPiの
2B,3B,3B+,4となるが2Bは今や品薄で3と価格が変わらないので除外
４はまだまだ共有が安定しないしVolumioの対応具合も不明なので最有力候補は3Bもしくは3B+となる。amazonの3B+の感想に
「aspberry PiはPi 3B, 3B+, 4Bを所有しており、今回購入の３B+は２台目。3B+は3Bと比較して電源周りが良くなっていてノイズが少なく、微少信号取得などの応用には最適。４Bとの比較でも、CPUパワーは４Bの方が高いが、プログラムによっては３B+の方が速い場合がある。４Bが安定するまでは、Piの産業応用には３B+が最適と感じている。世界的な品薄状態が続いているのが残念。」とあるし価格も3Bが秋月でRS版が@5200(送料別)なのに上記のAmazonの３B+が@6000と言うことなので実に悩ましい　どうせ2.5Aの比較的良い電源も欲しいしSoCのヒートシンクも欲しいので3Bで秋月と言うことになりそうな気もする。
Amazonだとケース等も安くありそうでこちらも悩ましい。

考えて疲れてきた（実はこれが楽しい）　続きは後日

C# 再入門(その１）

うーん。どうしてなんだろう。
datagridviewにデータを簡単に出そうとするが出ない
ちょっと応用しようとするとコードの意味を見失う

結局、データベース系の各オブジェクトの依存関係を正しく把握してないことが原因だとはわかっているけど・・・
で、いきなりFE6だ、dapperだORMだとやってみても上手くいかない

手持ちの2008(C#3.5)頃の手持ちの書籍をいろいろとひっくり返してとうとう秀和システムの「VisualC#2008逆引き大全555の極意」に立ち返った（750ページ以上もある辞典みたいな書籍なんだけど今じゃ古書で\100なのね）
これの251番～の項目が一番しっくりときた
もっともローテクな感じの記述なのだがすんなり入る
自分の思考方法が古いある点で固定しているのかなとも思うけど現状持っている知識で思い付きを形にするために書くことができるのはこういうプリミティブな知識が系列的に説明されているものをかみ砕いて得る基礎によるんだと再認識（やっぱりブラックボックスはあきません）

あぶねー！raspiよ なんとかしてくれよ！

昨日、rasberry pi用にと用意したハイレゾ対応のDACが届いた。

とはいえそれほどたいそうなものでもないのでネットで探った結線を頼りにつないでみたが無音。
USBDACにかえたら一応音は出たもののライブラリーもちょっとしか出ない。ついでにとSDの内容を書き換えてVolumio2にしたらこちらは激重で画面の更新時にも音が途切れる。

いろいろ探して初期raspiはVolumio1.55+USBDACに戻すことにした。

あーあraspiの3Bでも格安で探さなきゃだわ

データベースをいろいろ弄ってみる

まずは自分的には標準データベースエンジンでもあるAccessのJETとsqlite3を比べてみる
言語としてはaccess,c#,pythonぐらいで１つのsqliteのデータベースを操作して扱いやすさとか速度を色々見てみる。

<2020/1/8 追記>

AccessでSQLite3	10000recのaddnew
トランザクション	ローカル	NAS上
あり	0.4375	0.6406
なし	972.2188	980.6211

まずはAccessにODBCでSQLite3のファイルをリンクして10000

レコードの挿入をVBAでやってみた。普通にやるとあまりにも遅いのでトランザクションを使ったら約1500~2200倍の速度向上となった

リモートとローカルの違いは挿入では余りないようだ。

検索についても調べてみよう。

書初め失敗

昨日、今年最初のプログラミングとしてjetEFに挑戦してみた
上記のリンクの写経をしようとしただけなのだが結果は・・・

残念、まったくうまくいきません。て言うか力もしくは経験値の絶対的な不足でした
そもそもVSの機能をうまく使いこなせてない
WindowsFormとソースエディタだけをいじればなんとかなるもの以外はWPFも含めて何も手が出ない
今、力不足を知れてよかったと思って今年の目標にVS攻略を掲げようと思いました

ちょっとmandelbrotの基本描画の時間を比較してみた・・・そしてgo-langに道草

これまでにもたびたびmandelbrot集合の描画をいろんな言語で書いてその様子をここに上げてきたけど都度上げていると環境も変わったりして本当の意味の比較にならなかったこともあるので手元に残っている言語などで再度計測したりして比較をしてみた

条件
　　画面は640ｘ480相当　色は8色（あんまり速度と関係ないけど）
　　N88BASICのように縦方向に制限があるものは400ドットの場合
　　があるがあまり意味が無いので気にしない。
　　そもそも比較的新しい言語では縦方向の制限がされているものは
　　総じて他と比較にならないほど遅いので・・・
　　※上記ではN88BASIC on anex86がそうだけど
　　　更に2割遅くなっても・・・まあ仕方なし
結果
　
　　すぐさま引き出せるソースのあるものではprocessingが最速
　　さすがにベースがjavaなことはあると思う
　　次点はc#で画面を1次元の配列イメージで描いたもの
　　次がc#で普通に描いたもの（その差4倍弱）
　　その次にpythonで描画をpygameで速めて、mandelの発散
　　確認をnumbaの@jitで実行時にコンパイルしたもの
　　後は1秒以上かかっているしエミュレータはやはり遅い
　　好奇心でeFMR-50(i286)でpanacom用のmbasicでもやって
　　みたが自分で我慢できずに止めました（遅くて耐えられない）

来年はこの手のお遊びは自重してc#で業務ソフトを書くことと
go-langでシステムよりの実験をいろいろ書こうと思ってます
※本日go-lang最新go1.13.5をインストール(go-walkも）
もちろんこんな自分のことですので気の向くままに脱線しますが
温かい目でよろしく見守ってくださいね

暫くは安定路線を・・

ちょっと前のエントリーでC#+Databaseをいろいろやってみようと思うようなことを書いたけどMicrosoft謹製の開発環境VisualStudioでの使用を考えるとC#だけではなくてpythonにも目を向けたくなる。
最近のMicrosoftはソリューションの構成要素としてスクリプト言語にはpythonを、そしてweb系記述言語にはnode.jsをはっきり押していると思う。
VisualStudioのサポートするメニューでその他のウィンドウメニューを見ても

F#,C#のキーワードに加えてpython,node.js押しなのが伺われる。

当然、同環境ではそれらは自然に使えると思うので活用したくなる。

さてどうやって使おうか?