Some info on the world's finest portable music player, that you do not find elsewhere ...
What's wrong with this picture ? Know the answer win a Tera (just kidding ;-)
B-man enjoying early (series-0) Tera on the Koss-PortaPro.
Here's the proof: Tera is the most relaxing music player - ever
made!
Tera in the making, most components under the SD-connector. These capacitors look so simple and standard .. they ARE NOT!
Drilling the venting holes:
Below the first Tera's tactile pad ever made.
In my hand -> the very first Tera-Stealth! Background: Altmann Attraction DACs in the making.
The Tera-Stealth and the p0sh-Tera :) Notice the polished plates, beautiful!
Gold plated Tera tactile pad flex-pcb waiting for drill-job.
Space-age equipment used for design of the famous Tera-Pad.
You don't need 200W of solar panels to charge a Tera, but it can be done, as long as charging voltage is below 12V :))
Testing a Tera digital transport:
PLEASE NOTE: THE BELOW SITE IS ABOUT THE FIRST TERA-PLAYER PROTOTYPE.
FOR THE PRODUCTION TERA-PLAYER, PLEASE GO TO WWW.TERA-PLAYER.COM
The ALTMANN TERA-PLAYER PROTOTYPE .. really has not so much to do with the actual Tera-Player product, but many of you are soooo curious ...
The Altmann Tera-Player the world's first handheld music player that plays .wav files from a SDHC card without oversampling and up to 192kHz sample-rate. It is the highest audio quality handheld player today.
The black pin in the middle, is a small joystick for music navigation and volume setting.
The Altmann Tera Player features an impressive number of worlds firsts:
World's first handheld digital music player that can play uncompressed wav-files up to 192kHz sample-rate.
World's first handheld digital music player without oversampling.
Worlds first music player that automatically adjusts to the the following playback samplerates: 44.1 kHz, 48 kHz, 88.2 kHz, 96 kHz, 176,4 kHz and 192kHz.
Worlds first digital audio player that employs a 16-bit string DAC.
The Altmann Tera-Player reads from a micro SDHC card.
SDHC card in slot:
The other side: headphone jack, power plug and on/off switch.
The Altmann Tera-Player does support wav-files only. No compressed music. It is about the size of a matchbox:
The Altmann Tera-Player is powered by a cell-phone Li-Ion battery and is designed to be charged with a cell-phone charger.
At the end of 2007, I played around with the widgets of my new Mac-mini. I found a Pong-widget, you know this old tennis-type video game.
Then I had the idea of making my own pong-game, I still had this spare 10" flatscreen monitor. Having no ideas of video signals I googled around and found the website of Peter Jakacki. Peter had won an ARM programming contest that was set out by Philips semiconductor, now NXP.
Peter has programmed his NXP arm processor to output a video signal. I was impressed. Although I had some knowledge about microcontrollers, I never worked with an ARM chip.
So I decided to give it a try and ordered an LPC evaluation board from Keil.
Peter had programmed a color video signal on his lpc arm-chip, however I wanted to use the 800 x 600 video mode and did not need the colors for Pong. I also honestly did not understand Peter's routines (which are written in Forth, very cool :) so I basically was up to myself.
My version of the video output made use of the SSP (synchrounous serial port) inside the LPC-2103.
The SSP implementation in the LPC-2103 features an 8-frame 16-bit FIFO, which means that you can serially output 128-bit (enough for a Pong video line) without any load on the processor.
I used studio faders for controlling the paddles instead of rotary potentiometers. The faders have the same length as the screen, so the slider position is identical to the paddle position on the screen, which means you can play some real fast Pong :-)
The result looked like this and was real fun to play:
Learning ARM assembler language was a bit new, and fun.
In a way it is the most beautiful programming language in existence. ARM assembler code can have a density which is close to the critical mass. It is almost an implosion, LOL.
I found it odd that there was no assembler directive to allocate RAM like 'DS.B' or 'DS.W' for the Intel 8051 or 'DFS' for the Motorola HC08 or 'BLKB' for the Mitsubisch M377xx or 'RES' for the Microchip PIC, etc.
Instead you have to write down the offsets manually:
As I thought, I was doing something wrong or was not finding a feature in the assembler, I called ARM in Munich to inquire about this. They told me that the assembler is made by KEIL and I should call them. So I called KEIL (they made the dev.kit I was using) only to learn that they did not understand my question and they did not understand why I was programming in assembler (instead of C) and that the assembler is not made by KEIL, but by ARM ;)
They also told me that I could never produce code in ARM assembler that will be as efficient as the code that comes out of their C-compiler.
I don't know if that really is the case, but somehow I doubt it.
However, the powerful SSP in NXP's LPC ARM controller rang a bell inside me.
A fully automated high-speed serial 128-bit output is indeed a rare feature which I had never encountered before in any microcontroller.
My second idea was generating a S/PDIF signal in software. One S/PDIF frame consist of 64 bit. Because S/PDIF is biphase mark encoded you need to transmit 128 bit.
The SSP's FIFO inside my NXP ARM has exactly 128 bit, what a match.
I had the idea of building a mini-transport, which plays wav files from a SD or SDHC card.
Meanwhile my KEIL board was pumped up: VGA, TOSLINK S/PDIF and SD card connector:
The biphase mark coding of the S/PDIF signal was a bit tricky as the data stream had to be reversed. In order to do that in real-time with high sample-rates I had to make a lookup-table:
S/PDIF also uses a parity bit, that now must be generated in software, all other status bits are of minor importance and are set to standard values.
It worked. I managed to send a zero S/PDIF stream to my Attraction DAC and it locked :)
Next I had to implement the SD-card interface. As the chip I was using had no in-built SD-card support, I wrote routines that interface via port pins to the SD-card in 4-bit bus mode, doing all the clocks manually. ARM assembler is able to handle that effectively.
Reading a wav file from the SD-card and putting out the S/PDIF signal worked up to 96 kHz. The real-time construction of the S/PDIF signal took most of the processing time.
See below my first prototype. This already has Li-Ion charging circuitry and navigation joystick.
This is the bottom layer of my first prototype. The DAC chip and output amplifier are still unmounted.
Now for the DAC section. As you may already know sigma-delta converters are cheap to manufacture, but sound very bad, which is the main reason that all existing mp3 player, ipod, etc. just give you a good headache, but in no way any feeling of hi-fidelity.
So what was needed, was a single-supply, low-voltage, low-power true mulitbit DAC. I decided for the 16-bit DAC 8552 from Burr Brown which uses a resistor string architecture.
A 16-bit resistor string DAC consists of 65536 resistors in a series connection (string). Each resistor tap has an associated switch to connect to the output, giving 65536 different voltages.
String DACs have the advantage of extremely low noise during code changes, which is a highly desirable feature for an audio DAC.
Also the distribution of 2nd and 3rd order harmonics of the DAC8552 looked highly promising.
As nobody seems to have ever used a string DAC for an audio-application before, I was curious how it would sound.
It sounds fantastic :)
On the next picture you see a close-up of the audio clocks (the 2 tiny rectangulars below the LPC chip). The Altmann Tera-Player uses true audio clocks for 44.1 and 48 kHz and their multiples. The ARM processor switches between the two clocks depending on the sample-rate of the .wav file to be played. While one clock is used, the other is disabled.
This sounds simple but it is a really tricky thing, as the ARM processor while running on clock A (44.1 / 88.2 / 176.4 kHz) has to switch to clock B (48 / 96 / 192 kHz) if the playlist requirest this. Now what happens during the transition ? One clock is switched off, and at the same time the other clock is switched on. I was thinking that this would definitely cause some hangups, but to my absolute surprise it works flawlessly.
You can have a mixed playlist where a 44.1 kHz CD track is followed by a 192 kHz hi-resolution track, and it will just play beautifully, no pops, no clicks, just music.
The output of the DAC runs through a small passive filter circuit and then enters the headphone stage. I am using 2 OPA4343 packages, with a total of 8 Opamps that work in a parallel push-pull configuration, so that the headphone is driven directly, without any coupling caps.
This gives a very good low frequency performance down to DC.
So it all worked quite well until I ran into a problem. The sound was very good, worlds better than any other player, but still not good enough. It sounded as if I was having some jitter problem, but why ? The machine is powered by battery, the music is read from a flash card - no moving parts, I'm using ultra-precision Oscillators (from Golledge).
So what's the problem ?
Hm ....
It turned out that the problem was the flash-card. While reading from the SDHC-card, every time I jumped to the FAT in order to look where the next cluster of data would be, there was a huge current surge from the supply. As the FAT has to be looked up regularly there was a very bad jitter correlation.
I learned that this was not only a problem for the one card I was using, but it is a problem inherent in all SD-cards. Whenever you have to change the reading location (i.e. jump to FAT) there will be a jerk in the supply, causing a significant and badly correlated amount of jitter.
So flash storage, just because there are no moving parts, does not mean that you will not have jitter ;-)
The mess you see below the SD-card socket on the following pic shows my attempt to smooth out the power supply of the flash card, using a simple R-C-R-C-R-C chain.
While the filter chain reduced the jitter, this was not a complete solution. I had to come up with something better ...
Then I had the idea, that if I could reduce the number of FAT reads per time, I would be able to break the jitter correlation.
Up to know I was jumping to the FAT for each and every cluster. That gave me a constant jitter frequency that was very audible also dependent on the sample-rate of the wav file.
The solution was the introduction of a continuity counter. While running through the FAT, I would count the number of clusters that are linearly allocated without fragmentation. This way I only need to jump to the FAT again when the continuous cluster chain is running out.
With the continuity counter the number of power supply jerks that are caused during each FAT read, were reduced from a couple of times per second to about 1x per minute.
This completely solved the SD-card jitter problem.
The Tera-Player has come a long way. I consider it the best sounding handheld playback machine in existence today - by a large margin.
So what is missing ?
There are a few things that are not yet solved:
Pop noise in headphone during power on and power off.
FAT 32 file support and navigation not completely programmed.
Some people said that it is not loud enough. I think it is very loud on the headphones, but it could be louder, when you connect it to your home stereo.
Housing is not water protected.
No Display. This is blind navigation. Folders are supported and are accessed by a push-slide of the tiny joystick.
However with 2 Terabytes of wav-files on your SDHC or SDXC card, it will be difficult to locate and individual track without a display ;)
I have to admit that I also got a little bit distracted by other projects and also by fulfilling all your orders, but I hope I can finish this nice little player in the near future and make it available to you.
Fun ...
ENOUGH PEEPING, NOW GO TO WWW.TERA-PLAYER.COM !!!
ALTMANN MICRO MACHINES ... Dipl.-Ing. Charles Altmann ... Erlenstr. 15 ...42697 Solingen ...Germany
phone +49-212-233-7039 ... email