このメッセージを書き込むのに大分時間がかかったのですが、確認環境を整備し、基本的な確認を取るのに手間取りました。

確認環境というのはオーディオラックとは別にスチール棚を用意し、そこにキツネDAC、Gustard X20、rpi-3b+とI2S TX_C2 GLA HDMI変換基板及び関連電源をひとまとめにしたものです。
ケーブルによる差はあるかなと考え、30cmのものと2mのSAEC製の音が良いとされているもので、確認しましたが、差が無いので、2mで全て確認しています。
rpi-3bはSMPDで動かし、版数は0.830です。
config.txtはdtoverlay=rpi-dacの指定だけです。

「あれ、HIFI DAC HATはどうなったの」という質問があるかと思います。これは、以前のスレッドでの問題点の「pi-3b+と変換基板を直接つないだ時、アンロックのままで、接続出来ない」は僕の確認ミスと分かったので、問題をシンプルにするために、HIFI DAC HATを外したのが理由です。

従って、キツネのi2s-DSD再生に関する問題点は一つだけで

①audio_output_format "*:32:*"を指定すると、モードに関わらず、352Kに変換され、再生される。
②結果として、頻繁に音切れが発生する。
③また"*:*:*"又は何も指定しないと、モードに関わらず、176Kが表示されるが、
④音は出ない

というものです。
パパリウスさんの質問にお答えしておきます。

問1、「キツネDACは32bit変換は必須ですか？」ですが、PCM再生に関しては必須ではありません。
DSD再生については、上記の「モードに関わらず」という部分が回答となります。「Linux側が無条件に352KPCMに変換しているようだ。」ということになります。

問2、「デフォルト設定(samplerate_converter も audio_output_format もコメントアウトした状態）だとPCMの再生に問題は生じますでしょうか？」はyesです。問題なく再生できます。

このディフォルトの設定で64MDSDを再生した場合キツネは③④となり音が出ません。X20の場合は64DSDと表示され、再生もされます。これはX20の方が標準的な動作であり、キツネの動作は①何故176Kという表示になるのか、②何故音が出ないのか、という疑問点があります。

次にaudio_output_format "*:32:*"を指定した場合ですが(PCM44.1K、DSD64Mの再生)、両者ともにPCMは44.1Kで、DSDは352KPCMに変改され、再生されます。これはPCM、DSD共に、"*:32:*"がLinux側でそのように解釈され、処理されているということなのでしょうか。

ちなみに、Windows10で、TurboBrowser(以降、TB)を使って確認しました。Matrix X-spdif2(TBとはusb接続)のHDMI出力を使って確認したら、DSD64Xと表示されDSDネイティブ再生されました。

ということで、Linux&SMPDで発生する問題であるようです。

>キツネの動作は①何故176KPCMという表示になるのか、②何故音が出ないのか、という疑問点があります。

smpdはDoPで送っているのにキツネがPCMとして認識してるみたいですね。これがデフォルト設定で音が出ない理由ですかね。

samplerate_converter で"soxr high"を指定すると本物のPCMに変換して送り出してくれるはずなので、音が出ると思います。

ものは試しで、audio_output_format "*:24:*"にしたらどうなりますかね。

Passさん

> samplerate_converter で"soxr high"を指定すると本物のPCMに変換して送り出してくれるはずなので、音が出ると思います。

これが出ないのですよね。

> ものは試しで、audio_output_format "*:24:*"にしたらどうなりますかね。

352Kと表示され、音も出ます。但し、音切れは発生します。

> smpdはDoPで送っているのにキツネがPCMとして認識してるみたいですね。これがデフォルト設定で音が出ない理由ですかね。

DigiOne Signatureを使い、SPDIF(同軸)接続にした場合(これは間違いなくDoPの筈ですよね)、DSD64Xと表示されます。再生も全く問題なしです。音切れも無しです。不思議ですね。

謎は深まるばかりです。やっぱりキツネは手強いです。

yoさん

HDMI変換基板はI2S TX_C2 GLAで間違いないですか？

拙宅でIntegrated250と接続してテストした基板は、I2S TX_C1 GLAです。

C1がPS Audio準拠のはずです。もしC2なら差動出力のピン配列が違うのでおかしな動作になっても不思議はありませんね。

Passさん

済みません。C1の間違えです。基板をみながら入力した時のタイプミスです。

yoさん、こんばんは

動作確認用のmpdをアップしました。
http://mpd.sytes.net/release/v0.8.x/ex/mpd.doptest" target="_blank">http://mpd.sytes.net/release/v0.8.x/ex/mpd.doptest

/usr/local/bin/mpdをバックアップした上で、差し替えてみてください。

これは、DoP関連のパラメータを3つ追加してあります。
/etc/mpd.confのaudio_outputの上に、パラメータを3つ追記してください。

記載例）

dop_shift8 "true"
dop_pack "true"
dop_reverse_endian "true"

audio_output {
dop "yes"
type "pipe"
name "pipe"
command "exec /home/pi/misc/pcminfo.sh"
}


この3つのパラメータはtrue または false で指定します。
未設定時のデフォルト値はfalseです。
全8パターンを試して、動作に違いが出るか確認してください。

mpdはALSAライブラリのAPIでDACを何度もつついて
DACが受け入れてくれるパラメータを自動で探索してくれます。

smpdではpipeアウトプットプラグインでPCMを名前付きパイプに書き出していますが、
オリジナルのソースはDoPに対応しておりません。

DonutsさんがDoP対応のパッチを開発してくださいまして、
v0.8.8からDoPでの再生を実現することができました。

ただ、DoP用の適切なパラメータを自動で探索するような作りにはなっていませんでしたので、
mpd.confで明示的にパラメータを指定するようにしてみました。

音質上の配慮が十分とは言えない、突貫工事のビルドですが、
まずはこれで検証いただければと思います。

パパリウスさん

DoPパラメータ対応版MPDビルドありがとうございます。早速試してみました。
結果は残念ながら、全てアウトです。

samplerate_converter も audio_output_format もコメントアウトした状態で確認しました。

all false 176K表示、音は出ず
その他の設定 176K表示、全てホワイトノイズ風の雑音が再生される、雑音の音量や再生のされ方は設定により多少変化する

となりました。

audio_output_format "*:32:*"を指定すると、352K表示、再生されます(全ての組み合わせではないが、3ケースほど確認しました)。
また、この時、非常に良好な再生状態になります。特に全てをtrueに設定すると、音切れが発生頻度が相当低くなりますね(バッハ平均律5曲に1回位、これまでは一曲で数回でした)。なにか魔法をかけたのですかね。

尚、X20でも同じ状況です。samplerate_converter も audio_output_format もコメントアウトした状態でのDSD再生は all false 以外の設定では176KDSD表示、雑音。all false ではDSD64表示で正しく再生。

yoさん

よく分からない状況ですね。
HDMI入力でもDSD64XでネイティブDSDは認識できてますよねぇ。
DoPがうまく認識できないのか、176.4kがうまく認識できないのか。。。

2点試してみて頂きたいのですが、
①　audio_output_format"176400:24:*"で出力フォーマットを指定してPCM音源を再生した場合。
②　何かしらのソフトでMatrix X-spdif2のHDMI出力を使ってDoP出力でDSD64音源を再生した場合。

Passさん

samplerate_converter も audio_output_format もコメントアウトした状態で、「X20ではall false ではDSD64表示で正しく再生」されていますので、キツネ側が同じデータを受けて、176K表示するのはおかしいと思っています。この点は日本代理店に確認した方が速そうです。多分、Inttegrated250もDSD64でDoP再生できているはずで、X20と同じ振る舞いなのだろうと思います。

audio_output_format "176400:24:*"を試してみました。音が出ました。もちろん176Kと表示されます。ますます謎だらけですね。

yoさん、検証ありがとうございます。

moodeやvolumioでDoPが上手く再生できるなら、
smpdのソフトウェアの問題と断定できると思います。
mpd、aplay-rt、ドライバ、カーネル…一つ一つ検証を進めれば
対策できるのでは無いかと思います。

販売店への問い合わせも並行していただき、
ハードウェアの面からも情報を集めていただけると助かります。

yoさん

176K DSDってキツネは何を検出してるんでしょうね(笑)
ここは代理店に聞いてみたいところですね。

パパリウスさん

DSD64のファイルをsamplerate_converter で"soxr high"で指定した場合、Integrated250はPCMとして認識しています。
Integrated180はPCMしか対応していませんが、音がでます。
なのに、キツネでは音が出ないそうです。でも、PCMを176.4k 24bitアップサンプリングは音がでるそうです。

DSD64をsamplerate_converter で"soxr high"で指定した場合とPCMをアップサンプリングした場合で、出力される信号に何か違いがあるのでしょうか？

Passさん、パパリウスさん

JRIVERのmc20では、DSD再生に関し、dopとnativeが切り換えることが出来るのですが、これでキツネを試してみました。
結果はどちらもDSD64Xと表示され、再生も出来ます。dopとnativeの音の差はほとんど感じられないレベル。気のせいか(^^;;;、nativeの方がいいような気がするという感じです。

「メイジャーなものは嫌いだ。volumioなんて使ったこともない。」と、最近、何処かに書いたような記憶がありますが、この際、背に腹は変えられないので(^^;;;、moodeやvolumioで試してみることにします。「こういうメイジャーなソフトはどうやって動かすのだろう」というレベルからスタートしますので、時間がかかるかもしれませんが、気長にお待ちください。

代理店にもこれからメールします。今日は一日出歩いているので、これも返事は明日以降ですね。

Passさん、パパリウスさん

moodeとvolumioで試してみました。結果はSMPDの場合と同じです。native再生では352Kと表示され、音は出ます。dop再生では176Kと表示され、音が出ません。従って、結論として、これはキツネの問題ですね。

moode、volumio共にdopとnativeを陽に指定することが出来ます。これで指定して、上記の通りの結果です。moode、volumioのどちらも再生エンジンはmpdベースだと思います。
ということは、DSD再生において、dop yesを指定し、
audio_output_formatを指定しないと、dop変換されたデータがキツネに送り出され、
audio_output_format "*:32:*"を指定すると、nativeのままのデータが送信される。
一方、キツネは、
dopデータを受けると「176Kと表示し、音は出ない」、
nativeデータを受けると「352Kと表示し、音は出る」
ということのようです。
パパリウスさん or donuts.shop73さん、この推論が正しいかソースコードから検証していただけますか。

面白いのは一つ前のメッセージに書いたように、Windows JRIVERのmc20でのDSD再生では、「DSD64Xと表示され、音が出る」ことです。これはWindowsだから、こうなるということでは無く、X-SPDF2のHDMI出力だとこのように表示されるということになります。何故かは、キツネとX-SPDF2の振る舞いの問題で、謎です。

また、audio_output_format "176400:24:*"で音が出たのは本当に172KPCMに変換されたデータを受けたので、その通り表示し、再生したということだと思います。

HDMI接続でdopデータを受けた場合の処理についていうと、どう処理するかという取り決めはあるのでしょうか。HDMI接続というのは、DSD再生についていうと、nativeデータのやり取りのための方式と考えるのが常識的なので、それ以外のデータが来たら、キツネはビックリして逃げ出すというのも、あながち間違っているとは言えないような気もします。

Windows JRIVERのmc20でのDSD再生で、dopとnativeでほとんど音の差を感じ無かったことと、表示がどちらもDSD64Xとなったのは、ひょっとしてX-SPDF2は全てnativeデータとしてキツネに送っているからではないのでしょうか。

rpiとの接続で音の出るDSD再生は352Kと表示されるが、実際はnativeデータと考えると、SMPDでの音切れが頻発することは問題だということになります。実際、moodeとvolumioで試したのですが、音切れは発生していません(まだ確認は不十分ですが)。これは、テスト用のmpdでは、かなり軽減していますので、まだ改善の余地があるのかもしれません。

ちょっと確認をとる前にいろいろ勝手な推論しすぎなので、ここで止めます。御意見よろしくお願いします。

yoさん、こんばんは。

検証いただきありがとうございます。
native指定ならキツネが受け付けてくれるということがハッキリしましたね。

mpdのpipeアウトプットプラグインをnative指定に対応させてみようと思いますので、少々お時間をください。

それで動作が良好ならば、綺麗に実装してリリースしたいと思います。

yoさん

全体的にはソフトのお話がメインなので、パパリウスさんにお任せします(笑)

1点だけ、
＞Windows JRIVERのmc20でのDSD再生で、dopとnativeでほとんど音の差を感じ無かったことと、表示がどちらもDSD64Xとなったのは、ひょっとしてX-SPDF2は全てnativeデータとしてキツネに送っているからではないのでしょうか。

X-SPDF2はHDMIの端子でDSDとPCMの切り替えをしていないようです。底面のDIPスイッチで手動で切替する仕様のようです。

そして、今キツネの仕様書を確認したのですが、HDMI入力はDoP対応していないようです。。。なので、mpdでPCMに変換するか、もしくはnative DSDで送り出すかどちらかですね。

そして、キツネは内部でDSDをPCMに変換してからD/A変換しているようです。

どうやら全部謎解き出来たようですね。


パパリウスさん

> mpdのpipeアウトプットプラグインをnative指定に対応させてみようと思いますので、少々お時間をください。

よろしくお願いします。
急ぎませんが、20日頃までに間に合うと、4名ほど幸せな人が誕生します(意味不明ですね。7月にやった会の第二回戦目でsmpd+キツネを聴こうということになっています)。


Passさん

> 底面のDIPスイッチで手動で切替する仕様のようです。

確認したらDSD nativeになっていました。

> HDMI入力はDoP対応していないようです。

従って無音というわけですね。

輸入代理店には「何で、DDCのHDMI出力だとDSD64Xと表示され、Linux=i2sだと176/352K表示になるのか。ソフト作者まで巻き込んで、切り分けるのに苦労したぞ」とイチャモンをつけてみますかね。

yoさん

残った疑問は、DSD64をsamplerate_converter "soxr high"で指定した場合に、なぜキツネでは音がでないのか？だけですね。

PCMにしか対応していないIntegrated180では再生できているので、キツネでも再生出来て良いはずですが。。。
理由が分かりません。

Passさん

> PCMにしか対応していないIntegrated180では再生できているので、キツネでも再生出来て良いはずですが。。。

Integrated180の環境で dop "yes" ですか。"no"だとすれば、辻褄はあうのですが。
dop "yes"では、samplerate_converter "soxr high"を指定しても、dop変換されるので、audio_output_format をコメントアウトするか、"*:24:*"を指定すると、dopフォーマットのデータが送信されるので、キツネでは再生できないということではないでしょうか。

ところで、キツネの仕様書というのはどこにありましたか。

iCAT(キツネの日本販売代理店)に問い合わせてみました。

残念ながら、標準の構成以外の接続での内容については確認のしようがないので、お答え出来ないという回答でした。
i2s接続に関する標準の構成というのは「Holo Audioのメーカーの推奨するSinger SU1を用いてのみ動作確認および対応のみ」ということです。rpi-to-HDMI基板などというのは論外ということになるらしいです。

Linuxについては、本音が書かれていて、面白かったです。要約し辛いので、盛大に削除しながら、長め引用しますが、「ラズパイ４用のiCAT OSを・・・・、Linuxでの規格外の仕様に対する業界コンセンサスを取るのは至難の業で、USB Audio Class3.0仕様を策定の提案も・・・DACメーカーが引き気味です。・・・Linuxカーネル自体の変更開発を伴い、ローカルルールで iCAT、Signalit、Holo で対応する事を前提に進めており、・・・。」ということです。
つまりiCAT Linuxで特化してラズパイに対応するというわけなので、一般的なサポートを期待することは難しそうですね。まあ、ベンチャーで頑張っている代理店の対応としては仕方がないかなと思います。

yoさん

＞Integrated180の環境で dop "yes" ですか。"no"だとすれば、辻褄はあうのですが。

dop "yes" 、audio_output_format "*:*:*"です。この状態で、

samplerate_converter が"internal"だとIntegrated250はDoP64表示で音が出ます。Integrated180は音が出ません。
samplerate_converter が"soxr high"だとIntegrated250は176.4k表示で音が出ます。Integrated180も音が出ます。

なので、"soxr high"の指定はPCM変換されて出力されていると判断したのですが。。。
何が違ってキツネが受けてくれないのか全く謎です。
まあ、前スレにも書いたようにI2S over HDMIは規格外の応用的な使い方なので、動かなくとも仕方はないのですが。。。


仕様書はこちらです。
https://i0.wp.com/kitsunehifi.com/wp-content/uploads/2016/07/KitsuneTuned-Edition-%E6%B3%89SpringDATASHEET-1.jpg?ssl=1" target="_blank">https://i0.wp.com/kitsunehifi.com/wp-content/uploads/2016/07/KitsuneTuned-Edition-%E6%B3%89SpringDATASHEET-1.jpg?ssl=1

Passさん

Integrated180はDSD対応無し。従ってdop/nativeどちらのDSDデータを受けても処理出来ないはずで、無音となる。Integrated250はdop/nativeどちらのDSD対応有り。従って、どちらのDSDデータを受けても、その通り処理する。
と考えれば、ご提示の結果は辻褄があっています。

つまり、dop "yes" 、audio_output_format "*:*:*"で
samplerate_converter が"internal"だと、rpi-変換基板からはdop64のデータが送信され、Integrated250はその通り処理され、Integrated180はDSD対応機能がないので、無音となる。
samplerate_converter が"soxr high"だと、rpi-変換基板からはPCM176Kに変換されたデータが送信され、どちらもその通り処理される。
ということだと思います(僕には、このあたりの機種による違いがよく分かっていませんでした^^;;;)。

次に、キツネですが
どちらも176Kと表示され、音が出ない。
です。

従って、キツネのsamplerate_converter が"soxr high"の処理が謎だということですね。

ご指摘の通りで、日本のiCATは頼りにならなさそうなので、これ以上頑張るには中国の設計者に直接質問するという手しかなさそです。どうしたものかなと考えています。

キツネの仕様、ありがとうございました。iCATのサポートに「知らないの?」と書いて、送っておきました。

yoさん

＞従って、キツネのsamplerate_converter が"soxr high"の処理が謎だということですね。

そこですね。
PCMデータを176.4k　24bitでアップサンプリングした時とDSD 64をsamplerate_converter "soxr high"で送り出した時に、どういった違いがあるのかが分かれば、キツネがなぜ音を出せないのかも分かりそうですが。。。

逆にそこが分からないと、代理店やキツネの設計者に質問しても、また「答えられない」と回答されそうですよね。

Passさん、パパリウスさん

さらに謎を深めるのが
audio_output_format "176400:24:*"
だとキツネは鳴ることです。
samplerate_converter が"soxr high"の有無にかかわらず音は出ます。176Kと表示されます。
要するに、この場合は、176Kに変換されたPCMを再生出来るらしいです。

ところで、apuを2台使って、lightMPD upnpgwをタンデム構成(バックエンド機はapu2なので、最新版v1.20を適用)を試してみました。当然、usb接続となりますので、x-spdi2を間に入れて、i2s接続します。
この場合、Windowsソフトを使ったusb接続と同じことになります。結果も同じで、DSD64Xと表示され、音も出ます。この音が素晴らしいです。
どうも、このDSD64Xと表示されないとまずいようです。

実は、iCATとやりとりして、rpi to HDMI変換基板直接という普通はあり得ない接続形態で使っていることがお互いに理解出来て、ようやく話が通じるようになりました。

それで、iCATから指摘されたのはこの情報です。
http://nw-electric.way-nifty.com/blog/2019/02/mpd-f63f.html" target="_blank">http://nw-electric.way-nifty.com/blog/2019/02/mpd-f63f.html
たかじんさんの記事ですが、どうも352Kと表示されるのはこの件と関連しそうですね。
つまり、ネーティブ再生でなく、PCM352Kに変換されたデータを再生しているようです。
ただ、Integratedについては最大256Kということですので、そのあたり、どうなっているのか、分かりますか。


というわけで、iCATサポートにアプローチという方法で問題解決出来そうなので、dop再生の問題についても質問してみるつもりです。

yoさん

352kはPCMとして認識して音が出ていたんですね。
Integrated250はこの状態ではNoLockのままで音が出ませんでした。
ただし、PCMを352.8kにアップサンプリングしてもロックが不安定で音が出ないので、ケーブルの問題が大きいかもしれません。

audio_output_format "176400:24:*"も試してみました。Integrated250、180ともにノイズ混じりの再生になります。
表示は176.4Kなので、PCMで認識しているようですが、実際にはDoPのデータだと思います。なのでノイズ混じりなのではないかと思います。

DoPマーカー付け忘れですか。。。

iCATサポートより、以下の通りご連絡がありました。
---------------------------------------
申し訳ありませんが、SP2はI2SでDoPをサポートしていないことが判明しました。

Spring2 don’t support DOP at I2S. Spring1 does. Because we
haven’t seen any requirement at that time. All I2S source seems can
decode DOP by itself and output DSD to Spring1. So I just cancelled this
function in Spring2.
---------------------------------------
英文のIというのはPoloの社長さんです。つまりSpring1ではDoPをサポートしていたけれど、Spring2では社長判断でサポートを止めた。理由は I2S over HDMI でDoPデータは全てnativeに変換されて送られているからということです。
確かにSU1もX-SPDIF2も変換して、送っているようです。
つまり、rpi to HDMI基板--HDMIケーブル--DAC というのはかなり特殊な接続形態で、普通のオーディオメーカーが考慮する接続形態ではないということです。

ということで、rpi to キツネDAC i2s HDMI接続 の二件の問題は解決です。
一つ目 352K表示 の件はMPDのバグで実際にその通りPCM変換されたデータが送信されていた
二つ目 176K表示、音が出ない の件はキツネDACがDoPデータを処理しない仕様だから
という結論でした。

分かってみると、なんだですね。

yoさん

v0.8.32のカーネルの差し替えによってsamplerate_converter "soxr high"を指定してもIntegrated180で再生できなくなりました。
どうやらsamplerate_converterの指定に関係なくDoP出力になっているようです。

パパリウスさんがnative再生に対応してくれるそうなので、気長に待ちましょう。

Passさん、パパリウスさん

今回よく分かったのはDSD再生についてはまだまだ発展途上で、PCM再生のようなきちんとしたルールがまだ確立していなということですね。SMPDだけのことを言っているのではなくて、LinuxあるいはWindowsを含めてPCを使ったDSD再生全般について言えることだと思います。

まあ、SMPDも0.833となり、PCM再生については奥義を究めたという感じですから、DSD再生もよろしくお願いしますというところですかね。

アナログフィルターを通せばDSDはアナログ変換出来るので、シミュレーションしてみました。

アナログで13タップFIR＋3次LPFまでやってみましたが、まだまだな感じです。やなさんのDSD原理基板は32タップっていうのもうなずけますね。。。キツネはどこまでやってるんでしょう？

PCMをNOS＋アナログフィルターで復調すると同じ位大掛かりになるんでしょうね。。。大掛かり過ぎて実際に作ってみようという気には全くなりません(笑)

NOS　マルチビットDACということで、20kHzの正弦波を44.1kHzでPCMサンプリングして、NOSマルチビットでD/Aコンバートして復調してみました。

http://mimizukobo.sakura.ne.jp/upload/20Hz_44.1k" target="_blank">http://mimizukobo.sakura.ne.jp/upload/20Hz_44.1k sampling.jpg

6d、9d、12dはそれぞれ6次、9次、12次のアナログフィルター通過後です。


どうしても入力波形とサンプリングがタイミングが合わない事象が発生してしまい、周期的に元波形から大きく崩れてしまうようです。

仕方が無いので96kHzでもやってみました。

http://mimizukobo.sakura.ne.jp/upload/20kHz_96k%20sampling.jpg" target="_blank">http://mimizukobo.sakura.ne.jp/upload/20kHz_96k%20sampling.jpg

これならほぼ元波形を復元できるみたいです。試しに48kHzでは44.1kHzと大きく変化なし。88.2kHzは96kHzと大きく変化はありませんでした。
それでもアナログフィルターは9次はないと歪だらけです。

Passさん

おサルに分かるように教えて下さいませ。
この実験の意味ですが、「96Khz以上のサンプリングデータであれば、NOSマルチビットでD/Aコンバートは9次以上のアナログフィルターを使えば何とか実現出来るが、48KHz以下では、単純な技術では出来ないよ」という意味ですか。つまり、何か特別のノウハウが無いと出来ないという意味ですか。

yoさん

daoutの波形で見比べて頂くと分かりやすいと思います。これがマルチビットDACの出力波形です。
44.1kサンプリングの方はとても元波形を復元できる状態の波形じゃないですよね。

44.1k下のサンプリング周波数のデータでも、低い帯域なら問題ありません。１kHz正弦波のサンプリングです。

http://mimizukobo.sakura.ne.jp/upload/1kHz_44.1k%20sampling.jpg" target="_blank">http://mimizukobo.sakura.ne.jp/upload/1kHz_44.1k%20sampling.jpg

高次のフィルターでなくとも、もっと低い周波数からカットオフすれば波形を丸める事は出来るのですが、そうすると高域のレベル（音量）が低下してしまいますし、ハイレゾ音源再生でも20kHz以上の高域が出なくなってしまいます。

この点はデジタルでアップサンプリングしてしまうΔΣの方がアナログフィルターも簡易的なもので済んで、ハイレゾ対応も柔軟で有利になるんでしょうかね。
今度は高周波ノイズとの戦いになりますけど。。。

ついでに比較しやすいように入力波形とサンプリングの画像を重ねてみました。（茶色とピンクの波形）
真ん中の赤の波形が12次のアナログフィルターの出力
一番下の緑の波形は、入力波形－サンプリング波形＝量子化誤差です。（波形の大きさは同じですが、電圧の測定レンジが違いますのでご注意下さい）

１kHz　44.1kサンプリング
http://mimizukobo.sakura.ne.jp/upload/1kHz_44.1k%20sampling_2.jpg" target="_blank">http://mimizukobo.sakura.ne.jp/upload/1kHz_44.1k%20sampling_2.jpg

20kHz　44.1kサンプリング
http://mimizukobo.sakura.ne.jp/upload/20Hz_44.1k%20sampling_2.jpg" target="_blank">http://mimizukobo.sakura.ne.jp/upload/20Hz_44.1k%20sampling_2.jpg


20kHzのサンプリングは量子化誤差が大きすぎて、私の発想ではフィルターで処理しきれませんでした。
キツネはコレををどうやって処理しているのか知りたいですね。

Passさん

なるほど。こういう具合に見せてもらうと、フィルターでは高い周波数で処理出来ないことがよくわかります。まあ、20KHzは聴こえなくなくても分からないだろうけど、もう少し低い周波数だと問題でしょうね。
キツネ(というかNOSモードのあるDAC)はどうやっているのかは僕も興味があります。何か魔法のような方法があるのでしょうか。

yoさん

魔法の箱は、現在逢瀬で開発中です。しばらくお待ちください(笑)