nige2000 wrote: ↑Wed May 23, 2018 11:29 am
whats the advantage of option A over just using the installed software ?
am i missing something?
We would have the source code for a working SD player with excellent sound !!
Far easier to & can enhance/modify it ourselves than write it from scratch
So, we could change the existing functionality of the software - to remove the issues we may find when we begin using it i.e. with WAV tags issues or changes needed in trying to seamlessly connect it to a good user interface as we are planning.
For instance, I thought the best scheme so far was that the SD card player worked as a dumb audio file player - just playing the first file it finds in the playlist folder & deleting it after it has finished & playing the next file in the list (if any). At the moment a lot of these steps would have to be achieved by the control software on PC/phone sending control codes to the SD player to play the file, delete the file, play the next file in the playlist, etc.
All this control logic would be better done in the software on the STM. We could strip the STM code down to go headless - removing all code for screen display, button sensing, etc
Later on, we could enhance/change the software to work on our own hardware design or do things that it currently doesn't do - maybe output other than I2S signals for other DAC inputs?
on option B its a little alarming he wants to change it so much, although i can see his point,
id be afraid of tipping the baby out with the bath water?
Well, what would you want to see in option B?
back to this internal 16mhz sck, that sort of goes against our synchronous theory?
ive two other stm sd card players not nearly as good
one with audio clks and that akm chip something like 4118 interfering for spdif?
and another with 8mhz sck with no audio clks (if i remember right very low noise)
is there no way to use audio clks as system clock?
Exactly - we thought the secret sauce for why this SD card player sounded so good was the audio clock & system clock being the same - turns out that's not how the card works so we don't really know why it sounds so good. Just doing option B or any new hardware design could well leave us with just another SD card player that sounds OK - that was the point I was making - option B is a gamble & it seems the odds are against us in getting the same great sound.
I don't see what the point is of chasing what turned out to be a false premise - the audio clock & system clock being the same? It's something we could investigate down the road but it's not the cause of the great sound of the current SD player
That's why I favour option A - getting working software on the existing hardware. If it doesn't sound as good as the existing SD player then we know the secret sauce is in the software or in the way the software is using the hardware
If we do get a solution that sounds as good as the existing SD player then any changes we make to the hardware/software can be evaluated for impact on sound. We might, for instance, change the on 1MB board memory to SLC memory - we might increase the memory size & buffer more of the SD card reading (if that's the function that the memory is being used for?). We might decide that the purist way to do this is to read all of the file off the SD card into on board SLC memory & playback from that memory instead of what seems to be currently happening - the file is being read off SD card while it is being processed to I2S
Lots to think about