Researching SD Card Transports

[Miska]

RPi4? NUC with SD card? Mac Mini with SD card?

 

[Miska]

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...

 

[Miska]

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.

 

[Miska]

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...

 

[Miska]

3 minutes ago, bodiebill said:

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

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

 

Likely some regular CPU since it can decode FLAC, APE, etc... Plus having a display means it has regular software.

 

[Miska]

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"?

 

[Miska]

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...

 

[Miska]

45 minutes ago, hopkins said:

Whether or not these solutions bring something to the table, is not the issue here.

 

What is then?

 

[Miska]

9 minutes ago, hopkins said:

I (once again ?) did not express myself clearly. It is not the issue in the discussion you and I were having.

 

Is there an issue?

 

Quote

Obviously, the OP is concerned about SQ.

 

And you were talking about transparency, and related to sound quality are of course measurements. So just curious about demonstration about some assumed benefits of such device and differences between different implementation approaches (Linux vs some other software, etc).

 

Since you were talking about ALSA and such, I'm curious about substantiation of such assumptions.

 

[Miska]

2 minutes ago, bodiebill said:

Regarding OS´es, the Shinrico XRK SHD20 has two to choose from (button on the rear): Linux and Android. All confirm that Linux sounds better. Android of course has more options (such as touch screen).

 

Interesting, because Android is based on Linux too. Just the software stack on top of Linux kernel is different (Java runtime, etc).