ddコマンドのbs値の最適値は?
2020/11/29
目から鱗状態でナルホドと(笑)
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 が最適値の様ですね。
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
Sound Blaster X-Fi Titanium をlightmpdで使えるか?(改造仕様I2S出力で...)
2020/11/28
Donuts Shopさんが公開してくれたlightmpd/upnpgwには
Sound Blaster X-Fi Titaniumを動作させるためのドライバーは組み込まれていません。
(lightmpdは当初usb接続DACを想定して開発されたのが理由だと思います。)
とりあえず基板の改造は成功したので
次はlightmpd/upnpgwで音を出してみたいと思いました。
ドライバーの組み込み(kernel再構築)は.configで組み込むドライバーの項目をチェックするだけのはず...
x86_64-upnpgw-20200310.zipをベースにして CONFIG_SND_CTXFI=y
何回かトライして成功(笑)
# uname -a
Linux lightmpd 5.4.22-rt13-lightMPDx86_64 #2 SMP PREEMPT_RT Sat Nov 28 11:45:40 JST 2020 x86_64 GNU/Linux
# aplay -l | grep ctxfi
card 0: XFi [Creative X-Fi], device 0: ctxfi [Front/WaveIn]
card 0: XFi [Creative X-Fi], device 1: ctxfi [Surround]
card 0: XFi [Creative X-Fi], device 2: ctxfi [Center/LFE]
card 0: XFi [Creative X-Fi], device 3: ctxfi [Side]
card 0: XFi [Creative X-Fi], device 4: ctxfi [IEC958 Non-audio]
注意事項!
lightmpd/upnpgw スタンドアローンで音出しは成功しました!
良い音だと思います。
実験に使用した環境はGA-EP45-UD3R + Core2Quad Q8400S2.66GHzPC です念の為...
たぶんi3〜i5はダメだと思われます。
誰か?Xeonでテストしてくれれば良いのにとか思ってます。
lightmpd掲示板でカーネルビルド方法を教えていただいたDonuts Shopさんに感謝です。
---------------------------------------------------------------------------------------------------
壊す前にバックアップを(笑)
$ time dd if=/dev/sdd conv=sync,noerror bs=512k | gzip -c > Lightmpd-blaster.img.gz
29328+0 レコード入力
29328+0 レコード出力
15376318464 bytes (15 GB, 14 GiB) copied, 684.607 s, 22.5 MB/s
real 11m24.628s
user 1m28.601s
sys 0m24.100s
レストアコマンド例
$ gunzip -c Lightmpd-blaster.img.gz | dd of=/dev/sdd bs=512k
0+404940 レコード入力
0+404940 レコード出力
15376318464 bytes (15 GB, 14 GiB) copied, 1599 s, 9.6 MB/s
参考リンク
Pinkfauni2s bridge card + lightmpd/upnpgw プレーヤー側構築
lightmpd/upnpgw intel inside (2)
Sound Blaster X-Fi Titaniumを動作させるためのドライバーは組み込まれていません。
(lightmpdは当初usb接続DACを想定して開発されたのが理由だと思います。)
とりあえず基板の改造は成功したので
次はlightmpd/upnpgwで音を出してみたいと思いました。
ドライバーの組み込み(kernel再構築)は.configで組み込むドライバーの項目をチェックするだけのはず...
x86_64-upnpgw-20200310.zipをベースにして CONFIG_SND_CTXFI=y
何回かトライして成功(笑)
# uname -a
Linux lightmpd 5.4.22-rt13-lightMPDx86_64 #2 SMP PREEMPT_RT Sat Nov 28 11:45:40 JST 2020 x86_64 GNU/Linux
# aplay -l | grep ctxfi
card 0: XFi [Creative X-Fi], device 0: ctxfi [Front/WaveIn]
card 0: XFi [Creative X-Fi], device 1: ctxfi [Surround]
card 0: XFi [Creative X-Fi], device 2: ctxfi [Center/LFE]
card 0: XFi [Creative X-Fi], device 3: ctxfi [Side]
card 0: XFi [Creative X-Fi], device 4: ctxfi [IEC958 Non-audio]
注意事項!
lightmpd/upnpgw スタンドアローンで音出しは成功しました!
良い音だと思います。
実験に使用した環境はGA-EP45-UD3R + Core2Quad Q8400S2.66GHzPC です念の為...
たぶんi3〜i5はダメだと思われます。
誰か?Xeonでテストしてくれれば良いのにとか思ってます。
lightmpd掲示板でカーネルビルド方法を教えていただいたDonuts Shopさんに感謝です。
---------------------------------------------------------------------------------------------------
壊す前にバックアップを(笑)
$ time dd if=/dev/sdd conv=sync,noerror bs=512k | gzip -c > Lightmpd-blaster.img.gz
29328+0 レコード入力
29328+0 レコード出力
15376318464 bytes (15 GB, 14 GiB) copied, 684.607 s, 22.5 MB/s
real 11m24.628s
user 1m28.601s
sys 0m24.100s
レストアコマンド例
$ gunzip -c Lightmpd-blaster.img.gz | dd of=/dev/sdd bs=512k
0+404940 レコード入力
0+404940 レコード出力
15376318464 bytes (15 GB, 14 GiB) copied, 1599 s, 9.6 MB/s
参考リンク
Pinkfauni2s bridge card + lightmpd/upnpgw プレーヤー側構築
lightmpd/upnpgw intel inside (2)
— posted by くま at 11:52 am
本日改造したSound Blasterサウンドカードは...
2020/11/27
$ lspci | grep Sound
03:00.0 Audio device: Creative Labs EMU20k2 [Sound Blaster X-Fi Titanium Series] (rev 03)
$ aplay -l | grep XFi
カード 0: XFi [Creative X-Fi], デバイス 0: ctxfi [Front/WaveIn]
カード 0: XFi [Creative X-Fi], デバイス 1: ctxfi [Surround]
カード 0: XFi [Creative X-Fi], デバイス 2: ctxfi [Center/LFE]
カード 0: XFi [Creative X-Fi], デバイス 3: ctxfi [Side]
カード 0: XFi [Creative X-Fi], デバイス 4: ctxfi [IEC958 Non-audio]
$ cat /proc/asound/card0/pcm0p/sub0/hw_params
access: RW_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 44100 (44100/1)
period_size: 4410
buffer_size: 22050
$ cat /proc/asound/card0/pcm0p/sub0/hw_params
access: RW_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 96000 (96000/1)
period_size: 4096
buffer_size: 16384
$ cat /proc/asound/card0/pcm0p/sub0/hw_params
access: RW_INTERLEAVED
format: S24_3LE
subformat: STD
channels: 2
rate: 192000 (192000/1)
period_size: 4369
buffer_size: 21845
03:00.0 Audio device: Creative Labs EMU20k2 [Sound Blaster X-Fi Titanium Series] (rev 03)
$ aplay -l | grep XFi
カード 0: XFi [Creative X-Fi], デバイス 0: ctxfi [Front/WaveIn]
カード 0: XFi [Creative X-Fi], デバイス 1: ctxfi [Surround]
カード 0: XFi [Creative X-Fi], デバイス 2: ctxfi [Center/LFE]
カード 0: XFi [Creative X-Fi], デバイス 3: ctxfi [Side]
カード 0: XFi [Creative X-Fi], デバイス 4: ctxfi [IEC958 Non-audio]
$ cat /proc/asound/card0/pcm0p/sub0/hw_params
access: RW_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 44100 (44100/1)
period_size: 4410
buffer_size: 22050
$ cat /proc/asound/card0/pcm0p/sub0/hw_params
access: RW_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 96000 (96000/1)
period_size: 4096
buffer_size: 16384
$ cat /proc/asound/card0/pcm0p/sub0/hw_params
access: RW_INTERLEAVED
format: S24_3LE
subformat: STD
channels: 2
rate: 192000 (192000/1)
period_size: 4369
buffer_size: 21845
— posted by くま at 05:48 pm
PC_Audio 突き詰めて行くと最後はやはり電源の質という事になる
2020/11/25
PinkFaun I2Sサウンドカード(旧版)の電源供給はPCIeからではなく
カード後部のペリフェラルコネクタ(12V,5V)からになっている。
試しにこのコネクターを抜いてPCを立ち上げてaplay -l コマンドで確認すると
カードが動作していない事が確認できる。
基本的な使い方としてマザーボード用のATX電源から供給が想定されているが
さすがに高音質を狙うにはそれでは忍びなくクマ電源基板で12V,5Vを各一枚で作ってケースに入れ
そこからサウンドカードペリフェラルコネクタへ直接供給する様にしてみた。
当然、音質は向上したが...あともうひと押ししたい気分である(笑)
PS:蛇足
音質向上のために最近は何かイジッッテいる毎日である(笑)
その中でやはりアンプとスピーカーは表裏一体の存在であるという事に改めて気がつく。
たとえば手段を選ばずに背圧を減らしコンプライアンスの向上と
コーン紙の制動を追求したスピーカーを元にアンプを開発すれば
アンプはパワーが無くても十分ドライブ可能となる。
瞬間的な電流供給能力もそこそこで問題ないと想像する。
その組み合わせで練り上げられたシステムはやはりその組み合わせで使わないと良い音が出ないのである。
何に組み合わせても良い音で鳴るスピーカーやアンプは存在しない。
例えが悪いが現代のスピーカーは能率が低い。それは再生周波数を広域にした事が原因である。
そんなスピーカーに真空管アンプを組み合わせても良い音は出せないと経験的に思う。
(アキューフェーズのアンプが欲しくなるだろう。)
やはり真空管アンプは高能率のフルレンジと相性が良い。
重いウーハーはドライブが困難なのだ。
たまに自分のリスニングルームに何百万のスピーカーを入れて自作スピーカーと比較視聴して
「勝った。勝った。」と自慢する記事を見るがそれはアンプとスピーカーのマッチングでしか無い。
カード後部のペリフェラルコネクタ(12V,5V)からになっている。
試しにこのコネクターを抜いてPCを立ち上げてaplay -l コマンドで確認すると
カードが動作していない事が確認できる。
基本的な使い方としてマザーボード用のATX電源から供給が想定されているが
さすがに高音質を狙うにはそれでは忍びなくクマ電源基板で12V,5Vを各一枚で作ってケースに入れ
そこからサウンドカードペリフェラルコネクタへ直接供給する様にしてみた。
当然、音質は向上したが...あともうひと押ししたい気分である(笑)
PS:蛇足
音質向上のために最近は何かイジッッテいる毎日である(笑)
その中でやはりアンプとスピーカーは表裏一体の存在であるという事に改めて気がつく。
たとえば手段を選ばずに背圧を減らしコンプライアンスの向上と
コーン紙の制動を追求したスピーカーを元にアンプを開発すれば
アンプはパワーが無くても十分ドライブ可能となる。
瞬間的な電流供給能力もそこそこで問題ないと想像する。
その組み合わせで練り上げられたシステムはやはりその組み合わせで使わないと良い音が出ないのである。
何に組み合わせても良い音で鳴るスピーカーやアンプは存在しない。
例えが悪いが現代のスピーカーは能率が低い。それは再生周波数を広域にした事が原因である。
そんなスピーカーに真空管アンプを組み合わせても良い音は出せないと経験的に思う。
(アキューフェーズのアンプが欲しくなるだろう。)
やはり真空管アンプは高能率のフルレンジと相性が良い。
重いウーハーはドライブが困難なのだ。
たまに自分のリスニングルームに何百万のスピーカーを入れて自作スピーカーと比較視聴して
「勝った。勝った。」と自慢する記事を見るがそれはアンプとスピーカーのマッチングでしか無い。
— posted by くま at 10:24 pm
I2S-HDMI送信基板
2020/11/22
フットプリントを正確に割り付けていません。部品名は適当です(笑)
やなさんの基板が廃版になるので作ろうかとか考えています。
作るとは言っていません!
ふざけた部品でシュミレーションして見ましたが出来そうですね(笑)
追記
こんなイメージ...Combo384に亀の子にも出来そう(現状はそのピン配置では無い)
需要なんてあるのか?(笑)
やなさんの基板が廃版になるので作ろうかとか考えています。
作るとは言っていません!
ふざけた部品でシュミレーションして見ましたが出来そうですね(笑)
追記
こんなイメージ...Combo384に亀の子にも出来そう(現状はそのピン配置では無い)
需要なんてあるのか?(笑)
— posted by くま at 12:10 pm
Archlinux 指定kernelで起動させる設定
2020/11/18
/etc/default/grubを下のように書き換えて
# GRUB boot loader configuration
GRUB_DISABLE_SUBMENU=y #サブメニューを無効にする
GRUB_DEFAULT=2 #二番目のエントリーで起動の意
コマンドでブートローダーを更新する。
# grub-mkconfig -o /boot/efi/EFI/GRUB/grub.cfg
参考リンク:GRUB/ヒントとテクニック
# GRUB boot loader configuration
GRUB_DISABLE_SUBMENU=y #サブメニューを無効にする
GRUB_DEFAULT=2 #二番目のエントリーで起動の意
コマンドでブートローダーを更新する。
# grub-mkconfig -o /boot/efi/EFI/GRUB/grub.cfg
参考リンク:GRUB/ヒントとテクニック
— posted by くま at 04:00 pm
Archlinux rt kernel動作確認
2020/11/16
本日 moct氏からいただいたリアルタイムカーネルをインストールして動作が確認出来ました。
残念なのはこれから夜勤へ行かないと...
# uname -a
Linux ArchPlayer 5.9.1-rt20-1-rt #1 SMP PREEMPT_RT Tue, 10 Nov 2020 16:01:50 +0000 x86_64 GNU/Linux
現状使っているカーネルも残したいのでデュアルブートとするため
GRUB に自動で他のシステムを検索してほしいので、os-prober をインストール
/etc/grub.d/40_custom と grub-mkconfig を使って自動生成する。
# grub-mkconfig -o /boot/grub/grub.cfg
UEFI-GPT モードでは
# grub-mkconfig -o /boot/efi/EFI/GRUB/grub.cfg
肝心の2つのカーネルの音質については後ほど...^^;
5.4.70-rt40-1-rt-lts
5.9.1-rt20-1-rt
追記:11-19
個人的見解?ですが
2つのkernelの音の違いは音の余韻響きに違いがあると思います。
特に低音域は顕著でドラム、ベースの切り口の輪郭がはっきりするイメージ。
中高音域も音が出た後の響きが少なくなる付帯音が減るイメージです。
残念なのはこれから夜勤へ行かないと...
# uname -a
Linux ArchPlayer 5.9.1-rt20-1-rt #1 SMP PREEMPT_RT Tue, 10 Nov 2020 16:01:50 +0000 x86_64 GNU/Linux
現状使っているカーネルも残したいのでデュアルブートとするため
GRUB に自動で他のシステムを検索してほしいので、os-prober をインストール
/etc/grub.d/40_custom と grub-mkconfig を使って自動生成する。
# grub-mkconfig -o /boot/grub/grub.cfg
UEFI-GPT モードでは
# grub-mkconfig -o /boot/efi/EFI/GRUB/grub.cfg
肝心の2つのカーネルの音質については後ほど...^^;
5.4.70-rt40-1-rt-lts
5.9.1-rt20-1-rt
追記:11-19
個人的見解?ですが
2つのkernelの音の違いは音の余韻響きに違いがあると思います。
特に低音域は顕著でドラム、ベースの切り口の輪郭がはっきりするイメージ。
中高音域も音が出た後の響きが少なくなる付帯音が減るイメージです。
— posted by くま at 03:27 pm
帯域幅が足りない様な気がするけど 余計なお世話かぁ間違いかぁ(笑)
2020/11/15
某掲示板で DSD11.2MHzの再生 という質問を見たが
DACのデジタル入力仕様が 同期 帯域:28 kHz 〜 200 kHz
とあるから192KHzまでの入力対応という事なのかな?
だとすればDSD64ぐらいまでが限界の様に思う。
参考までに自分の環境でDSD11.2MHz(DSD-native)再生した時は
$ cat /proc/asound/card1/pcm0p/sub0/hw_params
access: RW_INTERLEAVED
format: DSD_U32_LE
subformat: STD
channels: 2
rate: 352800 (352800/1)
period_size: 32768
buffer_size: 131072
DSD-nativeでさえ
352.8KHzの帯域を使って再生してるから...
再生したファイルの参考データー
Album : ドラマチック<2016デジタル・リマスター>
Audio
Format : DSD
Format/Info : Direct Stream Digital
Commercial name : DSD256
Format settings : Little
Duration : 4 min 4 s
Bit rate : 22.6 Mb/s
Channel(s) : 2 channels
Channel layout : L R
Sampling rate : 11.3 MHz
Compression mode : Lossless
Stream size : 658 MiB (100%)
DACのデジタル入力仕様が 同期 帯域:28 kHz 〜 200 kHz
とあるから192KHzまでの入力対応という事なのかな?
だとすればDSD64ぐらいまでが限界の様に思う。
参考までに自分の環境でDSD11.2MHz(DSD-native)再生した時は
$ cat /proc/asound/card1/pcm0p/sub0/hw_params
access: RW_INTERLEAVED
format: DSD_U32_LE
subformat: STD
channels: 2
rate: 352800 (352800/1)
period_size: 32768
buffer_size: 131072
DSD-nativeでさえ
352.8KHzの帯域を使って再生してるから...
再生したファイルの参考データー
Album : ドラマチック<2016デジタル・リマスター>
Audio
Format : DSD
Format/Info : Direct Stream Digital
Commercial name : DSD256
Format settings : Little
Duration : 4 min 4 s
Bit rate : 22.6 Mb/s
Channel(s) : 2 channels
Channel layout : L R
Sampling rate : 11.3 MHz
Compression mode : Lossless
Stream size : 658 MiB (100%)
— posted by くま at 10:35 pm
Comments