/ 雑記帳

明けたら閉めましょう...

今年もよろしくお願いしますm(_ _)m
年の初めから毒舌?
何時食べられるか分からないステーキより今食べられるお茶漬けだと(笑)
食べたことの無い高級な料理や食材の味を力説した所で説得力は無いから...
リアル世界現実で食べたり聴いたりしないと納得出来ないのが普通の人だと思う。

— posted by くま at 02:09 am  

このブログは書き込みが出来ない...

表題の通りなのだ(笑)

あまりに広告リンクの書き込みスパムが多くて
だいぶ前に書き込みが一切出来ない様に設定を変更した。
本来は自分と同じような事をしている方々から
色々な知識、意見を頂戴するのが目的のブログだったのだが...
一方通行ではやはりマズいと考えて連絡方法を
かなりかなり目立ない様に設定して結構時間が過ぎたが...
誰も気が付かないのか?あるいはまったく詰まらないから
意見すら無いのか(笑)

— posted by くま at 10:24 pm  

 

変換コネクターを作らないと

IN4



雑記...
某高級音響機器の接族規格の宣伝を見た。もうがっかりすぎる。
SONYのベーターマックス技術の様に仕様を公開せず性能の良さをいくら宣伝した所で
無意味なのが分からないんだろうか?
お金が儲けたいなら早く実用新案、特許を申請して仕様を公開して欲しいと強く思う。
才能のある技術者からドライバー開発の意思表明があったのに断ってしまって
ホントもったいない。
結局は何も進んでない?のでは(怒) 
結局多くの人が購入出来ない超高級機にコネクタだけ付いて
そこに繋がれる機器、ドライバーはまともに開発されずにお飾りになってしまう様に思えて残念だ。

それが美味いのか不味いのか食べてみないと分からんでしょ
いつか食べられる高級ステーキよりもすぐに食べられる牛丼に価値があると(笑)

— posted by くま at 11:12 am  

Archlinux rt kernel...

今Linux archlinux 5.9.1-rt20-1-rt のカーネルで
クリスマスソング?(ビル・エバンス)を聞いている。(笑)

archlinuxはrtカーネルをKernel再構築という
面倒な作業無しに聴けるのでお気に入りである。
5.9.1-rt20-1-rtの方は所謂AUR (en) からインストール出来る。
これは yay を使わないとインストール出来ないが
通常のpacmanでもrt(リアルタイムKernel)はインストール出来て
こちらのバージョンは現在 Linux ArchPlayer 5.4.82-rt45-1-rt-lts だ。
「l」が付いているのはubunntuとかと同じで長期?サポートという事らしい。

2つのカーネルの音質を比較して一番差異を感じるのは
自分の環境では
lrtの方がrtに比べて音の余韻が感じられる所だ。

何回かconfigを弄り回して最小Kernelを目指した事があるが
苦労する割に見返りが少ないので最近は吊るしのカーネルで大人しく聴いている。

— posted by くま at 09:01 am  

I2S送受信基板の電源

市販品のI2S入出力付きのDACやデジタルプレーヤーでは
手を入れるのが困難だと思うが...
自作品となれば話は別になる。
贅沢な電源基板をやなさんのI2S-HDNI送受信基板に
組み合わせて聴くと分解能の高さに気がつくはずで
改めて電源の重要性を感じる。
現状で市販されているのDAC-ICはI2S入力が大部分なので
プレーヤーから接続される入力信号は手を加えないI2S信号そのものがベストだと思う。
SPDIFとか光とかで入力されても結局最後はI2Sに変換されてDAC-ICへ入力されるのだから
I2S信号でやりとりするのがやはり一番シンプルで劣化が少ないと考えている。

光入力は直接接続していないから最高という意見を目にするが
結局光を出すための光素子をドライブしているのは送り側回路中トランジスタ等である。
回路中のVCC-GND間で動作しているのでそこにノイズが存在すればその分も光るはずで(笑)。
ノイズ成分が伝送されないとすればそれはVCC-GND間に存在するノイズ成分を
伝送していないと言う事であり何らかのフィルターが介在している事と同じだと思う。
果たしてそれがノイズだけだと誰か断定出来るのだろうか?

— posted by くま at 09:02 am  

Archlinux(Intel-PC) + lightmpd(APU1C2) 運転、様子見状態

アキュフェーズ、エソテリック 何ですかそれ?食べられますか?
まったく縁の無い管理人(笑)
肋骨骨折に加え大雪に襲われ雪かき作業に追われます。
「痛い寒い辛いです。」
愚痴はコレぐらいにして...

Archlinux + lightmpd + PinkFaunI2Sbridge が中々良い音を出してくれています。
オリジナルのlightmpdと同じく polipo もインストールして動作させています。
電源ON-OFFもACPI管理パッケージをインストールして
電源スイッチで停止出来る様に設定しました。

もっと安価でシンプルな改造に適したサウンドカードを探しています。
傷が癒える春頃までにI2S出力サウンドカード普及委員会を
発足しようかと考える今日この頃です。(冗談^^;)

Audioは金持ちだけの趣味では無いと思います。
工夫次第でお金をかけずにしかしカウンターポイント的な
そんなアプローチがあると考えています。
自分の装置が高価で良い音だと...他人には中々入手出来ない状況で自慢するのは
ホント Audioをつまらなくしますよね...場の空気を読んで欲しいです。
人それぞれ自分の主張があって多方面からアプローチ、その結果を楽しむ それでいいでしょ?
個人的には専用のスレとか掲示板でも作ってその中やって欲しいとか思います。
自分の主張を抑えられない...自分もそういう時はあるけどね。
まあ Audioの前に他人への配慮思いやり...ジェントルマンで有りたいなぁとか(笑)

Arch-intel



— posted by くま at 10:36 am  

lightmpd 外伝...

lightmpdの代表的な二台構成はAPU1,2の組み合わせですが、
その片方(Player側)を一般的なPCにlinux-OSをインストールした環境に置き換えて
lightmpd/upnpgw的な事ができるのか?

この組み合わせが可能な事、基本的な設定をmoct氏に教えて貰いました。
難易度は高めかも知れませんがハード的な相性の解消には良い手段だと思います。

自分の環境ではIntel-CPU i5 i9を使用したPCでPinkFaun Saundカードを使用した場合に
lightmpd/x86では動作不能という事に対する対策でもあります。
作り方はAPU二台構成時のPlayer側の設定を一般PCにlinux-OSをインストールした環境に施すだけです(笑)
自分はArchlinuxが常用なのでそれでテストしてみました。
Archlinuxは特殊な設定があり扱いにくいかも知れないので(笑)
UbuntuStudio lowlatency kernel が良いのでは無いかと思います。
サラッと書いていますが結構試行錯誤の部分が多いかも知れません^^;

APUは
Audio的に良いハードだと思いますがIntel,AMD CPUを装備したPCと比較して
少しパワーが足りないです。
Intel,AMD CPUは少々設定調整技術が足りなくても力ずくで解決してくれる様に感じます(笑)

肝心の出音ですがAMD-PCにlightmpd/upnpgw環境を2つ作って比較してみました。
2つとはUSBメモリーを使った純正仕様とM・2インストールArchlinux です。
フロントは共通としてAPU1C2(USBインストールx86版lightmpd)
結果はどちらも良いです...嗜好の範囲だと感じます

— posted by くま at 02:19 pm  

個人的な事

先日、勤務中に転倒して怪我をしました。
頭部裂傷、肋骨骨折です。
なのでしばらく冬眠する事にします。
現状、装具を付けて車の運転がやっと...(笑)
肋骨が開く動作はすべて厳しいです。
モノを持ち上げる動作すら激痛で無理みたいです。
追記:
緊急外来で撮ったCTで肺にデキモノが三個発見されました...なんだかなぁ

— posted by くま at 09:49 am  

Pink faun i2s bridge card 破損


この記事でも語られていますがカードの表面を覆っている?
SMD電解コンデンサーのリード部分が脆いです。
自分のカードではI2S送り出しICへ電源供給している部分の電解コンデンサーが取れました!
デジキーで同じ規格メーカー品が販売されている事は確認できましたが...しかし
転んでタダでは起きない管理人なのでPanasonic製OSコンを付けて見ました。
あれ!音が激変(笑)...すべての電解コンデンサーを交換する誘惑に勝てそうもない。

吾唯知足(われただたるをしる)の心境へたどり着くのはいつの日か?
追記...実はその日のうちにやってしまいました。...
交換直後はなぜか?音が引っ込んでしまって二三日は全部交換は失敗か!とか悩みましたが
聴き込むうちに低音域がソリッドに且つ再生域が広がって来て おお!(笑)

after



— posted by くま at 04:41 pm  

 

ddコマンドのbs値の最適値は?

目から鱗状態でナルホドと(笑)
ddコマンドのbsサイズ
とりあえず我が家の環境での最適値を調べて見ました。
# ./dd-speed.sh
creating a file to work with
1175000+0 レコード入力
1175000+0 レコード出力
601600000 bytes (602 MB, 574 MiB) copied, 5.61014 s, 107 MB/s
---------------------------------------
Testing block size = 16M
35+1 レコード入力
35+1 レコード出力
601600000 bytes (602 MB, 574 MiB) copied, 3.30805 s, 182 MB/s

---------------------------------------
Testing block size = 32M
17+1 レコード入力
17+1 レコード出力
601600000 bytes (602 MB, 574 MiB) copied, 7.94921 s, 75.7 MB/s

---------------------------------------
Testing block size = 64M
8+1 レコード入力
8+1 レコード出力
601600000 bytes (602 MB, 574 MiB) copied, 5.46157 s, 110 MB/s

---------------------------------------
Testing block size = 128M
4+1 レコード入力
4+1 レコード出力
601600000 bytes (602 MB, 574 MiB) copied, 4.77684 s, 126 MB/s

---------------------------------------
Testing block size = 256M
2+1 レコード入力
2+1 レコード出力
601600000 bytes (602 MB, 574 MiB) copied, 4.90123 s, 123 MB/s

---------------------------------------
Testing block size = 512M
1+1 レコード入力
1+1 レコード出力
601600000 bytes (602 MB, 574 MiB) copied, 5.73013 s, 105 MB/s

bs=16M が最適値の様ですね。

— posted by くま at 04:23 pm  

<< 2024.11 >>
SMTWTFS
     12
3456789
10111213141516
1718 1920212223
24252627282930
 
























T: Y: ALL: Online:
ThemePanel
Created in 0.3658 sec.