SD-card player prototype is working, there are some minor problems with SD-card latency, this will be solved by doubling RAM buffer size.
SD-card access is software-driven, I2S signals are generated by the on-chip DCI module and through DMA.
The player already supports multiple directories (99) and multiple tracks within each directory (99 track / directory). Long file names can be used as well.
Shuffle play (CD / tracks) also works.
Bit clock jitter can be kept very low as expected. First impressions of sound quality are very good.
The SD-card latency limits max. sample rate and bit depth. The latency is basically caused by the on-card controller, and may vary with SD-card brand.
SD-card access is software-driven, I2S signals are generated by the on-chip DCI module and through DMA.
The player already supports multiple directories (99) and multiple tracks within each directory (99 track / directory). Long file names can be used as well.
Shuffle play (CD / tracks) also works.
Bit clock jitter can be kept very low as expected. First impressions of sound quality are very good.
The SD-card latency limits max. sample rate and bit depth. The latency is basically caused by the on-card controller, and may vary with SD-card brand.
How about user interface (display, remote, ....) ?
And when would you be offering to us ?
I have a serious interest in the frontend part, up to I2S output.
There are just too many limitations in the Koonlab version.
Pls keep us posted.
Patrick
And when would you be offering to us ?
I have a serious interest in the frontend part, up to I2S output.
There are just too many limitations in the Koonlab version.
Pls keep us posted.
Patrick
Just came across this...
http://www.compactstick.com/
it seems the only stuff being released in this format at the moment is psychedelic trance, however it will be interesting to see if this becomes more widely adopted.
There is specification for the filesystem layout here:
http://www.compactstick.com/cs_contents_v10.pdf
http://www.compactstick.com/
it seems the only stuff being released in this format at the moment is psychedelic trance, however it will be interesting to see if this becomes more widely adopted.
There is specification for the filesystem layout here:
http://www.compactstick.com/cs_contents_v10.pdf
Could a Squeexebox be used to output I2S?
If so, it will handle FLAC no problem?
Whilst the media os not solid state, has no mechanical and servo parts which I think is the point of this thread??
Ian
If so, it will handle FLAC no problem?
Whilst the media os not solid state, has no mechanical and servo parts which I think is the point of this thread??
Ian
ecdesigns, are you planning an electronic control (user) interface of some kind? This would make it a very useful module for other projects.
There are a ton of cheap transflash and sd players (also mp4 video) from china around for between $20 - $35. Do you think any of these would be hackable for i2s or some kind of digital output?
There are a ton of cheap transflash and sd players (also mp4 video) from china around for between $20 - $35. Do you think any of these would be hackable for i2s or some kind of digital output?
regarding hardware design
ecdesigns,
It would be very useful to buffer both the clock signals
going to the dac and dsp, as changes in the impedances
or pll pulling (if that happens in the internal circuitry)
will cause some jitter. It will be a pity to loose the
clean clock to this.
Also, make sure all impedances are matched as far as
you can from chip pin to external circuitry.
Looking forward to the final thing!
ecdesigns,
It would be very useful to buffer both the clock signals
going to the dac and dsp, as changes in the impedances
or pll pulling (if that happens in the internal circuitry)
will cause some jitter. It will be a pity to loose the
clean clock to this.
Also, make sure all impedances are matched as far as
you can from chip pin to external circuitry.
Looking forward to the final thing!
Hi git,
The prototype is built around a Microchip DV164027 MPLAB debugger module:
http://nl.farnell.com/microchip/dv1...odule-w-dm300027/dp/1439838?_requestid=734245
We added a SD-card holder, an external 2.8224 MHz low jitter clock, and a stereo DAC for testing.
The microcontroller is a DSPIC33FJ128GP802.
I try to make and post some photographs of the test set-up soon.
The prototype is built around a Microchip DV164027 MPLAB debugger module:
http://nl.farnell.com/microchip/dv1...odule-w-dm300027/dp/1439838?_requestid=734245
We added a SD-card holder, an external 2.8224 MHz low jitter clock, and a stereo DAC for testing.
The microcontroller is a DSPIC33FJ128GP802.
I try to make and post some photographs of the test set-up soon.
John,
I hope you would offer a dedicated board before long.
I like your designs, not only this one but also your TDA154x DACs, especially the linear interpolation. Innovative stuff, as one often finds in designs coming from the Netherlands.
😉
Patrick
I hope you would offer a dedicated board before long.
I like your designs, not only this one but also your TDA154x DACs, especially the linear interpolation. Innovative stuff, as one often finds in designs coming from the Netherlands.
😉
Patrick
Hi EUVL
At the moment the prototype is controlled by a serial interface (for testing), so no keyboard or display yet.
We plan to use two double blue 7-segments LED displays.
The first display shows the CD number (1 ... 99), the second shows the track number (1 ... 99). These displays are also used for other information like shuffle play, and SD-card number.
There will be two keys for CD selection (- / +), two keys for track selection (- / +), a key for stop, and a key for play / pause.
The player will also have a serial communications channel, it can be used for remote-control functions.
But first we need to have a version that runs on most SD-cards (even the slower one's) without causing drop-outs.
In order to achieve this, we plan to use Philips I2S interface with 32 bits / frame (2 x 16 bits). This will double the effective RAM ping-pong buffer size to 1 K byte.
How about user interface (display, remote, ....) ?
And when would you be offering to us ?
At the moment the prototype is controlled by a serial interface (for testing), so no keyboard or display yet.
We plan to use two double blue 7-segments LED displays.
The first display shows the CD number (1 ... 99), the second shows the track number (1 ... 99). These displays are also used for other information like shuffle play, and SD-card number.
There will be two keys for CD selection (- / +), two keys for track selection (- / +), a key for stop, and a key for play / pause.
The player will also have a serial communications channel, it can be used for remote-control functions.
But first we need to have a version that runs on most SD-cards (even the slower one's) without causing drop-outs.
In order to achieve this, we plan to use Philips I2S interface with 32 bits / frame (2 x 16 bits). This will double the effective RAM ping-pong buffer size to 1 K byte.
John,
I think SD cards will only get larger and faster, so there is perhaps not much point in trying to support the smallest and slowest ones.
The proposed operating keys are sufficient for a minialistic player, but IMHO a 2x8 VFD display or blue LED dot matrix (probably not available ?) is perhaps better if playing time can be displayed. Or is it a limitation of the dsPIC ?
And how about fast forwards and backwards within the same sound track ?
Are USB-sticks an alternative to SD cards ?
Pls keep us posted.
Thx,
Patrick
I think SD cards will only get larger and faster, so there is perhaps not much point in trying to support the smallest and slowest ones.
The proposed operating keys are sufficient for a minialistic player, but IMHO a 2x8 VFD display or blue LED dot matrix (probably not available ?) is perhaps better if playing time can be displayed. Or is it a limitation of the dsPIC ?
And how about fast forwards and backwards within the same sound track ?
Are USB-sticks an alternative to SD cards ?
Pls keep us posted.
Thx,
Patrick
Hi EUVL,
The display will produce interference, the main objective is best possible 44.1/16 playback imaginable, meaning extreme low interference levels and extreme low master clock jitter.
However, the integrated RS232 communications channel can be used to control and read SD-card player status. The serial interface will have to use optical interface (with PC) in order to completely avoid ground loops, we are planning to use 2 x Toslink for this. If desired, artist name, Album and artwork can be displayed on a connected computer.
I attached a photograph of the SD-card player prototype (before improvement). Turned out that the drop-outs were caused by both the SPI clock frequency and long wires running to the SD-card.
The SD-card prototype is now modified (much shorter wires), and now it plays flawlessly for hours.
Although it was not causing the problem, I2S format is now 32 bits/frame, and the bit clock equals 1.4112 MHz.
This isn't implemented yet, might be added later if it doesn't affect performance in any way.
The proposed operating keys are sufficient for a minialistic player, but IMHO a 2x8 VFD display or blue LED dot matrix (probably not available ?) is perhaps better if playing time can be displayed. Or is it a limitation of the dsPIC ?
The display will produce interference, the main objective is best possible 44.1/16 playback imaginable, meaning extreme low interference levels and extreme low master clock jitter.
However, the integrated RS232 communications channel can be used to control and read SD-card player status. The serial interface will have to use optical interface (with PC) in order to completely avoid ground loops, we are planning to use 2 x Toslink for this. If desired, artist name, Album and artwork can be displayed on a connected computer.
I attached a photograph of the SD-card player prototype (before improvement). Turned out that the drop-outs were caused by both the SPI clock frequency and long wires running to the SD-card.

The SD-card prototype is now modified (much shorter wires), and now it plays flawlessly for hours.
Although it was not causing the problem, I2S format is now 32 bits/frame, and the bit clock equals 1.4112 MHz.
And how about fast forwards and backwards within the same sound track ?
This isn't implemented yet, might be added later if it doesn't affect performance in any way.
Attachments
Looks good. Thanks for the photos.
> the main objective is best possible 44.1/16 playback imaginable, meaning extreme low interference levels and extreme low master clock jitter.
Could not agree more.
Patrick
> the main objective is best possible 44.1/16 playback imaginable, meaning extreme low interference levels and extreme low master clock jitter.
Could not agree more.
Patrick
Hello John
Have you try those mp3/wav players that has a digital out and used SD card ?
Like the iRiver iHP-120.
I was thinking of using a player like that, using it with a non-os TDA1541A dac, but it maby less good since it is SPDIF.
Bye
Gaetan
Have you try those mp3/wav players that has a digital out and used SD card ?
Like the iRiver iHP-120.
I was thinking of using a player like that, using it with a non-os TDA1541A dac, but it maby less good since it is SPDIF.
Bye
Gaetan
Hi UV101,
Yes, I already tried this using an older model squeezebox, it required some glue logic though. I attached a photograph showing the tapped I2S signals from the SB being connected to a DI16 DAC (16 x TDA1543).
One problem is the network connection that introduces an ac ground-loop, the other is the high jitter produced by the squeezebox on-board master clock, so some more mods are required. There is also the ground-loop introduced by connecting the DAC (with built-in power supply) to the squeezebox (with built-in power supply). Finally It required a computer, running the Slimserver database.
I often had problems with the squeezebox player connecting to the database as well, this was very annoying. With increasing amount of stored CD images, it also became increasingly difficult to locate the desired CD / track, using the SB user interface, so finally I stopped using it.
Next I started using the mac with iTunes, now music was much easier to access. I started with an USB audio interface, but the galvanic connection created a ground-loop, and sound quality wasn't satisfying. So I built-in opto-couplers (before reclocking) in order to interrupt the ground loop. This produced slightly better results, but still wasn't optimal.
Then I switched to Toslink, first using an analogue PLL driving a VCXO master clock. This was later replaced by a micro controller-based VCXO FLL that synchronously reclocks the source timing signals. Problem was, my CD player produced better sound quality (Toslink) than the Toslink output on my mac. The problem seemed to be solved when I started using the Airport Express mini Toslink output (fixed 44.1/16).
As DAC sound quality kept improving, due to modifications, this option also didn't seem to be perfect. The audible differences between both CD player digital output and AE digital output kept increasing with DAC performance.
That was the time I started looking for a better solution (perfect digital audio source) that should solve these "issues" once and for all. This lead to SD-card player development.
The point is to create an (almost) perfect digital audio source that is as compact as possible, consumes as little power as possible, provides extreme low masterclock jitter, I2S output, and lowest possible interference levels. In order to eliminate ac ground loops, no galvanic or capacitively-coupled interlinks to any (computer) equipment is allowed. Wireless communication like WLAN is not an option either, as it causes significant EM interference.
Could a Squeexebox be used to output I2S?
Yes, I already tried this using an older model squeezebox, it required some glue logic though. I attached a photograph showing the tapped I2S signals from the SB being connected to a DI16 DAC (16 x TDA1543).
One problem is the network connection that introduces an ac ground-loop, the other is the high jitter produced by the squeezebox on-board master clock, so some more mods are required. There is also the ground-loop introduced by connecting the DAC (with built-in power supply) to the squeezebox (with built-in power supply). Finally It required a computer, running the Slimserver database.
I often had problems with the squeezebox player connecting to the database as well, this was very annoying. With increasing amount of stored CD images, it also became increasingly difficult to locate the desired CD / track, using the SB user interface, so finally I stopped using it.
Next I started using the mac with iTunes, now music was much easier to access. I started with an USB audio interface, but the galvanic connection created a ground-loop, and sound quality wasn't satisfying. So I built-in opto-couplers (before reclocking) in order to interrupt the ground loop. This produced slightly better results, but still wasn't optimal.
Then I switched to Toslink, first using an analogue PLL driving a VCXO master clock. This was later replaced by a micro controller-based VCXO FLL that synchronously reclocks the source timing signals. Problem was, my CD player produced better sound quality (Toslink) than the Toslink output on my mac. The problem seemed to be solved when I started using the Airport Express mini Toslink output (fixed 44.1/16).
As DAC sound quality kept improving, due to modifications, this option also didn't seem to be perfect. The audible differences between both CD player digital output and AE digital output kept increasing with DAC performance.
That was the time I started looking for a better solution (perfect digital audio source) that should solve these "issues" once and for all. This lead to SD-card player development.
Whilst the media os not solid state, has no mechanical and servo parts which I think is the point of this thread??
The point is to create an (almost) perfect digital audio source that is as compact as possible, consumes as little power as possible, provides extreme low masterclock jitter, I2S output, and lowest possible interference levels. In order to eliminate ac ground loops, no galvanic or capacitively-coupled interlinks to any (computer) equipment is allowed. Wireless communication like WLAN is not an option either, as it causes significant EM interference.
Attachments
Significant even through metal shielding?-ecdesigns- said:Wireless communication like WLAN is not an option either, as it causes significant EM interference.
Perhaps you should have tried a "quality" Toslink output as it is used on pro-soundcards
My current preference:
As you know I use an optical USB Cable from Opticis (USB 1.1 only) for galvanical isolation.
The receiver is "custom-made" battery powered. This made a great improvement
with your USB reclocker/receiver I used to use.
My current preference:
As you know I use an optical USB Cable from Opticis (USB 1.1 only) for galvanical isolation.
The receiver is "custom-made" battery powered. This made a great improvement
with your USB reclocker/receiver I used to use.
-ecdesigns- said:
...One problem is the network connection that introduces an ac ground-loop ...
By AC ground loop do you mean the coupling via ethernet isolation transformers?
- Status
- Not open for further replies.
- Home
- Source & Line
- Digital Source
- Lossless SD-card player