Tír Na HiFi

No intimation of perfection.

AS Salvador Dali told us: "Do not fear perfection, you will never realize it"

I meant as long as I am this happy I will drag it out a little while longer. When my ears have completely figured out the puzzle and find it lacking I will give them something new to work on.

I mean, give me, at least, until this weekend, Nigel!

lol
only making jokes :)

only delaying the inevitable

jrling wrote:Actually what made me think it might be available was this line in nige's £75 Chinese player in a box -

Under SD card with the firmware update function, we released Firmware APP.bin directory on the SD card, boot update, the update takes only 1-2 seconds, firmware deleted without deleting not affected.

So that inferred they would supply firmware for updating.

HOWEVER, that almost certainly is compiled executable not the source code. But thought I would ask.

Code for a FPGA is no different in concept from any other computer player code. Written in various languages and compiled to an executable which cannot be read.

Actually, it could make very good biz sense. If there was an ability to improve the code, then it could create an audiophile following much as the Soekris has.

Rick - the code for the SDTrans is very custom for that board. I doubt it even uses the same FPGA chip as nige's. So rest easy!

Jonathan

Jonathan,

Agreed that the FPGA code is compiled machine code or equivalent... but having been a mainframe assembly language programmer from the late '70s through the early '90s, that can be read and manipulated with some effort (you don't want to know how many dumps I've had to read!).

Also, during the cMP/cPlay XP-slimdown craze, people were using tools to modify executables to take out un-needed sections and make them smaller...

So it can be done with the EBay reader, if only from a reverse-engineering perspective. Maybe stripping out the code for all of the formats we wouldn't use would be useful?

Just a thought... hoping mine arrives soon!

Greg in Mississippi

P.S. For some insight to what one can do with careful code-optimization, read some of the posts by Ted Smith on the PS Audio forum on some of the work he did in getting better sound out of that DAC on later firmware releases.

Interesting and thanks.

'Ebay reader'??

Apart from stripping code not being used, which is probably not that much, I had in mind possibly improving the actually rendering code. We have seen what can be done in MQn and WTFPlay that makes such a difference to the SQ. The code in the FPGA must be doing a render loop being fed from a buffer and outputting it to another buffer. I wonder if that could be optimised?

Certainly not by me, but may be by you!!

Just a thought, but probably too difficult and actually not entirely 'right' without asking the manufacturer. But there are a number of these SD card players on the market now and I wonder if they are sharing the same FPGA code.

Cheers
Jonathan

Based on Nige's pics, I'm not sure there is an FPGA on his ebay board.

Looks to be some kind of ARM processor, kind of hard to tell as "ARM" is the only thing I can read on that guy.

There is another chip that I would guess is memory, it's not a kind of package normally used for FPGAs.

Randy

randytsuch wrote:Based on Nige's pics, I'm not sure there is an FPGA on his ebay board.

Looks to be some kind of ARM processor, kind of hard to tell as "ARM" is the only thing I can read on that guy.

There is another chip that I would guess is memory, it's not a kind of package normally used for FPGAs.

Randy

Well spotted. I had just assumed FPGA.

Looking at the board, the legend says STM32F (ARM) which is as you say an MCU for embedded systems.

Interesting. I would guess actually better potential for this application than an FPGA, but over to you & Gstew for expert views.

So nige has got a different animal from SDTrans. Can't wait for a competitive match between the two.

Jonathan

randytsuch wrote:Based on Nige's pics, I'm not sure there is an FPGA on his ebay board.

Looks to be some kind of ARM processor, kind of hard to tell as "ARM" is the only thing I can read on that guy.

There is another chip that I would guess is memory, it's not a kind of package normally used for FPGAs.

Randy

Unless there is another chip or two hiding on the bottom, you are right. ARM might suggest Linux, but does not have to be that.

Maybe Nige can share more about whether the instructions listed a Firmware/Software update process... that would tell us a lot.

On the potential of someone stealing the SDTrans FPGA code, I doubt the designers are too worried... it is a device with VERY limited functionality, WAV only, limited control of playback, very hair-shirt, very specialty. I doubt they are too worried that it will be copied... no profit in it... only us 'enthusiasts' want one.

OTOH, these Chinese players are much more functional and have a much higher 'appeal'. But given the various ones that appear to be available, the firmware/SW has probably already been stolen and is out there.

Greg in Mississippi

P.S. Jonathan, thanks for the vote of confidence, but I am likely the least 'expert' of the group here!

YAY!!!! Tracking info indicates mine has made it to the shores of the USA!

Hopefully I'll have this to play with by the weekend!

Greg in Mississippi

Well spotted. I had just assumed FPGA.

Looking at the board, the legend says STM32F (ARM) which is as you say an MCU for embedded systems.

Interesting. I would guess actually better potential for this application than an FPGA, but over to you & Gstew for expert views.

So nige has got a different animal from SDTrans. Can't wait for a competitive match between the two.

Jonathan

nige - would you agree that the ARM STM32F in your born again SD card player is not an FPGA but some sort of more general CPU?

If so, I wonder if that is a better solution - to program an ARM MCU specifically for audio player - as opposed to the same conceptual code in an FPGA?

I have read that FPGAs 'fire' their gates all the time even if not being used and thus causing 'noise'.

Of course this may mean that the coding of the MCU is also different from an FPGA.

Jonathan

http://www.mouser.com/ds/2/389/DM00037051-492832.pdf
http://static.qobuz.com/info/IMG/pdf/AK4118.pdf

i haven't even read them myself yet