Jump to content
IGNORED

Researching SD Card Transports


Recommended Posts

I had a fellow audiophile over the other day and we listened to my speakers with his SDTrans384.  I was shall we say very interested.  I have started a little research project to try to identify SD card transports available in 2021.

 

Here is my list so far:

 

https://shenzhenaudio.com/products/hxmelody-hx500-digital-turntable-player-lossless-pcm768k-dsd1024-dst-direct-solution-player?variant=33557600403588

 

http://www.tachyon.co.jp/~sichoya/SDTrans/SDTrans6.html

 

https://soundaware.aliexpress.com/store/3548007

 

https://primeaudio.org/aune-x5s-review-6th-anniversary-edition/

 

https://hifigo.com/collections/aune/products/aune-x5s-8th-anniversary-edition-headphone-amplifier

 

 

Anyone with reviews, news, love, hate, etc?  Used gear for sale?

 

Bob

 

NOTE:  I FULLY understand the UX of the SD card experience. I am really only looking for SD to AES or SPDIF. 

 

 

Link to comment

Resonessence Invicta and Mirus DACs have built in SD card transport.  Really designed as an integrated solution, but I believe can output digital on Toslink if you really want to (Not tried myself) .

 

Company went out of business last year, but generally always a few s/h if you look hard (and likely relatively cheap now) and is still a very good DAC.

 

 

Link to comment

@gstew and @tapatrick are the experts for sure, at least two more candidates were discussed on tirnahifi.org and here's the first one

 

https://audiophilestyle.com/forums/topic/24966-ecdesigns/page/87/?tab=comments#comment-1147423

 

The second one (i.e. SD3.75 transport) from the same tirnahifi.org thread

 

https://item.taobao.com/item.htm?id=601209239990

https://www.aliexpress.com/item/4000196295448.html

https://www.aliexpress.com/item/4000413900271.html

https://www.aliexpress.com/item/4000764535296.html

 

Obviously the first one wouldn't work out of the box, some DIY skills are required for converting I²S into either AES or S/PDIF.

 

OTOH, check this out and it could very well be yet another avenue to explore

 

https://www.diyaudio.com/forums/pc-based/329911-getting-allo-coms-katana-dac-40.html#post5945670

 

When it comes to the performance of transports that are based on the RPi / CM3 / CM4 platform, it largely depends on minimizing the footprint of the Linux distro while stripping the kernel WAY down. Other than that, we just need to go for the best carrier board available for CM4 and this particular one is created by the same seller of SD3.75 transport as I mentioned before

 

https://item.taobao.com/item.htm?id=643286972960

https://www.aliexpress.com/item/4000906750017.html

https://www.aliexpress.com/item/1005002583268413.html

https://www.aliexpress.com/item/1005002583442098.html

https://www.aliexpress.com/item/1005002846039806.html

 

Fortunately it's easy to find a SuperSlim distro that's totally tricked out and ready to go for CM4

 

https://github.com/sam0402/pcp-44.1KHz

https://www.stsd99.com/phpBB3/viewtopic.php?p=19950#p19950

 

Then we just add this from the seller of SD3.75 transport afterwards

 

https://item.taobao.com/item.htm?id=636388022226

https://item.taobao.com/item.htm?id=637015014400

https://www.aliexpress.com/item/1005002086574264.html

https://www.aliexpress.com/item/1005002211136533.html

https://www.aliexpress.com/item/1005002687681407.html

https://www.aliexpress.com/item/1005002846164130.html

https://www.aliexpress.com/item/1005002990993180.html

 


 

However, there's still something else that's WAY simpler than everything listed above

 

http://www.qlshifi.com/en/wzcapi/qa390.htm

 

All we need is a single 12V rail of DC4 ARC6 (with Mundorf SGW115) for powering the entire package

 

https://www.head-fi.org/threads/chord-electronics-dave.766517/page-1172#post-16461095

https://audiophilestyle.com/forums/topic/30376-a-novel-way-to-massively-improve-the-sq-of-computer-audio-streaming/page/719/?tab=comments#comment-1147143

 

Just get whole bunch of SLC SD cards and it's a done deal.

Link to comment

The FPGA based devices have virtually (some assumptions on my part no unnecessary overhead, hardware,software,etc. 

 

An example of this is:

 

There is a LOT of hardware there to get the noise down.  It is great looking and very interesting to think about.  You can select different clocks in board,  A lot do and look at.

 

I am really looking for something "simpler". Think CD transport for SD cards.  

 

Link to comment

The SDTrans does not use a Linux operating system, but runs on a microcontroller which has been programmed to perform a limited set of functions. It only reads WAV files. A similar approach was implemented in ECDesigns UPL. I don't know of other "players" that have been build from the ground up like these two. 

 

On the other hand, stripping down a Linux system (or Windows or Mac) is not going to get you as far towards "minimalism". With Linux, you'll still be running Alsa for audio, and that's a big and complex  "black box". 

 

If you see SD card players advertised as playing other formats than WAV, such as Flac, chances are they are running Linux, and are probably using a standard card like a RaspberryPi. I doubt anyone has programmed from scratch a Flac decompression algorithm on a microprocessor but I could be wrong. 

Link to comment
1 hour ago, bobfa said:

The FPGA based devices have virtually (some assumptions on my part no unnecessary overhead, hardware,software,etc. 

 

An example of this is:

 

There is a LOT of hardware there to get the noise down.  It is great looking and very interesting to think about.  You can select different clocks in board,  A lot do and look at.

 

I am really looking for something "simpler". Think CD transport for SD cards.  

 

 

That's based on RPi...

 

FPGA devices certainly have "software". But in any case, if you have SD card with normal filesystem and files - you need software to read it, decode file contents etc. No matter how you call the "software", it is there.

 

CD is much simpler, but it also needs software to deal with the contents. It may be less "visible" to you though. And being fixed standard you usually cannot update it etc. Although newer players that can play Bluray etc, based on Mediatek chipset or similar, typically run Linux as OS.

 

 

P.S. You can run Linux on FPGA too...

 

Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Link to comment
2 minutes ago, hopkins said:

With Linux, you'll still be running Alsa for audio, and that's a big and complex  "black box". 

 

Where is it "black box"? You have all the source code! I have done quite a lot of work on ALSA. Although using ALSA is not necessary, you can do it other ways too. And it is not particularly complex, it is pretty straightforward and streamlined. Actually very low overhead when used correctly.

 

Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Link to comment
12 minutes ago, Miska said:

 

Where is it "black box"? You have all the source code! I have done quite a lot of work on ALSA. Although using ALSA is not necessary, you can do it other ways too. And it is not particularly complex, it is pretty straightforward and streamlined. Actually very low overhead when used correctly.

 

 

Have you published any of this ? 

What have you used aside for ALSA? What are your recommendations for a "correct use"? Without any specifics I am a little skeptical about what you are referring to. 

 

 

 

Link to comment
1 hour ago, bobfa said:

A lot of data, thanks.  I may have opened up a can of worms for myself.

 

No problem, there's something rather obvious that I wasn't talking about in my previous reply.

 

First and foremost, front and center, the whole point of SD card players are about their I²S outputs while their AES and S/PDIF outputs should be nothing to write home about.

 

We'll feed that I²S to stuff like FifoPi Q3 Ultimate / ReClockPi / SinePi / McFifo / McDualXO and then the quality of the crystal oscillator(s) would become mission critical. And then we're bypassing all Ethernet / USB / AES / coaxial / Toslink inputs of the DAC while the reclocked I²S is fed to the DAC directly. That's the TRUE value of really simple SD card transports.

 

Heck, just take a look at how Crom managed to do his double re-clocking here

 

https://www.diyaudio.com/forums/pc-based/335881-iancanadas-rpi-gb-goodies-impressions-tweaks-mods-hints-156.html#post6494550

 

Besides, nothing would perform very well right from the get-go and SDTrans384 ain't getting THAT far until all regulators are bypassed

 

https://noblyn.at.webry.info/201405/article_2.html

http://toukiyakoneko.web.fc2.com/SDTrans384_with_Ultra_Low_Noise_Power_Supply-V1.0.0.pdf#page=4

https://www.diyaudio.com/forums/digital-source/142562-microsd-memory-card-transport-project-103.html#post5692194

 


 

Depending on how much simpler we'd like to get, one of those Sony 4K Ultra HD Blu-ray players (e.g. UBP-X700 / UBP-X800 / UBP-X1000ES / UBP-X1100ES etc.) could do so much better as soon as the SMPS is replaced by much better DC 12V rail(s)

 

http://www.stsd99.com/phpBB3/viewtopic.php?p=18978#p18978

http://www.stsd99.com/audio/changedc01.jpg

http://www.stsd99.com/audio/changedc02.jpg

http://www.stsd99.com/audio/changedc03.jpg

http://www.stsd99.com/audio/changedc04.jpg

http://www.stsd99.com/audio/changedc05.jpg

 

And then convert HDMI audio into I²S output just like this, there's a specific seller on Tao Bao who made a package with better clocks (1,800 RMB) and obviously we could also do something similar to that one

 

https://www.ebay.com/itm/124448887818

https://www.ebay.com/itm/363228674748

https://item.taobao.com/item.htm?id=530846802496

https://forum.psaudio.com/t/getting-oppo-dsd-output-to-the-direct-stream-dac/2744/250

https://forum.psaudio.com/t/it-works-sony-ubp-x1000es-hdmi-audio-output-to-chinese-i2s-adapter-board-to-ds-sr-i2s-input/15630

 

HDMI audio → I²S → FifoPi Q3 Ultimate → TransportPi as shown below

 

http://www.stsd99.com/phpBB3/viewtopic.php?p=18771#p18771

 

Of course we'll play lossless music files off USB drives after they're plugged into one of those players from Sony.

Link to comment
12 minutes ago, hopkins said:

Have you published any of this ? 

 

Of course.

 

13 minutes ago, hopkins said:

What have you used aside for ALSA?

 

So far OSS, ALSA and my custom interface on Linux. And then WMM, WASAPI and ASIO on Windows. And CoreAudio on macOS. And some more esoteric things like the BeOS interface and such.

 

14 minutes ago, hopkins said:

What are your recommendations for a "correct use"?

 

Direct "hw" devices, like used by HQPlayer.

 

15 minutes ago, hopkins said:

Without any specifics I am a little skeptical about what you are referring to.

 

I've worked quite a while on Linux audio, for example you can look at my code on Jack Audio Server almost 20 years ago...

 

Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Link to comment

Looking to replace my SDTrans384 that recently died on me...

I was ogling Shinrico SHD20 and D7, but also noticed this -- just out I believe and also FPGA based:

http://www.musician-audio.com/en/col.jsp?id=124

Given my good experience with the Musician Pegasus DAC I am tempted...

 

I do play into a Mutec reclocker now which makes a noticeable positive difference. This does not accept I2S, so I would use AES for that. Which I could compare to I2S direct into the Pegasus without reclocking.

 

audio system

 

Link to comment

I maybe need to shrink this down a bit.  My speakers; the HeavelySoundworks 517 run Ncore hardware and have AES/SPDIF/TOSLINK and analog inputs.   When my friend brought over his SDTrans384 and we hooked it up to the system I was surprised to say the lease.

 

I am very interested in something that will do AES or SPDIF out from SD cards and not have all the overhead of other things.  Right now my SPDIF connection is hooked up to an Aurender.  

 

The I2S stuff is out of scope for me, but really interesting!.

 

RJF

 

Link to comment

I guess waiving the CPU is problematic. The few devices that do that (SDTrans384 and ECdesigns UPL96) I found to be somewhat cumbersome. My main objectives in using a minimal stand-alone transport are SQ related:

(1) waive usb

(2) waive network

(3) optimize output format depending on DDC/DAC used

(4) minimize footprint (CPU activity) without being totally user unfriendly -- perhaps the hardest one

 

audio system

 

Link to comment
Link to comment
7 hours ago, Miska said:

So far OSS, ALSA and my custom interface on Linux.

 

What I referred to as "published" was the source code. I assume your custom interface on Linux is not freely available. You are a vendor, selling a product.. 

 

There is little "transparency" about some of  these products (not necessarily referring to yours).

 

Having an SD card in itself is no guarantee that the solution will be in any way similar to the SDTrans. I seriously doubt a public OS based solution is going to be comparable. 

 

Link to comment
7 hours ago, bobfa said:

 

Thanks for the research! The choice becomes harder...

 

I am a bit confused about the world clock connections: on the Aune X5S and QA661 it says external clock input and on the QA661 and AliExpress device it says world clock output.

Do these indeed have different functionality? How to use these with f.i. with a Mutec reclocker?

 

The AliExpress one probably has the lowest footprint (closer to SDTrans384), adds LVDS/HDMI I2S output, and I like that it can be fed with a good 6-12 VDC LPS of choice.

 

audio system

 

Link to comment
2 hours ago, hopkins said:

What I referred to as "published" was the source code. I assume your custom interface on Linux is not freely available. You are a vendor, selling a product.. 

 

All kernel source code I have is available as required by kernel's GPLv2 license. Most patches have been upstreamed though and are part of official Linux kernel source tree already.

 

I'm selling music playback/recording/conversion software and custom DSP algorithms. Not Linux or hardware. In the past I used to work for example for Nokia (on Linux OS for mobile devices) and Intel (on Linux running on Intel's hardware).

 

2 hours ago, hopkins said:

There is little "transparency" about some of  these products (not necessarily referring to yours).

 

Having an SD card in itself is no guarantee that the solution will be in any way similar to the SDTrans. I seriously doubt a public OS based solution is going to be comparable.

 

Haha, so making some "black box" solution is better than using "public OS"?

 

Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Link to comment
12 minutes ago, Miska said:

Haha, so making some "black box" solution is better than using "public OS"?

 

You are being a smart-ass, but we both know exactly what I meant. A lot of manufacturers of these so-called "SD card" players are not transparent about the solution they implement. If the OP is looking for something similar to an SDTrans384, he should be aware of this. 

 

Whether taking a raspberryPi and a linux distribution and using standard Linux programs to decode audio, and play it from an SD card is going to be better than having a microprocessor with a very small instruction set dedicated to audio - that's for everyone to decide. I am just highlighting the differences. Obviously, you are here to sell your own solution, and that's fine (send me the link to your "custom linux interface" source code, I'd be curious to see exactly what you are talking about, and we can continue this offline). I'm not in the market for any of this, so I really don't care either way, but once again, you cannot compare apples and oranges.

Link to comment
2 minutes ago, hopkins said:

You are being a smart-ass, but we both know exactly what I meant. A lot of manufacturers of these so-called "SD card" players are not transparent about the solution they implement. If the OP is looking for something similar to an SDTrans384, he should be aware of this.

 

Yes, that's why I said that if the device reads files from SDcard, it is invariably a software solution in first place. One way or the other.

 

Then if such device is supposed to improve over something else, next level of transparency I'd ask is measurement results that demonstrate it. So far I didn't find such yet...

 

Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Link to comment
1 minute ago, Miska said:

 

Yes, that's why I said that if the device reads files from SDcard, it is invariably a software solution in first place. One way or the other.

 

Then if such device is supposed to improve over something else, next level of transparency I'd ask is measurement results that demonstrate it. So far I didn't find such yet...

 

 

No, it's not only a software solution, as the hardware is different as well.

 

Whether or not these solutions bring something to the table, is not the issue here. If you don't believe they do (based on measurements, or listening, or whatever), then you don't need to contribute in this thread.

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...