# audiophile diy DAP?



## Danielj

OK folks...I know there are alot of electronic wizards here; building your own dacs, phone amps, etc. So what about a transportable true audiophile quality DAP? I know Vinnie is doing the imod thing with clean line out...which is what is missing from all these comsumer audio players. But he is working with microscopic size circuits. I am thinking of something larger: a bare bones unit; mains and battery powered, but smaller than the pixel magic and the like. something that outputs to a headphone amp and designed just for that. What would be needed to make a truly good DAP

 easy stuff
 2.5 harddrive, laptop type 
 small dac like monica
 good quality lineout directly from dac no internal headphone amp
 small ipod type screen

 hard stuff?
 firmware like rockbox?
 the processor to operate the whole thing. Is this where the problem would be? The pixel magic type players are using a sigma processor and linux software.

 so, is the technology abailable to gather all the parts for such a device? If it is, it seem s to me that all is needed is to have the knowledge to wire all of it together. I have a friend that is on headfi...I betcha he could do it.

 thoughts and problems

 thanks
 Daniel


----------



## pheonix991

I don't think there is anything like this.


----------



## threepointone

not _yet_ *hint hint*

 sigmatel processors are uber-unobtainium in small quantities. However, the freescale MCF5250 (or scf, keep on getting confused) which is used in the iriver h3x0 series is more readily available.

 The iriver h3x0 also happens to run rockbox *hint hint hint*

 wiring together? surface mount, not quite as easy as you'd think. something goes wrong? debugging would require quite a bit of skill and tools.


----------



## Sherwood

I think if size is not an issue, most folks elect for a purpose-built silent PC. Really, what you're looking at is a music server. Perhaps something like the Olive Opus.


----------



## Danielj

So there are chips available i.e. as in iriver. that's encouraging About wiring...I dont know anything thats why its good to know people who do. But it seems to me that if the path of componant connection is known via all these consumer dap's diying on a larger scale should be possible. As you say tho, if something goes wrong, one would need alot of skill to track down the problem.

 yes, the Olive opus minus the cd transport and of course diyable and much cheaper. I am a poor guy and as you all on headfi know - audiophil itis is quite expensive. 

 I am glad to hear so folks chipping in on thise...keep it up something good might come of it.


----------



## Danielj

Yes, I have looked into the small form silent pc vendors. I dont know if mounting a dac internally running directly off the motherboard is possible,or sonically advisable....or perhaps an internal soundcardwith digital out and use an external dac, then headphone amp?.

 I see on ebay all the time these cheap multi media players where you put in your own hard drive. But everything I have read about them say the sound quality is really sub par

 Just have been wondering if diyers have experimented with making their own DAPs
 thanks all


----------



## threepointone

I personally don't like full-scale PCs for audio--there's just too much overhead from the software that isn't necessary and might mess up the audio without you realizing it (case in point: kmixer). Also, making a full-scale sound card is a whole lot harder than making a DAC. You have to deal with the PCI bus, all the digital noise inside a full-scale PC, and the drivers for the DAC. Quite a nightmare for any DIYer. I'm quite certain it's virtually impossible to do some crazy modification to the motherboard in order to accomplish this.

 Either way, a 2Ghz CPU is about 10000x more processing power and complexity than you'd need to do this sort of stuff. It's probably easier to just design a DAP from scratch. The rockbox project actually has most of the schematics for the iriver on its site--it shouldn't be all that difficult to make a copy of the iriver using a bigger board and mostly thru-hole components, though it wouldn't be fun to solder/debug 100+ SMT processor pins. Most of the work would probably lie in the layout and modifying the rockbox firmware for the modified components (no li-ion power controller, different DAC, etc. . .). I've been planning to do this sort of DIY audiophile DAP this summer, although I was going to jump directly to an ultraportable design.

 btw, the MCF5250 happens to come in a LQFP package, unlike some of the other coldfire chips I was looking at, which means it's accessible to a lot more than the 10 DIYers who have a toaster-oven-bga reflow system set up.


----------



## gates_2

To me, it would be absolutely amazing to see a high-quality DIY dap that has a SQ better than the standard Ipod

 Amplifiers and Daps are two very different animals. I really wouldn't be surprised if we had some talented ECE people here who could pull this off.

 With the cost of flash technology, you could easily stick a 4-8gb card in the player.

 Big issues would still be on our(the DIyer side) Without a knowledge of how it actually works(those processors are much more complicated than an 8 socket opamp) one tiny mistake could cause huge amounts of frustration!

 Heres a current offering, albeit not quite audiophile quality:http://www.techdesign.be/projects/020/020.htm

 EDIT: more:http://www.teuthis.com/html/kits.html


----------



## oicdn

Well, maybe not just a home unit, but a portable unit. People are making portable amps....and as we all know, size can and will vary.

 It would be sweet to see something flash based like a Shuffle (without a screen to make it easier on the developer, just buttons) with the 1/8th jack being a dedicated line out....i.e. useless without an amp, or can be used cans with an inline attenuator ala KSC 75s ampless.

 I would buy one.


----------



## Danielj

I just did a search on the web and there are several diy mp3 players....but we are looking for somthing alot more high end.

 3.1 I agree that a computer based system is way overkill. Please keep me posted on your progress this summer. thanks Dan


----------



## jonnywolfet

dammit, i cant find an old link i had for a diy product that was open source, hosted most hard drives, and output to coax digital. with various addon components.
 does that not sound perfect?


----------



## jonnywolfet

i found this:
http://dma.elektroda.net/projects/mp...rm_player.html
 not the link i was looking for but its interesting.


----------



## balou

Quote:


 firmware like rockbox? 
 

 why 'like'? rockbox is open source - you could use it as the main OS

  Quote:


 I just did a search on the web and there are several diy mp3 players....but we are looking for somthing alot more high end 
 

.
 Makezine had one... it uses an all-integrated-chip. sd card interface, mp3 decoder, user interface, headphone amp... not really a good option.


  Quote:


 It would be sweet to see something flash based like a Shuffle (without a screen to make it easier on the developer, just buttons) with the 1/8th jack being a dedicated line out....i.e. useless without an amp, or can be used cans with an inline attenuator ala KSC 75s ampless. 
 

all that's really needed is something which accepts sd cards, and puts out an i2s or spdif signal. the rest can be borrowed from the alien dac or other usb-powered diy dacs. I'm interested in such a thing too. After my holidays, I'll try to find a chip which could one or more of the required things. Oh and why sd cards? 1. available everywhere 2. cheap 3. easy to adress from a hardware perspective 4. exchangeable. if you don't need multiple megabytes per second (320kbps mp3 equals just 40kb/sec), you can access sd cards with a simple serial protocol.
 ti, maxim or ad surely have some mp3 decoders. maybe even with some extra stuff like spdif out... the other controling stuff could be done by an atmel microcontroller

 edit: jonnywolfet: indeed interesting. seems like this guy wrote the mp3 decoder 100% in software, and used mm cards (sd cards are backwards compatible). but I don't think the on-chip dac could be considered audiophile.
 edit2: looks like a software-emulated 1-bit dac. yep, maybe not audiophile...


----------



## Sherwood

Hypothetically, though, anything that could run slim client could also run linux and, through that, foobar or some foobar derivation. There are already existing DIY USB dacs that could be built into the housing of such a unit, bypassing kmixer and other internal processing. You could find parts for this, everything but the drive, for literally free at thrift stores. Sure, a modern computer is 50x overkill, but people are throwing away computers that are 1/50th of the power of a modern computer.

 The biggest problem would be fan noise -- old computers are loud, and quiet computers are pricy.


----------



## srobertson

Hop on IRC and join the Neuros 3 design meeting:

http://open.neurostechnology.com/node/894

 A full-featured DAP is being designed from the ground up, and as it stands the first run will have a case with a generous amount of room - it's conceivable that a digital out could be offered with test points that could be grabbed by a custom DAC and piped to a real line out.

 Full disclosure: This device is going to be entirely community-designed, but manufactured by Neuros, the company I'm an intern with this summer. (Don't worry, they're great people.)


----------



## spongezone

Making something small with decent battery life that could play FLACs (for example) would be extremely difficult without some uber computer engineering skills. Especially if you want to interface IDE or SATA to it.

 I suppose hacking something something like an NSLU2 wouldnt be impossible. You could simply hook up a 2.5" USB hard drive to it, and interface a serial LCD to the serial port. The CPU, 266mhz Xscale, should have plently of power to decode FLACs, but you'd have to be an embedded linux guru to figure out how to get digital audio out of the thing (from one of the USB ports, perhaps). Even so, there would still be the problem of how to run the thing on batteries, and it would still not exactly be small.

 Edit: I take it back, apparently its quite easy to interface a USB DAC to the NSLU2. http://www.nslu2-linux.org/wiki/HowTo/SlugAsAudioPlayer
 I suppose interfacing something like a PCM2702 to it would be trivial then. The only remaining issue would be battery power. http://www.nslu2-linux.org/wiki/HowT...eryPoweredSlug


----------



## balou

Quote:


 Especially if you want to interface IDE or SATA to it. 
 

TI has ATA interface chips, DSPs specially designed for mp3 players, DACs, and application notes on how to wire that stuff together 
	

	
	
		
		

		
			





 other IC fabs surely have similar product lines


----------



## labmat

Quote:


  Originally Posted by *balou* /img/forum/go_quote.gif 
_
 Makezine had one... it uses an all-integrated-chip. sd card interface, mp3 decoder, user interface, headphone amp... not really a good option.
_

 

http://store.makezine.com/ProductDet...tCode=MKMP3KIT


----------



## louilouinovo

May be one way to achieve a good player is to use a ITX Pc, the nano itx motherboards is 12cm x 12cm and has everything you need. I am not sure they are fanless but it can use external PSU. If you want to go smaller you can go with the Pico Itx it's 10cm x 7 cm.
 Via who promote the Itx format is known for their ship in the av710 soundcard. The price of Nano, mini and pico Itx decrease regularily, So wait and see. 

 Another way is to use A board dedicated to music like this one or this other one. sorry the second one is in french. But it is a pure Diy, they sell Pcb, take a look to the ships, I don't think they will be easy to solder.

 I will prefer the first solution, it's the more flexible one.


----------



## colonelkernel8

The reason it is so hard is obviously the components used are typically proprietary and are only manufactured for the company making it. Like the LCD screen for example, and the really, really, really complicated PCB's that have traces so small its scary.


----------



## threepointone

thanks to the trend towards sticking everything on one chip, most of the ata/SD interface/etc external chips aren't really necessary--a lot of microcontrollers already have these built in.

 If there's people interested in wallwart powered, somewhat large DAPs, well that's actually not too difficult to make. However, if we want a portable device, it's a lot more difficult. I've been looking into DAP design a lot these days, and it appears that the main difficulty for us HF DIYers wouldn't be so much the engineering behind it but the uber-unobtainium required. I've looked at several DAP schematics from the rockbox project, and honestly the hardware for most DAPs is virtually the same--a DAC/headphone driver IC, some power management ICs, display, RAM, and a microcontroller which sometimes has the rest built-in. They differ in the displays used, the casing design, or the interface design (i.e. capacitative touch sensor on the iPod), and the exact ICs that are used. The most difficult part of hardware design for us is most likely the PCB routing and finding out where to get the casing manufactured.

 More difficult is sourcing the components which will allow us to make a low-power and small DAP. Unlike our headphone amplifiers, reducing power consumption is something that can really only be done on the IC manufacturer/designer side. If we want our own DAP to compete in terms of performance/size/battery life with the latest generation of DAPs (iPod nano, etc) we would need access to the newest/most efficient microcontrollers, RAM chips, flash ICs, etc. . . which is mostly uber-unobtainium for DIYers. If we just want something like the old iriver H3xx, we're faced with another problem: since we're looking for audiophile quality, and audiophile = uber-inefficiency, chances are, our design would be even less efficient/larger than the _old_ DAPs which lasted only 8 hours or less. I'm pretty certain that most of our current headphone amp designs/DAC designs already use more power than an entire portable DAP. 

 The LCD screen for the portable DAPs was indeed the most difficult thing to find when I was first researching the feasibility of this project. I finally got referred to sparkfun.com, which sold small color LCDs for relatively reasonable prices (I think mouser started stocking small color LCDs, too, but at $100+ per unit). Now they even managed to get a hold of genuine PSP LCDs at what I'd say is a pretty reasonable price--they're absolutely the best source for diy uber-unobtainium I've seen on the Internet. Hopefully, should we try going forward with a DIY portable dap, they might be able to help in finding the rest of the uber-unobtainium.

 What I think _might_ be able to allow us to make a truly portable, competitive DAP is with a lot of CS trickery. If we've got any EE+CS geniuses around here, I've got a couple of (possibly impossible) challenges for you that could really make a truly revolutionary DAP:
 a) get a FLAC/MP3/shorten (shorten seems to use the least processing power, at least on the x86, iirc) decoder to run realtime on a 16-bit MSP430 chip, possibly running in parallel (these things can run literally ~300uA/2.2V at 1Mhz; at higher speeds it's still pretty darn low power)
 b) use a more complex microcontroller and instead of mathematically decoding everything, see if you can pull it off using lots of lookup tables. This theoretically could significantly reduce the clock speed and power required. There's a lot of problems with this, including ram timing, what kind of memory to use, etc. . . but philosophically it just kind of appalls me to think that our computers have to recalculate the same basic functions over and over again

 hm... I really like making looooooooooong technical posts, don't I?


----------



## spongezone

Sure, with a team of CS, CE, and EE people putting thousands of man-hours of work into this, it could become a reality. But, I think this is outside the scope of a DIY project. 

 It's sort of strange really, that there are such massive open source software projects around, but open source hardware has yet to really materialize. I guess Arduino and Chumby are pioneers in that field, but even those are somewhat less complicated than this. Arduino is just an AVR platform, and Chumby doesn't have to worry about being power efficient.

 If you do want to get a full scale open source hardware project together though, I'm up for helping out. I'm currently studying Electrical and Computer Engineering, so I've got some background in the area.


----------



## gates_2

Well another option would be a "transportable" dap- by that I mean something not so small as to fit into your pocket, but perhaps something that would fit into a bag or backpack... That would make things a bit easier right?

 As far as the LCD goes, I know that one DIY MP3 player site sais it uses screens from an old model nokia cell phone- you could probably buy used/broken units on ebay for cheap


----------



## vYu223

Interesting. I'm going to subscribe to this thread to see what happens.


----------



## j4cbo

The codecs are the biggest challenge. There are plenty of very low power dedicated DSP products for decoding MP3, WMA, etc., but none that I'm aware of that handle lossless codecs such as FLAC.


----------



## Danielj

For my purposes a wal wart would be just fine. I hear running battery power is smoother,so one could certainly obtain an external battery pack and charge it up at night. 

 As I said when starting this thread...I know nothing about electronics. But i do know about sound quality. So my vote would be not to try to compete with the commercial micro options out there as far as features and size, but rather a larger; better quality; better sounding Dap that could replace a desktop Cd transport as a source. 

 Its good to hear all you techies talking about this,even if I dont understand 90$ of it.


----------



## threepointone

codecs aren't at all a problem if we can stick rockbox on it, and since I'm going to be running the same cpu as the h340, it should be quite possible.

 The main difficulty in my head at the moment is a bdm programmer for the coldfire microcontrollers (used on the h340/compatible with rockbox) that doesn't cost $250+; honestly I don't think I'll be programming on that platform in the future, and I'm not ready to drop that much for something I won't use again. Anyone here played with fpgas/cplds/programmable logic before? I found just one schematic for a bdm programmer for this chip, but it uses a programmable logic IC which I have no idea how to use/debug/program. There's also bdm programmers for other platforms, like the 68k--would those also work with the coldfire microcontrollers?
 I know most people on head-fi probalby wouldn't have much experience with this digital stuff, since we mainly deal with analog, but I guess it's worth a try with some questions anyway.

 And back to analog! I've never really looked into audiophile DAC design, so I'm just wondering exactly what makes a DAC audiophile quality? I've heard of jitter, but exactly how do we minimize it? Are there any other parameters that should be considered when designing a DAC, and what DAC ICs should I use?


----------



## Cauhtemoc

Forget all about codecs and fancy processors. Just run .wav files of a 2.5" IDE harddrive. They are easy to decode and even a 40 GB harddrive could hold over 400 songs at 24 bit/192 kHz. Throw in a CS4398 or WM8740 DAC and your set.


----------



## spongezone

AFAIK, there are no FLAC DSPs, or low power FPGAs, for that matter. That's why it would be easier just to use software decoding, and have a reasonably beefy CPU. If it's not going to be small anyway, that should be fine.

 Anyway, I looked at my friend's NSLU2 again, and it's much smaller than I remember. With a bit of effort, it would be possible to fit an NSLU2, a small LCD, a 1.8" hard drive, and a small DAC inside an original Gameboy case. a battery wouldn't fit inside though.

 Anyway, I think the best bet is to go for something Xscale, simply for ease of programming (and because several hardware platforms already exist, making this project, well... realistic).


----------



## louilouinovo

May be someone can take a look inside a high end Dap and tell us what are the ships used used inside ?


----------



## j4cbo

I don't think Xscale is available in anything non-BGA, which would make DIY assembly more or less impossible.

 The NXP (formerly Philips) LPC2368 is a nice processor: 72 MHz ARM7, half a meg of Flash, built-in I2S, built-in SD (8 gigabyte SDHC cards are cheap now), etc. It only has 32k of internal SRAM on the bus, though, which may be insufficient.


----------



## threepointone

Yeah, people already have. That's what I'm basing my design on--the iriver H340. I was pretty much inspired by everything by rockbox' work on disassembling and documenting all the hardware in the DAPs; I realized that there the differences among most DAPs were minimal, and that as long as if we had the software to run everything (rockbox) the hardware wouldn't be that difficult to _design_ (of course, sourcing all the parts and miniaturizing/reducing size would not be as easy). For example, look at the Iaudio X5/M3 and Iriver H3xx/H1xx; the basic components used in those players are virtually identical in function, and those players actually use the same processors as well. The other rockbox players, including the iPod, Gigabeat, and H10 also use pretty much the same portalplayer ICs (which are not accessible to us).
 Hardware info is available via http://www.rockbox.org/twiki/bin/view/Main/WebHome. Click on the player you're looking at under "Ports" then look for the link labelled "[player name]hardwarecomponents" or the schematics, if available (didn't want to post 15 different links)

 Anyway, heres the basic idea of what i'm going to be working on:
 a) first I'll probably prototype a (mostly) non-portable wall-powered unit based on the MCF5250, the microcontroller used in the H3x0. It'd really just be a quick prototype/feasibility check project.
 b) then I'd start on a portable version. I might still use the MCF5250 first, but I think the base power consumption of that chip might be too high. I might look for a lower power ARM chip.
 c) completely radical design. might pick some exotic ultra-low-power architecture or see if I can get some of the dedicated DAP chips. Might run a custom firmware instead of rockbox.

 of course, everything would be designed with audiophile quality in mind.

 The primary things that are preventing me from going forward at the moment are: 
 a) need a way of programming a coldfire microcontroller. The standard way is to use a BDM programmer, but those cost $250+ minimum and I don't see myself using coldfire ICs after this project so I'd rather make one myself. The only diy coldfire bdm pod I've seen requires programming cplds, which I don't know how to use either. There are some DIY BDMs for other kinds of microcontrollers, but I don't know if they'd work for the coldfire platform. The coldfire microcontroller also has a JTAG interface, but I'm still not entirely sure if I could use that for programming, as it is usually used for testing during production.
 b) prototyping PCBs. It's not really a problem specific for this project, but currently I've got another project on my mind for making prototype PCBs which might go first to ease the wait time for the DAP project
 c) MCF5250 IC. Waiting for samples--hopefully freescale accepts my request (I put legitimate info, of course). If they don't, I'm screwed because the only other place that has MCF5250 (or scf? i still can't get this straight) ICs available has a pretty large minimum order quantity, which also poses some problems if any of these designs really work and become published. May need some group buys and/or redistribute parts


----------



## spongezone

Quote:


  Originally Posted by *j4cbo* /img/forum/go_quote.gif 
_I don't think Xscale is available in anything non-BGA, which would make DIY assembly more or less impossible.

 The NXP (formerly Philips) LPC2368 is a nice processor: 72 MHz ARM7, half a meg of Flash, built-in I2S, built-in SD (8 gigabyte SDHC cards are cheap now), etc. It only has 32k of internal SRAM on the bus, though, which may be insufficient._

 

My point was that there are many Xscale boards readily available at reasonable prices, making a DIY project realistic. And more so, it would make it truely DIY, rather than a, one person buys expensive equipment, manufactures boards, and sells them to people who want to "DIY" it.

 Just a few examples are NSLU2, Gumstix, and Zipit.


----------



## utilisateur

*subscribed

 and i've got a link to check out
NSLU as audioplayer


----------



## spongezone

Quote:


  Originally Posted by *utilisateur* /img/forum/go_quote.gif 
_*subscribed

 and i've got a link to check out
NSLU as audioplayer



_

 

Not bad. Looks like FLAC is only 17% CPU usage for a 266mhz Xscale.


----------



## threepointone

If we're still talking about making a portable DAP, we shouldn't be looking at clock speeds at all--rather, we should be looking at how little power it'll use at lower clock speeds. Sure, the iPod ARM processor might be able to run at 75Mhz or higher, but most of the time it probably runs at lower speeds in order to save power. Since the XScale is rated for such high speeds, though it may be low power consumption for its performance, I wouldn't be so sure that it'd be the best choice for lower speeds. I'm not very familiar with the XScale series, so I'm not sure exactly which processor I should look at to evaluate, but I would think that it also costs more than alternatives.

 Otherwise, if we're just talking about a desktop DAP, I really don't think there's a problem with any of the chips suggested here--the ARM series is used by many (if not most) modern DAPs. The XScale series is actually based on the ARM core, according to wikipedia. Additionally, the ARM (or at least the portalplayer flavor) is already running rockbox, which is the open-source replacement firmware for the ipod/iriver hxx(x)/iaudio/toshiba gigabeat/etc that can play FLACs. Personally, I'm looking at the coldfire SCF5250 series right now since it's the most obtainable and most usable (available in non-BGA surface mount) microcontrollers out of all those supported by rockbox. I would expect that we'd have to modify <50 lines of code; in fact, we'd probably be mostly deleting modules from rockbox, since we wouldn't need any of the power management routines.


----------



## threepointone

Quote:


  Originally Posted by *j4cbo* /img/forum/go_quote.gif 
_It only has 32k of internal SRAM on the bus, though, which may be insufficient._

 

Don't worry about the internal RAM; virtually all DAPs (or any of the more complex digital equipment) will have an additional external RAM chip.


----------



## j4cbo

Quote:


  Originally Posted by *threepointone* /img/forum/go_quote.gif 
_Don't worry about the internal RAM; virtually all DAPs (or any of the more complex digital equipment) will have an additional external RAM chip._

 

Necessary for buffering in a hard drive player, but not so much if it's Flash-based. External RAM is certainly an option but adds quite a bit to the design difficulty.

 I suspect you're underestimating the effort required to integrate all the hardware and software here. Using a chip that Rockbox has already been run on doesn't really provide any advantage, as it'll still be essentially a new hardware platform (everything but the uC, user interface available, etc.); why limit yourself?


----------



## bubbamc119

Great idea. 24bit playback should be considered.


----------



## Cauhtemoc

Quote:


  Originally Posted by *j4cbo* 
_Necessary for buffering in a hard drive player, but not so much if it's Flash-based. External RAM is certainly an option but adds quite a bit to the design difficulty._

 

32 kB is enough to store some 30 ms of audio at 24 bit/192 kHz. Even the slowest of harddrives doesn't have a random access time this long.


----------



## bubbamc119

I'm going to subscribe to this thread. I finish my electronics/comms degree in a few months and would be glad to help get this off the ground.


----------



## labmat

I would love to see something like this get off the ground; and I would love to help wherever needed. I'm a Mechanical Designer by day and have access to 3D CAD software and can design any mechanical parts needed.


----------



## Danielj

Wav of course is mandatory and flac would be nice. If wav only, then of course the case would have to support much larger drive. Either way, one thing I think would be essentail is hardrive swapping or more importantly, access to a 2nd HD via usb. I have noticed in reviews of these new players running off the sigmatel chip, is that they are having problems accessing a HD via usb...seems to be a firmware problem. 
 Perhaps in our player; a physical switch to select either internal or external HD prior to bootup. Why would the chip care which one is being used?


----------



## threepointone

interfacing an HD via USB is completely different than interfacing with an directly with an HD (ATA protocol). however, if we really want it as a feature, I know FTDI makes a chip that can handle USB mass storage devices; we can add it at the expense of complexity/space. Having the USB host on the CPU is a nicer way to do it, of course, but USB host features seem to be not as common and probably require more software without a very high level dedicated IC for it


----------



## Danielj

Well, then...flac with room in the case for a 120-160 gig lpatop size HD.

 Other thoughts The dac should be given high priority in the design; if we use the same sort that is in the portable players available...what's the point, just by an Iriver. I only know what I read about dacs; monica 2 and alien dac. the Spitfire by firestone has good reviews and they mention the components used. Also many people say good things about the dac used in the emu systems external soundcards.

 Also, most portable daps do not have a true line out, they just lock the amped signal at a certain gain. If our project has a headphone jack, then again perhaps a switch for lineout that bypassed all the amp stuff.


----------



## spongezone

I'm not sure it's worth placing power efficiency as a main concern if the other goals of the project are audiophile quality and high capacity 2.5" hard drives. If it has a 2.5" hard drive in it, it's already not exactly portable or power efficient, so you might as well stick a giant (~6-8 AA) battery pack onto it and use a more powerful, more readily available CPU like an Xscale (or an older StrongARM).

 Apparently my take on this project is not quite the same as most other people's.


----------



## threepointone

hm... there is definitely a bit of confusion on exactly what everyone means by DAP. I don't know about everyone else, but an audiophile quality DAP has been on my todo list for a while, and I've already been working on plans for a DAP based on the scf5250. One main reason I'm using the SCF5250 is that it was designed for audio--it has a built-in SPDIF interface, flash/ide memory interface, and CD-ROM decoding/interfacing (probably won't use this, of course). It also appears to be very flexible with the I2S clocking; the maximum frequency is 1/2 (or 1/3, but probably a typo in the manual) of the system clock, which would put the maximum I2S clock rate in the ~<10Mhz range. Correct me if I'm wrong (I haven't done too much research on I2S, I admit) but a worst-case (or "best"-case) 24-bit, 192kHz digital audio signal would only need a 4.6Mhz clock, so this is definitely fast enough.


 Of course, as a group, we can create something entirely different. If this indeed is a non-portable project, there's nothing wrong with an XScale; I just personally know little about the platform.


 Following what the OP said, I think we should all assume that whatever we're working on is simply an audiophile DAP without a strong emphasis on portability. I'm still not sure exactly how "non-portable" it would be--will this be completely non-portable, like a speaker amp/home cd/dvd player or will this be somewhat portable (PIMETA-ish sized, and can run off battery power if necessary?)

 After we figure that out, we should probably begin to outline the basic features we'll be designing into this DAP, what software we plan to run on it, and decide on a hardware platform to work off of. So far we've got XScale, (strongARM?), ARM, ColdFire, and. . .I'm sure I missed something there.

 There's also the possibility of doing the whole thing with minimal complexity in terms of software, and just make it play WAVs. We can back down to that plan if we really can't pull something cooler off


----------



## threepointone

AAAHHHHHHHAAAA!!!!!!!! Two days of searching and I've finally found it.
 DIY Coldfire BDM programmer for <$250 (or rather, <$10!!!)

http://forums.freescale.com/freescal...=624&jump=true

 Looks like I'm really going to get this project soon (at least mine; as I explained above, my own project isn't necessarily what everyone else has to do). I'm stuffing some new ICs into the eagle library and starting to remember why I hate eagle so much. . .

 btw, this also means that if any of you have bricked your iriver with rockbox, it just got a whole lot cheaper to repair it =)


----------



## Cauhtemoc

Quote:


  Originally Posted by *threepointone* 
_hm... there is definitely a bit of confusion on exactly what everyone means by DAP. I don't know about everyone else, but an audiophile quality DAP has been on my todo list for a while, and I've already been working on plans for a DAP based on the scf5250. One main reason I'm using the SCF5250 is that it was designed for audio--it has a built-in SPDIF interface, flash/ide memory interface, and CD-ROM decoding/interfacing (probably won't use this, of course). It also appears to be very flexible with the I2S clocking; the maximum frequency is 1/2 (or 1/3, but probably a typo in the manual) of the system clock, which would put the maximum I2S clock rate in the ~<10Mhz range. Correct me if I'm wrong (I haven't done too much research on I2S, I admit) but a worst-case (or "best"-case) 24-bit, 192kHz digital audio signal would only need a 4.6Mhz clock, so this is definitely fast enough._

 

Remember that you have to transfer two channels. You would need at least 9.216 MHz for 24 bit/192 kHz audio. 

  Quote:


  Originally Posted by *threepointone* 
_After we figure that out, we should probably begin to outline the basic features we'll be designing into this DAP, what software we plan to run on it, and decide on a hardware platform to work off of. So far we've got XScale, (strongARM?), ARM, ColdFire, and. . .I'm sure I missed something there._

 

You need to make your own software. Porting an already working firmware is way more complicated than creating something from scratch. Trust me, I've done it.

  Quote:


  Originally Posted by *threepointone* 
_There's also the possibility of doing the whole thing with minimal complexity in terms of software, and just make it play WAVs. We can back down to that plan if we really can't pull something cooler off 
	

	
	
		
		

		
		
	


	


_

 

You are all underestimating the effort needed for a project like this. You should start with something as simple as posible and move up FLAC once you have something that works.

  Quote:


  Originally Posted by *threepointone* 
_AAAHHHHHHHAAAA!!!!!!!! Two days of searching and I've finally found it.
 DIY Coldfire BDM programmer for <$250 (or rather, <$10!!!)

http://forums.freescale.com/freescal...=624&jump=true

 Looks like I'm really going to get this project soon (at least mine; as I explained above, my own project isn't necessarily what everyone else has to do). I'm stuffing some new ICs into the eagle library and starting to remember why I hate eagle so much. . .

 btw, this also means that if any of you have bricked your iriver with rockbox, it just got a whole lot cheaper to repair it =)_

 

That programmer is of little use to you. The embedded series of ColdFire processors (SCF5250 is part of this series) does not require a programmer per se, they have an instruction cache and run all code from an external EEPROM. Any serial EEPROM programmer would work (for example this one costs a whooping $5).


----------



## threepointone

I'm reading about the instruction cache right now, but I'm quite amazed that the rockbox dev team didn't even think of doing that and instead dumped their money on a $250 BDM. Actually, now that I think of it, the <$10 BDM has debugging capabilities, which is something I think would be quite necessary for the development process.

 I admit, I do have a tendency to underestimate things, but I still think it's better to try porting the rockbox. First of all, rockbox is a very unique piece of firmware: the development process has always been "backwards," in a sense, as rockbox has always software designed to work on hardware, the other way around. Additionally, rockbox has six years of code behind it--the first couple years, of course, were relatively quiet but the iriver port (based on the scf5249) still started in 2004, three years ago. It would take a very, very long time for us to start a piece of software from ground up to reach the abilities of the rockbox.

 Porting will definitely take quite some work--I'm expecting it to take up to the whole summer and a bit more. I still think it should be much easier porting the rockbox on a scf5250 platform, which it already runs on, than writing an entirely new firmware--looking at the project history for the iriver h3xx porting, it appears that many of the basic rockbox software components were successfully ported without any modification. Of course some of the software components which relate to the new external hardware had to be modified, such as the new color LCD. A significant portion of the initial development time for rockbox involved identifying all the components on the board and figuring out how everything was interconnected (on a 4+ layer board. . .not easy) and then trying to obtain all the datasheets. Now, however, we will know everything about the hardware, which should again reduce the amount of time it will take. In the end, I think it's more worth it to try porting the rockbox.


----------



## Danielj

As for form factor... i was thinking last night and looking at my 120gig portable IOmagic HDD which case dimens of about 3x5x.5 inches AS for our dap I was originally thinking something along the lines of mac mini size or the other small form factor min pcs. Looking around the house, trying to visualize a form factor for a laptop sized drive, I spotted a pile of vhs tapes next to my dvd player.. Yes I thought, this is the right shape; easy to throw in a bookbag or suticase. Could be layed flat or on its side for usage; external walwort powered. Course the actual vhs tape size may be a bit too thin and not quite wide enougt to place a drive in. But i like the form factor.

 3.1 is this something too small for what you are planning? Around 5x8x1.5 in....about four times the size of the ipod.


----------



## threepointone

size seems workable. I haven't figured out exactly what DAC/power supply design this thing will use, though, and as with everything audiophile, they might take up quite a bit of space.

 What kind of display should be used? nice & simple monochrome graphic LCD, something simpler, or something better? 

 I did a lot of research on this last year online, and here's a general idea of how easy for DIYers to obtain various LCDs (just a little note: by small, I mean small enough for to be portable, as I was thinking in terms of a portable DAP while I was looking)

*monochrome character displays*: really easy, they're everywhere, and easy to find. There's some pretty nice ones with inverted colors, blue blacklight, etc. . . Generally, they're pretty big for a portable DAP, but I'm sure they should fit snugly on this DAP. Not very high resolution density, however.
*monochrome graphics displays*: somewhat more difficult to obtain. Pretty much the same as above.

*tft color displays*: usually difficult to find, especially for smaller sizes (including as small as our DAP). DigiKey sells a couple, but they're overpriced and a bit too big for 1.5". Sparkfun also sells a nice PSP LCD, but it's also too big. After that, there's pretty much the cellphone displays and camera displays. The only (possibly) stable source for these displays is sparkfun (http://www.sparkfun.com/commerce/pro...oducts_id=569), which has a 1.2"x1.2" nokia display with data. I think a slightly wider display would be nicer, however. The only other sources for color LCDs would be ebay or old cellphones, which we can't rely on.

*OLCDs*: even though they're new, it turns out that they can be a bit more accessible than color LCDs. Digikey stocks them at reasonable prices (most expensive I saw was $30, most of them ~$10 ea) Sparkfun also has an OLCD which seems to fit and is higher resolution than any of those digikey stocks (http://www.sparkfun.com/commerce/pro...roducts_id=712) Unfortunately, it seems to have been OOS for a while.

 Note that I haven't gone over the driving requirements of all the display types yet.


----------



## louilouinovo

I am not for a portable Dap, I would prefer for a desktop Digital "audiophile" player
 with HDD and USB.

 In my opinion, no need to include a DAC, however the system must have connector to connect an external Dac or an nternal alien dac inside the enclosure fro example. It can ba a choice for the diyer. 

  Quote:


  Originally Posted by *threepointone* /img/forum/go_quote.gif 
_the MCF5250 happens to come in a LQFP package_

 

There is a LQFP 144 Universal prototyping boards for sell at http://www.poscope.com/ (click on product PoTQFP)

 You have mentionned the MCF5250, it seem that it is no longer manufactured (?), but the Sfc5250 can handle Flac and has USB. 
http://media.freescale.com/phoenix.z...794&highlight=


----------



## labmat

I think thats the perfect size for a first generation Audiophile DAP; It makes perfect sense to start a little larger and less portable and then pair down the size of the player with subsequent design revisions. I would think the the first generation could operate similarly to a PPA wallwart power with a separate battery pack at first and then migrating to an internal Lion battery and charger later.

  Quote:


  Originally Posted by *Danielj* /img/forum/go_quote.gif 
_As for form factor... i was thinking last night and looking at my 120gig portable IOmagic HDD which case dimens of about 3x5x.5 inches AS for our dap I was originally thinking something along the lines of mac mini size or the other small form factor min pcs. Looking around the house, trying to visualize a form factor for a laptop sized drive, I spotted a pile of vhs tapes next to my dvd player.. Yes I thought, this is the right shape; easy to throw in a bookbag or suticase. Could be layed flat or on its side for usage; external walwort powered. Course the actual vhs tape size may be a bit too thin and not quite wide enougt to place a drive in. But i like the form factor.

 3.1 is this something too small for what you are planning? Around 5x8x1.5 in....about four times the size of the ipod._


----------



## labmat

Quote:


  Originally Posted by *threepointone* /img/forum/go_quote.gif 
_*OLCDs*: even though they're new, it turns out that they can be a bit more accessible than color LCDs. Digikey stocks them at reasonable prices (most expensive I saw was $30, most of them ~$10 ea) Sparkfun also has an OLCD which seems to fit and is higher resolution than any of those digikey stocks (http://www.sparkfun.com/commerce/pro...roducts_id=712) Unfortunately, it seems to have been OOS for a while._

 

I vote for one of those


----------



## threepointone

Quote:


  Originally Posted by *louilouinovo* /img/forum/go_quote.gif 
_I am not for a portable Dap, I would prefer for a desktop Digital "audiophile" player
 with HDD and USB.

 In my opinion, no need to include a DAC, however the system must have connector to connect an external Dac or an nternal alien dac inside the enclosure fro example. It can ba a choice for the diyer. 

 There is a LQFP 144 Universal prototyping boards for sell at http://www.poscope.com/ (click on product PoTQFP)

 You have mentionned the MCF5250, it seem that it is no longer manufactured (?), but the Sfc5250 can handle Flac and has USB. 
http://media.freescale.com/phoenix.z...794&highlight=_

 

You're right, sorry about that, I can't ever get scf and mcf straight! I mean scf5250, and if I slip up again and say mcf5250, i still mean scf5250 =)

 I haven't gotten to review the details of the USB built-in to the scf5250 (I really can't stand reading datasheets online, and I'm waiting for freescale to ship them on paper), but I get this feeling it only has low-speed USB. We might need an external chip to handle the hard drive access (I know most of the dap schematics I looked at used one).

 I'll look into that prototyping board and I'll see if it's necessary. I'm currently working on a high speed, high accuracy pcb etching system, so I might even make a prototyping board myself =) BTW, sparkfun just posted a tutorial on surface mount. Watch the video; these guys are amazingly fast! scroll to the bottom with the qfp(?) IC

 Since the scf5250 has a built-in SPDIF out, a digital output would be relatively easy to implement, if desired. I'm don't know about the audiophile design constraints when it comes to SPDIF, however, and I suspect an onboard SPDIF transceiver might not be good enough.

 Also, a side note--currently, if we're going to use the scf5250 chip, since the bdm module is so cheap, I might be able to design it onboard--that way, you can easily plug in the DAP and reflash the firmware if something seriously goes bad or even debug/customize/modify/create your own firmware.

 just caught an error from before--if anyone wants to be nitpicky, I meant OLED, not OLCD


----------



## error401

Quote:


  Originally Posted by *threepointone* /img/forum/go_quote.gif 
_I haven't gotten to review the details of the USB built-in to the scf5250 (I really can't stand reading datasheets online, and I'm waiting for freescale to ship them on paper), but I get this feeling it only has low-speed USB. We might need an external chip to handle the hard drive access (I know most of the dap schematics I looked at used one)._

 

The SCF5250 doesn't have USB at all (host or device), though it does have pretty much everything else that would be required. There's an onboard ATA controller (for CF or IDE) that just needs a bus buffer, so hard disk access should be relatively trivial. Flash is easy too: there's an onboard SD/MS controller. Toss in a few DMA channels, a fast 68K CPU, tons of available GPIO and possibly built-in I2S and this looks like the perfect chip for this application. You'll probably need external RAM though, but with 16MB costing around $2 I don't think this is a big deal, aside from the extra routing/difficult soldering required.

 Even though this sounds simple, I don't think it will be. You've still got to integrate quite a few major components (at the very least, SoC, storage and DAC) off-chip, as well as figure out all the onboard components.

 I'm not so sure that starting from scratch is the best way to go about the software though. RockBox is all C except for the optimized decoders (and I believe there are C fallbacks for architectures that don't have optimized code), and thus should be relatively easy to cross-compile. It's also (now, anyway) well set up for porting, from what I've seen it's fairly easy to add a new arch. The biggest problems seem to be getting the data format for the LCD correct, the rest mostly seems to be just mapping the registers in the header files.

 Another option would be to start with uClinux and write drivers for all the integrated hardware that isn't already supported (and that's needed, which shouldn't be much, it looks like most of it already works). This really shouldn't be too hard to do, and you then have access to most Linux software. Implement /dev/dsp, and you're set as far as basic functionality goes. Then you just need to write a user interface, profile code and rewrite the core decoder loops in 68k assembly and you're golden.

  Quote:


 Also, a side note--currently, if we're going to use the scf5250 chip, since the bdm module is so cheap, I might be able to design it onboard--that way, you can easily plug in the DAP and reflash the firmware if something seriously goes bad or even debug/customize/modify/create your own firmware.

 just caught an error from before--if anyone wants to be nitpicky, I meant OLED, not OLCD 
 

As was mentioned, this chip can boot directly from attached memory on the bus, or even from IDE. Probably a bit of extra work to figure out how the image needs to be configured, but likely worth it for ease of testing. You'd have to read the programming manual to decide if this is feasible or not, but I suspect it is. Much cheaper to mass produce with a little ROM bootloader that boots from Flash than it is to program the big SoC for every unit sent out.


----------



## threepointone

Quote:


  Originally Posted by *error401* /img/forum/go_quote.gif 
_As was mentioned, this chip can boot directly from attached memory on the bus, or even from IDE. Probably a bit of extra work to figure out how the image needs to be configured, but likely worth it for ease of testing. You'd have to read the programming manual to decide if this is feasible or not, but I suspect it is. Much cheaper to mass produce with a little ROM bootloader that boots from Flash than it is to program the big SoC for every unit sent out._

 

I thought this was more of a DIY project rather than a complete ready-made product. The built-in BDM was really kind of in the DIY philosophy--allow anyone to easily modify the firmware as they wished without hardware getting in his/her way. Of course, to lower costs, not everyone has to install the ICs for the BDM if they didn't want to, and I could send off boards with preflashed EEPROMs (ROM seems so. . .anti-DIY, and I don't know if we'd ever have enough volume for a custom ROM to be worth it) so that no programming is necessary at all.


----------



## error401

Quote:


  Originally Posted by *threepointone* /img/forum/go_quote.gif 
_I thought this was more of a DIY project rather than a complete ready-made product. The built-in BDM was really kind of in the DIY philosophy--allow anyone to easily modify the firmware as they wished without hardware getting in his/her way. Of course, to lower costs, not everyone has to install the ICs for the BDM if they didn't want to, and I could send off boards with preflashed EEPROMs (ROM seems so. . .anti-DIY, and I don't know if we'd ever have enough volume for a custom ROM to be worth it) so that no programming is necessary at all._

 

Oops, that wasn't what I meant at all, sorry to be unclear. I was just trying to infer that it should be easy to boot from an EEPROM. Since it would be cheaper to use a preprogrammed ROM on the assembly line than programming every ColdFire there must be a facility to do so. I think the benefits translate to DIY as well, though if the BDM is indeed that simple, it may make sense to include it.


----------



## louilouinovo

Quote:


  Originally Posted by *error401* /img/forum/go_quote.gif 
_The SCF5250 doesn't have USB at all (host or device),_

 

Doc AN2645 (freescale) explain how "Interfacing the Philips™ ISP1362 USB OTG
 Controller to the MCF5249, SCF5249, SCF5250"


----------



## threepointone

Quote:


  Originally Posted by *louilouinovo* /img/forum/go_quote.gif 
_Doc AN2645 (freescale) explain how "Interfacing the Philips™ ISP1362 USB OTG
 Controller to the MCF5249, SCF5249, SCF5250"_

 

What we meant is that the scf5250 doesn't have USB with its chip. This document describes how the ISP1362, a separate chip, can be used to enable USB on the SCF5250. I just happen to come across that link a couple of minutes ago, but thanks for the tip anyway.

 When it comes to USB, I think the best choice would be a NXP (phillips) IC--they seem to be the best at this sort of stuff. We can use the ISP1362, which is what the H3xx uses and what freescale has data on, or we could try the ISP1760, which is a full USB Host controller and probably the fastest USB chip there is for this type of application. If we're lucky, the ISP1760 shouldn't be much different than the ISP1362.

 This application note might be somewhat useful to rockbox too--I think they've been trying for a while to get USB OTG working on the rockbox, and they seem to have been unable to find out how the isp1362 was connected to the uC. gonna drop a note there. . .


----------



## Danielj

In regard to the screen for of diy dap...those cheap oleds sound fine to me. The simplest easy to read, backlit is all that is needed imo in that this is an audio player not a video player. keep up the good work guys! Just hope that when the time comes I can afford the kit


----------



## marksk

very interesting thread. i'd like to see a unit that is compact and can record cd quality wav to a minimum, saving to either an sd card or mini hard drive.


----------



## Cauhtemoc

Neither of those devices will work. The ISP1362 supports 12 Mbit transfer only, this is not enough if you are going to transfer some 40 GB of music. The ISP1760 is a host controller only, it will not work as a peripheral controller. Take a look at the ISP1582 instead, it's a peripheral controller with support for 480 Mbit transfers. It is only availible in QFN package however, which isn't very DIY friendly.

 Another alternative is the Cypress CY7C68300A, which is a USB to IDE bridge. Basically you just connect it between the hard drive and an USB port and your set. It also has an IDE disable pin which disables (high Z) the IDE interface so that it can be used by other devices. You simply monitor the USB port with the processor, and when someone connects an USB cable the processor stops using the bus and hands over the control to the CY7C68300A.


----------



## threepointone

Sorry, my fault--I used to own an iriver and I always got the impression that it was full speed. I got confused with the ISP1761 and ISP1760; the ISP1761 is capable of using one peripheral port and two host ports. Someone mentioned previously that they wanted the DAP to be able to connect to an external hard drive, so it would need host capabilities. I haven't really done all the research on how difficult that would be, so this is of course all preliminary. The Cypress controllers don't seem to be the easiest to obtain for DIYers; the CY7C68300A has a minimum quantity of 468 at digikey. However, I'll look around and maybe there will be something that has a reasonable minimum quantity.

 On surface mount--I've decided that for a project of this complexity, it's really just time to forget about looking for THM parts only. The only thing I'm avoiding is BGA packages, which are truly impossible to solder without either a special protoboard (I think schmartboard sells one) or toaster oven reflow. Anyway, chips are slowly becoming surface-mount only, and I really think DIYers must keep up and not limit themselves to the ever-shrinking supply of THM parts. I may have some boards presoldered onto adapters, if necessary, or distribute some parts needed for surface mount soldering, like tweezers or solder wick or something

 If anyone wants to prep themselves for a lot of SMT, there's a nice tutorial here: http://www.sparkfun.com/commerce/pre...7-SMDSoldering

 <edddddit>
 We'd better spec the whole project before going too far ahead. Here's all the components of the DAP we'll have to think about.

 a) *USB *- will this DAP have host capabilities, i.e. you can plug in an external hard drive? might be difficult to implement in software
 b) *DAC/Audio *- this is the most important point, and we haven't really considered it at all. What DAC do we use? should we integrate an existing DAC design, and if so, which one? What outputs? XLR/Balanced, RCA/Unbalanced, 1/4", or a combination of those? Should there be an SPDIF Out (there's an SPDIF module built-in to the scf5250)? Would that SPDIF module be "audiophile" enough?
 c) *Power supply *- TREAD @ 5V, maybe? 2.5" notebook drives need .6A peak, ~.1-.2A idle @5V; for the absolute worst case scenario let's assume the whole system might use 1.5A @ 5V. Messing around a bit with tangent's calculator, this seems doable without having to go to switching regulators, but things might get a bit tighter with the heatsink required. We'll also need a 3.3V regulator for much of the logic--I think one of those REG10x-3.3's used in the alien DACs should work.
 Also, I need to clarify again--will there be space for batteries for somewhat-portable use?
 d) *RAM *- nothing special, I picked out the MT48LC16M16A2 4x16x4 SDRAM from Micron, which should be sufficient for anything we throw at it. Micron's RAM is also pretty readily available to DIYers from digikey.
 e) *EEPROM *- nothing special again, I'll just pick something from issi/atmel/microchip
 f) *IR *- I don't know how people are going to use it, but if this is going to be a sort of desktop/audio system standalone DAP, we might want to stick an IR sensor for remote control
 g) *controls *- plain old tactile buttons + rotary detector switch? or something a bit nicer like capacitative touch sensors (pretty readily available and pretty easy to use, though more complicated than plain ol' switches--cypress, analog devices, QProx all make ICs)
 h) *display *- I heard two votes for OLED. IIRC, they need a bit more circuitry to drive them--I have to double check to see how much we'll have to do with the models at digikey
 just checked, OLED seem to need a 18V supply. Unless you don't mind two wall-warts, I think it might be necessary to stick a switching driver somewhere in there. Don't know if any of you might mind.
 here's digikey's selection of oleds:
http://dkc3.digikey.com/PDF/T072/P2140.pdf
 another potential problem: OLEDs don't exactly last that long. Some of them I looked at were rated only to 10,000 hours @ 25*C

 g) *firmware *- rockbox, completely custom firmware, or uClinux. I'm gonna be honest, I'm not very experienced with linux so if we're using uClinux I'm probably not doing the software for it
 h) *hard drive *- I think we've gone over this already. 1.8" is too hard to obtain and doesn't hold enough, 3.5" is too big and uses too much power--2.5" seems to be the best candidate
 i) *casing *- the standard nice metal cases from hammond? we might also need some custom front panels to handle the buttons / display cutout and such. Now that I think about it, 8x5 is pretty big, and probably wouldn't do any good as a portable (even in a bookbag, imo)--are we entirely dropping any portable use from this version of the DAP?
 Tell me if I left anything out. 
 Looks like this might become a pretty expensive project--but heck, this is head-fi!


----------



## Cauhtemoc

Quote:


  Originally Posted by *threepointone* 
_a) *USB *- will this DAP have host capabilities, i.e. you can plug in an external hard drive? might be difficult to implement in software_

 

Host capability is pretty much useless and would only complicate the design.

  Quote:


  Originally Posted by *threepointone* 
_b) *DAC/Audio *- this is the most important point, and we haven't really considered it at all. What DAC do we use? should we integrate an existing DAC design, and if so, which one? What outputs? XLR/Balanced, RCA/Unbalanced, 1/4", or a combination of those? Should there be an SPDIF Out (there's an SPDIF module built-in to the scf5250)? Would that SPDIF module be "audiophile" enough?_

 

The Wolfson WM8740 holds my vote as the best DAC, followed by the Crystal CS4398. The WM8740 should ideally be operated in mono diffrential mode however, which requires one DAC per channel. This doubles the size and power usage, both of which are undesirable in a portable player. The CS4398 is probably a better choice, it's also easier to get ahold of ($8 from DigiKey).

 I've also heard some good things about the Analog Devices AD1955. However it has a current output and would require an external I/V converter which takes up space and increases power usage.

  Quote:


  Originally Posted by *threepointone* 
_c) *Power supply *- TREAD @ 5V, maybe? 2.5" notebook drives need .6A peak, ~.1-.2A idle @5V; for the absolute worst case scenario let's assume the whole system might use 1.5A @ 5V. Messing around a bit with tangent's calculator, this seems doable without having to go to switching regulators, but things might get a bit tighter with the heatsink required. We'll also need a 3.3V regulator for much of the logic--I think one of those REG10x-3.3's used in the alien DACs should work._

 

This is the least of your worries.

  Quote:


  Originally Posted by *threepointone* 
_d) *RAM *- nothing special, I picked out the MT48LC16M16A2 4x16x4 SDRAM from Micron, which should be sufficient for anything we throw at it. Micron's RAM is also pretty readily available to DIYers from digikey._

 

Bear in mind that the SCF5250 only supports 32 MB ram.

  Quote:


  Originally Posted by *threepointone* 
_e) *EEPROM *- nothing special again, I'll just pick something from issi/atmel/microchip_

 

Better yet is to load the firmware straight from the IDE hard drive. It also has the added advantage of allowing anyone to update the firmware from the USB port.

  Quote:


  Originally Posted by *threepointone* 
_f) *IR *- I don't know how people are going to use it, but if this is going to be a sort of desktop/audio system standalone DAP, we might want to stick an IR sensor for remote control_

 

Useless and would only complicate the design.

  Quote:


  Originally Posted by *threepointone* 
_g) *controls *- plain old tactile buttons + rotary detector switch? or something a bit nicer like capacitative touch sensors (pretty readily available and pretty easy to use, though more complicated than plain ol' switches--cypress, analog devices, QProx all make ICs)_

 

Start with simple tactile buttons and a rotary detector. Touch controls would be very cool but also very complicated.

  Quote:


  Originally Posted by *threepointone* 
_h) *display *- I heard two votes for OLED. IIRC, they need a bit more circuitry to drive them--I have to double check to see how much we'll have to do with the models at digikey
 just checked, OLED seem to need a 18V supply. Unless you don't mind two wall-warts, I think it might be necessary to stick a switching driver somewhere in there. Don't know if any of you might mind.
 here's digikey's selection of oleds:
http://dkc3.digikey.com/PDF/T072/P2140.pdf
 another potential problem: OLEDs don't exactly last that long. Some of them I looked at were rated only to 10,000 hours @ 25*C_

 

LCD displays are one of the only things you do not get from Digi-Key. This is the perfect candidate.

  Quote:


  Originally Posted by *threepointone* 
_g) *firmware *- rockbox, completely custom firmware, or uClinux. I'm gonna be honest, I'm not very experienced with linux so if we're using uClinux I'm probably not doing the software for it_

 

Start with a very simple firmware that only plays .wav files. Once the hardware is up and running you can look at porting something like Rockbox.

  Quote:


  Originally Posted by *threepointone* 
_h) *hard drive *- I think we've gone over this already. 1.8" is too hard to obtain and doesn't hold enough, 3.5" is too big and uses too much power--2.5" seems to be the best candidate_

 

Like I've said from the beginning, 2.5" IDE harddrives are perfect for this. 40 GB costs around $50 and holds over 400 songs.

  Quote:


  Originally Posted by *threepointone* 
_i) *casing *- the standard nice metal cases from hammond? we might also need some custom front panels to handle the buttons / display cutout and such. Now that I think about it, 8x5 is pretty big, and probably wouldn't do any good as a portable (even in a bookbag, imo)--are we entirely dropping any portable use from this version of the DAP?_

 

I don't see it as entirely impossible to fit everything on a circuit board about the same size as a 2.5" harddrive. With batteries it might be possible to get everything about the same size as three 2.5" harddrives stacked on top of eachother. This would not be much larger than the original iPod.


----------



## louilouinovo

I take a close look to the oryx, it is a diy dap project.






 Other images: http://www.oryxmp3.com/fr/oryx2/photos.php

 you need nearly 200 components to make the oryx
 It cost 170 euros without enclosure, 128 x 64 LCD module and some other component that I was not able to find . except the enclosure you need to have a HDD to play music.

 The mainboard (include in the price) is at 36,5 euros and the front panel pcb is 25 euros.

 It is based on an ATMEGA128L (Microcontroller), Sta013 (mp3 decoder), PCM1702 (DAC) and CY7C68013A (USB)


----------



## Cauhtemoc

A quick tally on the parts discussed above:

  Code:


```
[left]Freescale SCF5250$12 Crystal CS4398$8 Cypress CY7C68300A$4 Micron MT48LC16M16A2 $7 Nokia LCD$20 2.5" hard drive$50[/left]
```

This comes in at just below $100, and this is everything except the circuit board, switches, resistors, capacitors and various other minor parts.


----------



## threepointone

I think this DAP isn't exactly going to be portable. We'll just focus on the audio quality for this model--remember, this is head-fi after all, and the main differentiating part of this DAP is that it's targeted to us audiophile freaks.
 in my experience, the most expensive part of an audiophile system ends up being the excessively nice casing and some of the audiophile parts. I've thought, "wow, this amplifier is going to be pretty cheap" many times before I started on an audiophile project, and the casing / connectors / capacitors (*cough* black gate) easily end up becoming the most expensive part of the project.

 I'm going to need more opinions on the DAC section, and I'll probably post a new thread on it. There's a funny way things in the audiophile business are completely independent from the specs. . .

 The Oryx looks nice, but there's one main problem with it that I've never liked about every DIY DAP I've seen so far--they all use some sort of integrated decoder IC. The Oryx is incapable of playing anything but MP3s, and worse yet, it's not capable of being expanded to play anything but MP3s.

 OLEDs seem to be exception with LCDs--the only place I can find good ones is digikey. Color LCDs, of course, are far too expensive at digikey--sparkfun is definitely an excellent source

 Also, where does the 32MB number come from? Is it 32MBit or 32MByte? Looking at one other DAP based on this IC, the SCF5250 should be able to handle at least 128MBits of RAM (16MB, 2x16x4). Some SCF5249-based DAPs, which should be quite similar, have 256MBits of RAM. If you meant 32MB, what I chose is the maximum we can use (4Mx16bitx4banks = 256MBit = 32MB). I've always seen this first version as a bit of a prototype, so I'd prefer overspec'ing on the hardware so that the software does not become limited by the hardware.

 The EEPROM--unless I'm missing something here, we need something to put the bootloader off of. The SCF5250 has no built-in flash memory, if I'm not mistaken

 Now that I think of it, I have to agree that it's probably is best to start with a very basic firmware that plays WAVs only. We need some way to test all the hardware before advancing to something more complex.

 Touch too is probably not necessary for a unit that's not portable. I guess we'll just go with rotary/tactile switches. 

 IR - I'll see if there's any more opinions on this. it shouldn't be _too_ difficult to implement, as I've already done this before with interrupts on the PIC before.

 USB - The host probably will be too complicated. I'll drop it, at least for the first version. I might consider having a host controller onboard anyway without the software to support it, if I ever have time in the future to implement it. I'll have to consider how much more difficult it might be to operate the ISP1761 instead of the CY7C68300A, though.

 Again, I have to ask--where do we source the CY7C68300A? It has a minimum order quantity of 468 at digikey. In fact, it's actually an obsolete item now, and I'd really rather not have to change the whole design in three months just because we can't obtain anymore of that chip. [edit]just checked all the distributors, no stock / obsolete across the board. if we call them we might get lucky, but probably not at the small quantities we'll use.[/edit] I'm going to look at some other high speed USB peripheral--maybe cypress has a similar replacement

 Thanks for your comments!

 Also one more thing to consider
*flash memory* - is there any interest in a SD card slot? we do have built-in SD on the scf5250. Naturally, it'll also add to the complexity, but I mean if someone really wants it. . .


----------



## gates_2

Quote:


  Originally Posted by *threepointone* /img/forum/go_quote.gif 
_I think this DAP isn't exactly going to be portable. We'll just focus on the audio quality for this model--remember, this is head-fi after all, and the main differentiating part of this DAP is that it's targeted to us audiophile freaks._

 

Good idea, Keep in mind you can always start large, get it working, then in subsequent revisions work on reducing the size

  Quote:


 I'm going to need more opinions on the DAC section, and I'll probably post a new thread on it. There's a funny way things in the audiophile business are completely independent from the specs. . . 
 

CS 4398 is a great DAC chip, price seems right too. I'd vote for this.


  Quote:


 Now that I think of it, I have to agree that it's probably is best to start with a very basic firmware that plays WAVs only. We need some way to test all the hardware before advancing to something more complex. 
 

Again, excellent idea. Start simple, then expand. Fortunately for us, with WAVs you will be getting the highest SQ possible from the start.

  Quote:


 IR - I'll see if there's any more opinions on this. it shouldn't be _too_ difficult to implement, as I've already done this before with interrupts on the PIC before. 
 

Eventually it would be cool to see this implemented. I know that stand-alone IR remote control units get expensive for DIY'ers, but with the microcontroller already a part of the design, might be something to consider(probably after the sound works eh 
	

	
	
		
		

		
		
	


	




 )



 Oh, also, I'm not sure if I fully understood what you were saying above, but will the firmware be flash-upgradable via the USB? Keep in mind that many of us who decide to do this project do not own PIC programmers, and thus, every time a revised firmware is released, couldn't update it. Thoughts?


 Unfortunately, my ECE(electrical-computer engineering) skills are virtually non-existant. I'd be interested in helping out with the prototyping though.


----------



## labmat

Quote:


  Originally Posted by *threepointone* /img/forum/go_quote.gif 
_b) *DAC/Audio *- this is the most important point, and we haven't really considered it at all. What DAC do we use? should we integrate an existing DAC design, and if so, which one? What outputs? XLR/Balanced, RCA/Unbalanced, 1/4", or a combination of those? Should there be an SPDIF Out (there's an SPDIF module built-in to the scf5250)? Would that SPDIF module be "audiophile" enough?_

 

I think SPDIF out is a must; this will allow you to use a standalone DAC if you want.


----------



## Cauhtemoc

Quote:


  Originally Posted by *threepointone* 
_Also, where does the 32MB number come from? Is it 32MBit or 32MByte? Looking at one other DAP based on this IC, the SCF5250 should be able to handle at least 128MBits of RAM (16MB, 2x16x4). Some SCF5249-based DAPs, which should be quite similar, have 256MBits of RAM. If you meant 32MB, what I chose is the maximum we can use (4Mx16bitx4banks = 256MBit = 32MB). I've always seen this first version as a bit of a prototype, so I'd prefer overspec'ing on the hardware so that the software does not become limited by the hardware._

 

The 32MB number is from the datasheet for the SCF5250:

  Quote:


 The SCF5250 SDRAM controller provides a glueless interface for one bank of SDRAM up to 32 MB (256Mbits). 
 

I remember reading 256M in the datasheet for the MT48LC16M16A2 and for some reason I assumed this to be in bytes. I stand corrected however, the MT48LC16M16A2 would be an excellent match for the SCF5250.

  Quote:


  Originally Posted by *threepointone* 
_Again, I have to ask--where do we source the CY7C68300A? It has a minimum order quantity of 468 at digikey. In fact, it's actually an obsolete item now, and I'd really rather not have to change the whole design in three months just because we can't obtain anymore of that chip. [edit]just checked all the distributors, no stock / obsolete across the board. if we call them we might get lucky, but probably not at the small quantities we'll use.[/edit] I'm going to look at some other high speed USB peripheral--maybe cypress has a similar replacement_

 

The latest version would be the CY7C68300C. It too appears out of stock however. An USB controller like the ISP1582 might be the only choice here.


----------



## error401

Quote:


  Originally Posted by *Cauhtemoc* /img/forum/go_quote.gif 
_Better yet is to load the firmware straight from the IDE hard drive. It also has the added advantage of allowing anyone to update the firmware from the USB port._

 

This is probably rather non-trivial. I don't know how easy (or possible) it would be to have the firmware be a 'file' on a standard FAT32 hard drive. I think even if you wanted to load the firmware over IDE you'd either need to have your own on-disk data format (which means PC access would be difficult, and a lot more software work), or have a bootloader that implements FAT32 and grabs the code into memory. Not positive about this though, there might be enough room in the boot sector for the necessary bootloader - or there might not.

 I do agree that the firmware itself should be stored on disk rather than in the EEPROM. The bootloader itself should stay fairly static and not require updates once debugged.

  Quote:


 IR:
 Useless and would only complicate the design. 
 

IR is pretty trivial from a hardware perspective. The photodetector module needs power and a GPIO - everything else is software (assuming you don't want to do this with a bare phototransistor - but why bother - IR modules are cheap - and even then it could be done with a couple extra low pincount parts). There's not really any reason not to design the hardware around the assumption that this will be a feature. Software side shouldn't be too hard either, there's a wealth of available code and information on decoding IR remotes.

  Quote:


 Start with a very simple firmware that only plays .wav files. Once the hardware is up and running you can look at porting something like Rockbox. 
 

I'm going to change my mind and agree with this. Probably better to write a simple firmware yourself and learn how the hardware works and is interfaced together before porting an existing app. You'll also then have a known working codebase to start from for your porting efforts.

 I just had a thought about host capability as well. If you're okay with the non-DIYness of it, it would probably be pretty easy to rip the electronics out of an IDE-USB enclosure (or find the ICs - I bet this is what that cypress chip is for - there are probably others) and either add a Hi-Z bus buffer (or if the chip has the feature, pull it off to a GPIO on the CPU) or a switch to enable it. Flick the switch or press the button and the drive moves to the USB bus for access from the computer. Switch it back and the DAP can see it again. Fairly inelegant compared to implementing the host on the chip, but totally workable and easy to integrate. Unnecessary complication for a first rev tho.


----------



## threepointone

rockbox uses a bootloader (pretty stable, too; I'm pretty sure it hasn't been updated in a while) in the EEPROM which loads off the rest of the firmware from the hard drive, so it should be doable and we'll have something to base our bootloader off of.

 Just to clarify, we will still need an EEPROM for the bootloader, but not the rest of the firmware. In fact, if the firmware becomes complicated enough, I'm not even sure if it'd fit in the EEPROM--I know rockbox doesn't.

 I'm quite sure we're not putting USB host in the first versions of this DAP. I'm still thinking about whether or not we should base the USB on a chip that's capable of USB host (and do the code for host functionality later) or if we should just use a plain USB peripheral controller (and require a new board for USB host functionality).

 I'm not exaclty understanding the point about the USB/IDE thing--USB host is when you can plug in an external hard drive into the DAP. If you're talking about an easy way to multiplex the internal hard drive between the computer and the DAP, the recommended CY7C68300 by Cauhtemoc seems to be the most straightforward way to do this--unfortunately, digikey doesn't sell it in <1k quantities


----------



## error401

Quote:


  Originally Posted by *threepointone* /img/forum/go_quote.gif 
_I'm not exaclty understanding the point about the USB/IDE thing--USB host is when you can plug in an external hard drive into the DAP. If you're talking about an easy way to multiplex the internal hard drive between the computer and the DAP, the recommended CY7C68300 by Cauhtemoc seems to be the most straightforward way to do this--unfortunately, digikey doesn't sell it in <1k quantities_

 

Of course. My brilliant idea turns into a brain fart. I guess that's what I get for trying to think in the last minutes of a long day at work...

 It would probably be a cheap/easy way to get access to a USB->IDE bridge though-or 1394 even, but certainly less elegant than putting the Cypress onboard.


----------



## threepointone

Alright, I did a bit more research with the USB controller. If we want host capabilities (eventually, I don't mean in the first version of the software), we should probably try the ISP1761--according to its datasheet, the peripheral capabilities on the chip are the same as the ISP1582. The ISP1582 would need more work than a simple usb-to-ata bridge, but rockbox supports a player with that chipset so there's some example code to build on. 

 Or if we want to completely drop host capabilities from the first revision of the hardware, we can try looking at cypress' usb-to-ata bridges. Looking into their site, they've actually got a couple of more different models; I'm about to go to sleep now, but you'll want to look into the CY7C68301C, CY7C68320C, and CY7C68321C. They might not work, as I've just glanced at their specs so far. If someone wants to do some hunting, find a distributor that stocks CY7C68300C in reasonable multiples. 

 Argh, actually I did a quick digikey search and none of them are stocked by digikey and have a minimum quantity of at least 200 or so. Unless someone can find a good source, I think we're going to end up going for the ISP1761. A bit more work at first, but at least we'll be able to do usb host in the future.


----------



## Cauhtemoc

All of the ones you mentioned are essentially the same. The best I have been able to find is the CY7C68300B which has a minimum quantity of 56 from Digi-Key.

 The ISP1582 is probably your safest bet however. It is cheap and will not go obsolete for a long, long time. It's not too difficult to create a mass storage device.


----------



## utilisateur

unfortunately i dont have much to contribute on the technical side
 but
 I think the development focus should be put on the digital out with the minimum goal of a DIYable DAP with multiplexd digi out up to atleast 24/96 ?
 Wouldn't that mean a buffer and nice clock needs to be added ?
 What about the SDPIF transmitter ICs are they worth feeding a lowjitter clocksignal and can those integrated linedrivers be used?


 sofar
 2,5" HDD as storage
 wav decoding 
 I²S output to 
_ (so that's all done by that MCF 525??)_

 (AK4115 AK4103 CS8406 DIT4096 anything else out there?)


----------



## threepointone

I'll do another thread for the audio section. The first version of the firmware indeed will probably be something really simple, maybe just a WAV decoder. If it turns out to be not too difficult, there is a possibility that FLAC decoding will also be in the first version, or maybe even rockbox. Since this will be programmable by replacing a firmware file on the hard drive (or possibly some other means), we can easily release a more advanced firmware for the DAP later on without any modification to the hardware.


----------



## louilouinovo

I take a close look to the evaluation board M5249C3 and the Audio daughter board.

 I have done a list of the main components not the resistor, connector, jumper, capacitor... 


M5249C3 evaluation board

 *Audio Interfaces
 U19: AK4360: 20-bit DAC with built-in headphone amplifier
 U1: AK5353vt : 96kHz 24BIT ADC WITH SInGLE-ENDED INPUT

 *M5249
 U2: ColdFire MCF5249
 *10/100baseT Ethernet Port & Magnetics
 U4 : SMSC LAN91C111-NE: 10/100 Non-PCI Ethernet Controller with Coldfire supports 
 T1 : HALO TG110-S050N5 or N2 : 10/100 High Speed LAN Magnetics Isolation Modules
 U5 : ispGAL22LV; lattice SPLD Programmable Logic Devices

 *Flash & SDRAM memory
 U6 : AM29LV160DB90EC 1Mx16bit AMD Flash memory 
 U7 : K4S641633D 4Mx16bit SAMSUNG SDRAM memory 

 *Power Supply, Reset & Clock Oscillator
 U18: TLC7733ID TI Supervisory Circuits 2.93V
 U9 : MAX6355LSUT-T Maxim Triple-Voltage µP Supervisory Circuits
 U10 :NC7SZU04: Fairchild single unbuffered inverter
 U11 LM2596S-3.3 National Semiconductor Power Converter 
 U8 : LT1086CM Linear Technology 1.5A Low Dropout Positive Regulators

 *RS232 Serial, I2C & QSPI Interfaces
 U13: MAX3225CAP : RS232 Transceiver.
 U14: MAX3225CAP : RS232 Transceiver.

 *IDE Interface
 U16: MC74LCX16245DT : Motorala Low-Voltage CMOS 16-Bit Transceiver
 U17: MC74LCX16245DT : Motorala Low-Voltage CMOS 16-Bit Transceiver

Audio Daughter Board 
 *Audio: (dac and amp)
 T1: TTWB1010 : Surface Mount Wideband RF Transformer 
 T2: TTWB1010 : Surface Mount Wideband RF Transformer 
 U7A: Hex inverter
 U7B: Hex inverter
 U7C: Hex inverter
 U7D: Hex inverter
 U7E: Hex inverter
 U7F: Hex inverter
 DCDC1 : NMA0512S : single-in-line package DC/DC Converters 5v/12v
 U4: OPA2134/SO : Op amp 
 U6: OPA2134/SO : Op amp 
 U10: GP1FA550TZ : Fiber Optic Transmitter-Receiver
 U8: GP1FA550RZ : Fiber Optic Transmitter-Receiver
 U3: AK4393 : 96khz 24 bit Dac
 U5: AK4393 : 96khz 24 bit Dac

 *Flash Media Interface (simple)
 J9 : FPS009-2203-10 : SD Card and MMC Reader
 J10 : Memory Stick

 *Trio interface (it contains lcd and switches to navigate inside the data)
 LCD1: PSG7955AW-SGR alm Technology lcd module
 U9 : LM339d : QUAD DIFFERENTIAL COMPARATORS

 *USB Interface
 u1 :ISP1362 :Single-chip Universal Serial Bus On-The-Go controller 
 U2: MIC2026 : Dual-Channel Power Distribution Switch

 *CD Interface Adapters
 Connector only


Software Features
 • Audio CD playback
 • MP3 playback (MPEG-1 Layer 3 and MPEG-2 Layer 3 with lower sampling rates)
 • WMA playback (high rate, mid rate and low rate)
 • WAV file playback (16- or 8- bit linear samples; sampling rates supported same as for MP3 and
 WMA)
 • CD-DA, CD-R, CD-RW and CD-ROM discs
 • 12 cm discs
 • ISO-9660 Level 3 file system with Joliet extension
 • ISO-9660 Joliet format for Macintosh
 • UDF file system, version 1.5, with fixed and variable packets
 • Multi-session discs (up to five sessions)
 • Mixed discs (data and audio tracks)
 • Copy-protected CD-DA discs
 • Display of ID3 tags V1.1, V2.2, V2.3, V2.4
 • Disc start-up retry (for open discs and discs with errors)
 • Servo switch-off after filling up internal buffer
 • Basic player controls
 — Play/Pause/Stop
 — Next track/Previous track
 — Fast forward/Rewind
 — Digital Volume Control
 — Hold (disable keypad)
 • Track/File programming
 • Flat/Hierarchical/Collapsible file system browsing
 • Playlist
 • Shuffle
 • Repeat (None/One/All/AB)
 • Pre-set 5-Band Graphical Equalizer (Flat/Rock/Classic/Jazz/Ultra bass modes)
 • User Definable 5-Band Graphic Equalizer
 • ESA, with 4X ADPCM compression
 • Intro-Scan
 • Lid Open/Close detect, with player stop on Lid Open
 • Booting from Flash memory
 • Last three file systems stored during power-down in flash memory for quick start-up
 • Resume on power-up with previous settings and playing position
 • Software update from CD
 • Additional displays through Menu
 — Hold/Resume setting
 — Decoder Information (type, sampling rate, bit rate)
 — Time (Elapsed/Remaining time for current track)
 — ID3 and WMA tags display of artist, title, album, genre and year
 • Configurable SSC (sub-code and sector controller) and BFM (buffer and file management)
 •* Easy to add new decoders (e.g., Ogg Vorbis, MP3Pro)* and additional audio post processing (e.g.,
 SRS WOW, QSound Sizzle)


----------



## threepointone

Thanks, I'll look into the evaluation board--might be useful to look at for our design. IIRC, the decoders/firmware from freescale require an agreement to download, and they wouldn't approve me. That was over a year ago that I was researching this, though, so things might have changed. I'm checking right now.

 [edit> yeah, it appears they still need to do some agreement thing with an authorized dealer. forget it.

 BTW, I've split the audio hardware design section to another thread. Post any opinions you have on the DACs, SPDIF and such overthere.


----------



## louilouinovo

The Dap structure will not be far from the evaluation board/daughter board. We just need to clean it up and find some alternative chips.


  Quote:


  Originally Posted by *error401* /img/forum/go_quote.gif 
_Another option would be to start with uClinux and write drivers for all the integrated hardware that isn't already supported (and that's needed, which shouldn't be much, it looks like most of it already works). This really shouldn't be too hard to do, and you then have access to most Linux software._

 

Uclinux can run on the M5249C3. http://www.uclinux.org/ports/coldfire/faq.html

  Quote:


  Originally Posted by *threepointone* /img/forum/go_quote.gif 
_I'm quite sure we're not putting USB host in the first versions of this DAP. I'm still thinking about whether or not we should base the USB on a chip that's capable of USB host (and do the code for host functionality later) or if we should just use a plain USB peripheral controller (and require a new board for USB host functionality)._

 

The ISP1362 has been tested with MCF5249, SCF5249 and SCF5250. The host function is usefull if you want to connect a Portable player to the Dap without the need of a PC. 
 Digikey sell the ISP1362 at $7,10.


----------



## threepointone

The only thing with the ISP1362 is that it's not high-speed capable (so it's limited to 12mbps or so, iirc). It's going to be painfully slow transferring music onto the DAP.


----------



## Cauhtemoc

Quote:


  Originally Posted by *threepointone* 
_The EEPROM--unless I'm missing something here, we need something to put the bootloader off of. The SCF5250 has no built-in flash memory, if I'm not mistaken_

 

I was reading through the datasheet for the SCF5250 when I came across the following:

  Quote:


 *1.2.25 Boot ROM*
 The boot ROM on the SCF5250 serves to boot the CPU in designs which do not have external Flash 
 memory or ROM. Typically this occurs in systems which have a separate MCU to control the system, 
 and/or the SCF5250 is used as a stand-alone decoder.

 The SCF5250 can be booted in one of three modes:

 • External ROM
 • Internal ROM Master mode – boots from I2C, SPI, or IDE
 • Internal ROM Slave mode – boots from I2C or UART 
 

I do not believe an external EEPROM is needed.


----------



## threepointone

Yep I just saw that too. I'm going to see if I can get the IDE bootloader to work--documentation doesn't seem too clear to me. I might see if freescale will provide sample code for the ide bootloader, since there's almost no documentation on their site on it other than one or two pages in the datasheet.


----------



## Cauhtemoc

The datasheet for the SCF5250 contains only information specific to the SCF5250. General information on the ColdFire core can be found in the ColdFire User's Manual.

 You might also want to take a look at the ColdFire Programmer's Reference Manual.


----------



## threepointone

darn, I knew I'd leave something out when I requested the manuals!

 heads up: freescale offers free print-based documentation through http://www2.hibbertgroup.com/freesca...HomeController . Personally I can't stand reading manuals online, so I've requested most of the scf5250 documentation already. I'm not sure if they'll ship outside of the US, unfortunately.


 hey, whoever was thinking about using uclinux:
http://www.freescale.com/files/micro...85.pdf?fsrch=1
 freescale's got their own app note for it. I don't have the eval board, but it sounds like it wouldn't be as difficult as i'd thought to implement it.


----------



## louilouinovo

I thnk the first step is to build your own prototype (the 5249 evaluation board is more than $1000).


----------



## threepointone

arggggh! can't believe I didn't read this earlier. I've gone through most of the scf5250 reference manual, and it seems that the audio outputs (both SPDIF and I2S) are only capable of 20-bit. Personally I don't think 20-bit and 24-bit have much of a difference (iirc the noise floor of almost all systems is higher than what 24-bit can resolve), but it would have been better if it were 24-bit. 

 Although I've already gone somewhat far into the design, I'm still open to any suggestions for another microcontroller. If anyone knows of any I2S interface IC, I'd be interested too. I'd rather not have to put a programmable logic device to do that. I've also been thinking about multiplexing two of the I2S outputs and using a cheap uC or preferably some digital logic to take care of putting the signal back together, but I'm probably just asking for trouble with that. Adapting SPI might also be a possibility, though I think it might take too much processor time. Most likely I'll end up sticking to 20-bit.


----------



## Cauhtemoc

The I2S protocol is not as complicated as you think. All you need to make an interface is three shift registers, a counter and an AND gate. Let me know if you need a schematic.

 I would use a CPLD however, they are not as bad as you think. You can find a couple of ready made I2S interfaces over at OpenCores, or you can make your own.


----------



## kramer5150

interesting discussion...

 I was thinking of something in a non-portable chassis, ~500M capacity (or whatever size drive gives the most G per$), and optical / coax digital output. Could be either wall-wart powered, or have a dedicated P/S. Forget portability, that will drive cost up and audio fidelity down (we already have portable players for that). If it plays lossless files, and has an optical/digital output it could rival a good mid-fi CD deck.


----------



## threepointone

Quote:


  Originally Posted by *Cauhtemoc* /img/forum/go_quote.gif 
_The I2S protocol is not as complicated as you think. All you need to make an interface is three shift registers, a counter and an AND gate. Let me know if you need a schematic.

 I would use a CPLD however, they are not as bad as you think. You can find a couple of ready made I2S interfaces over at OpenCores, or you can make your own._

 

I was just wondering, how are CPLDs be programmed? Can it be easily programmed by a microcontroller? I'd rather not need any external programmers for the system

  Quote:


  Originally Posted by *kramer5150* /img/forum/go_quote.gif 
_I was thinking of something in a non-portable chassis, ~500M capacity (or whatever size drive gives the most G per$), and optical / coax digital output. Could be either wall-wart powered, or have a dedicated P/S. Forget portability, that will drive cost up and audio fidelity down (we already have portable players for that). If it plays lossless files, and has an optical/digital output it could rival a good mid-fi CD deck._

 

So far that's exactly what i'm doing--it'll have spdif output, use a 2.5" hd (up to maybe 200GB or so by now?), wall-wart powered, and play lossless =)

 btw, I split the audio design section here: http://www.head-fi.org/forums/showthread.php?t=248321


----------



## Cauhtemoc

Quote:


  Originally Posted by *threepointone* 
_I was just wondering, how are CPLDs be programmed? Can it be easily programmed by a microcontroller? I'd rather not need any external programmers for the system_

 

Depending on which CPLD you use, a programmer can be as simple as a parallel port, a buffer and a couple of resistor. They're not too dissimilar from the EEPROM programmer I posted earlier.


----------



## threepointone

I've been thinking about the case dimensions, and I made a couple of mockups of some of the hammond 1455 cases (the nice aluminum ones). To me it seems that the 1455Q1601 is probably the best candidate. It's 160mm x 120mm x 30.5mm (~6.3" x 4.75" x 2"), which might seem a bit big but when I made a model it's definitely a reasonable size, especially when compared to other desktop audio equipment. 

 The 2" height gives pretty good clearance for most LCDs and allows enough height for any low-density audiophile power supply caps / heatsink for the linear regulator. It'll also help with the modular design of the DAP, which will probably involve some elevated boards. 2" does actually look a bit high, but it's not as easy to find LCDs for the next shorter hammond case, at about 30mm (really about 27mm actual available height; most LCDs seem to have outlines of <30mm)

 The large amount of board space allows a 2.5" HD to fit pretty snugly on one end and provides enough room to isolate it from any of the audio circuitry. it also gives more room for any modules and the potentially complex audio section in the DAP

 If anyone wants me to, I can post pics of the mockups of the cases / LCDs / HD I made to get an idea of what size the DAP will be


----------



## labmat

Quote:


  Originally Posted by *threepointone* /img/forum/go_quote.gif 
_If anyone wants me to, I can post pics of the mockups of the cases / LCDs / HD I made to get an idea of what size the DAP will be_

 

I'd love to see what you've come up with.


----------



## Danielj

Hi 3.1 Sounds like you are making good progress...would very much like to se mock up pics posted

 keep up the good work
 Dan


----------



## OverlordXenu

I haven't read through this thread, so I don't know if this has been said, but here is my suggestion. As said by the OP, RockBox and a 2.5" laptop harddrive. Since this will be audio, an extremely small monochrome/two-tone/whatever display/LCD, something that will just display song info and directors and the like, low power. Instead of making the device bigger to include a DAC and battery, forget that. Just include an optical out (possibly a built-in high quality cable?), and some terminal so one can use external batteries.

 That would make the device as small as possible, and if someone is a true audiophile, they won't mind having something like a MicroDAC, external amp, and external battery pack.


----------



## Danielj

Hi the OP here...
 So far it seems that first build will be wav only with a 2.5 HD.
 Wallwart type PS so yes an external battery pack would be possible and recommended. The design implies the use of line out, so an external headphone amp or other amp source would be needed. Also implied is an optical out for those who want to use an external DAC; however the design needs to have its own high quality DAC so as to not force the extra expense of an ext. DAC We decided that the internal DAC needs to be of the highest quality possible...this has been a high priority for the design concept. Size of unit has been determined to be less of a priority than quality. transportable but not necessarily portable.

 Of course the particulars on the tech side are still being figured out by 3.1 and the other electro wizards involved in the project. As for myself I am just an end user hoping these guys can come up with something that qualifies as a superDAP


----------



## Danielj

Hi guys....there are some threads in the portable audio forum where folks are discussing the desire for audiophile daps. I pointed them to this thread as i know people are working on this.There hasnt been any recent postings, so how is the research and development going on this project?
 thanks Dan


----------



## threepointone

been a bit busy and it's been slow--came back from vacation a short while ago. a couple of friends of mine said they'd start working on it with me after they come back from vacation in a couple of weeks, so it might speed up. Unfortunately, it's going to be quite a while before something solid comes out. atm I'm waiting for a digikey order to come in and then I can start working on the digital section,.

 So far, here's the plan:


*basics:*
 - modular design (probably storage module, microcontroller module, USB module, user interface module, and DAC/SPDIF module). This will ease development, debugging, soldering, and allow for customizability. For now I'm using SIP sockets, but later I'll look for something that takes up less space and might be a bit nicer in terms of the parasitics
 - onboard diagnostic debug lights (after looking at how many connections there are on the board, this would be pretty darn necessary for debugging)
 - (might be removed if I end up needing more board space for everything else) optional built-in BDM programmer for myself and developers for easier debugging
 - (might, but probably won't, change) hammond 1455Q1601 case (about 6"x5"x2"--a bit thick, but personally I think the LCD would have to be too small otherwise)
 - scf5250 microcontroller, as discussed before
 - basic eeprom-based bootloader (more fail-safe than a hard drive based bootloader, at least during initial development)

*Basic modules:*
 - storage: 2.5" HD
 - USB: ISP1561 / cypress peripheral controllers for the USB (depends on whether or not I can get samples)
 - DAC: WM8740 (digits might be mixed up) for the DAC. I might even use something simpler--the DAC board is modular, anyway, so it doesn't really matter what I stick in here for the first revision.
 - SPDIF: directly from the scf5250, with a simple reclock circuit
 - user interface module: bunch of tactile play/pause/stop switches, and a simple graphic LCD. I would have gone for an OLED, but it appears that some serious problems are cropping up with supply--optrex, one of the most accessible suppliers of OLED screens, just completely pulled out of the display market. digi-key is only stuck with a couple if tiny OLED modules left in inventory and most other OLED module manufacturers have discontinued their lines. Sparkfun does have a color OLED available from a different OLED screen, but it's a bit more complicated than necessary (color screen) and a bit smaller than I was hoping for. If anyone knows somewhere I could get a monochrome (or grayscale) OLED with a module size of around 60mmx45mm-ish, tell me!


*Things on hold for future revisions of the board (i.e. "feature creep" section):*
 - ultra-low jitter clocking - I've figured out some way to get less jitter than probably anything available commercially. It's pretty complex, though, and I'm almost certain that I can't avoid four-layer boards if I really wanted to implement it. The clock distribution / clocking IC also sucks up quite a bit of power, though, and would probably require another microcontroller to control all of the clocks.
 - CPLD for 24-bit audio; the SCF5250 only supports 20-bit. I'm not sure if it'll be really that important, though, as some people seem to think going over 16/44.1, the original format of the audio, isn't a good idea anyway.
 - flash-memory based bootloader
 - differentially driven expansion port using RJ45/CAT-5 wiring: connect other modules (maybe video out, DSPs, ethernet, DACs slaved to the clock line, etc. . .) 
 - compactflash/securedigital storage module: the SCF5250 already has controllers for these formats, and some people might not mind sacrificing storage space for less EMI/RFI that might come from the hard drive
 - capacitive touch sensor for front panel interface
 - nicer screen
 - built-in headphone amplifier for the front panel
 - movie playback
 - enough feature creep already!

 As you can see, I'm trying hard to make it as simple as possible =) hopefully this will make it a bit easier for me to actually come out with something in a reasonable amount of time, and make debugging a lot easier.


 hm... whoa--sorry for the uber-long post!


----------



## OverlordXenu

Sounds amazing. Is that the same DAC that the iPod uses? Or is it better? I wonder what the best portable DAC is, and if you could get your hands on it...

 Are you going to be making these, offering them in kits, or what, exactly?


----------



## werdwerdus

any ballpark price range? Also, I'm guessing that it's going to be a line level output only, and not a volume adjustable?


----------



## Cauhtemoc

Quote:


  Originally Posted by *OverlordXenu* 
_Sounds amazing. Is that the same DAC that the iPod uses? Or is it better? I wonder what the best portable DAC is, and if you could get your hands on it..._

 

The iPod uses a WM8975. The WM8740 is much, much, much better.


----------



## Danielj

thanks 3.1 for the update...keep up the good work
 Dan


----------



## xnothingpoetic

maybe someone can improve this design?

http://www.hackaday.com/2005/11/14/simple-mp3-player/


----------



## threepointone

the problem with that diy mp3 player (and pretty much every other DIY DAP on the internet right now) is that it all relies on a dedicated MP3 decoding chip for all the audio decoding. This means none of them, as far as I know, can support FLAC/AAC/OGG/WMA/whatnot, and even if they could, you'd have to pretty much start over from scratch to make them accept any new formats. One of the goals of this project is to make a DAP that's actually as capable or more capable than teh stuff on the market.

 oh and a reminder: first version isn't portable at all--it's a desktop DAP. I'll start working to make it portable (which will require some compromises with the audio quality) after the desktop version is done. But it also depends on your version of portable--if you'll do anything for your audio (like that guy in the headphones forum who stuck a subwoofer (?) into his backpack for extra bass), i'm sure you could stick a huge battery pack and stick the DAP into your backpack. . .

 Price? no idea really--it's way, way, way, way too early to think about that. I'm pretty sure it'll be <$500, probably a lot less, but like all the other DIY stuff, it'd really depend on how you customize everything. Since many of the parts for this project aren't really available in smaller quantities without sampling (which can't be counted on) I'd imagine I (or someone else) would have to break up the chips into kits, or sell the individually. This would also drive down costs somewhat.


----------



## OverlordXenu

Well, desktop isn't too bad. At least then you can use it at work or something.

 Still, sounds GREAT.


----------



## flecom

im actually working on my own "audiophile" DAP... its going to be in a smallish hammond case with a built in battery and a decent dac/headphone amp so that its at least fairly portable... i will post pics when i get closer to being done 
	

	
	
		
		

		
		
	


	




 im thinking if i can actually get it working reliably im going to look into the costs of making them and maybe offer them to head-fi members... but thats probably 6 months off before i can really think about that

 its going to have a 2~3" color screen, MP3, MP4, FLAC, etc...


----------



## threepointone

cool, more people! someday head-fi's going to beat apple. . .OPEN SOURCE HARDWARE!!!! =)


----------



## OverlordXenu

Quote:


  Originally Posted by *threepointone* /img/forum/go_quote.gif 
_cool, more people! someday head-fi's going to beat apple_

 

I doubt that would be hard. It's not like Apple is an innovator or something. (Except maybe a hardware manufacturer controlling their phone in the US. That is something never done before.)


----------



## balou

Quote:


 the problem with that diy mp3 player (and pretty much every other DIY DAP on the internet right now) is that it all relies on a dedicated MP3 decoding chip for all the audio decoding. 
 

and even worse, it has a DAC, headphone amp and digital potentiometer already integrated (all non-bypassable). And the headphone out requires an output capacitor...


 I just read this on the Wolfson page:
  Quote:


 Fully dfferential voltage outputs 
 

 um.. did I get that right, the possibility for a balanced output?

 I also read the description on the SCF5250... this chip is quite amazing, IDE and SPDIF onboard, added DSP instruction set... I wanted to ask how you plan to attach the HD, but my question has been answered. This will also allow direct attachment of a CF card for the later portable version... nice.


----------



## threepointone

yep, balanced outputs =) an example is already in the datasheet. I'd have to figure out how to get balanced outs in the dual differential configuration, though (dual differential supposedly would perform even better)

 Yeah, the scf5250 is a great chip--only problem that's come up (other than 20-bit audio max) is that it might be getting a bit old, and there's a possibility that it might be obsoleted by the time everything gets finished (it's about 1 or two years old now?). The MCF5253 appears to be the best replacement (as far as I can tell, it does everything as good or even better than the scf5250--it even has builtin usb), but it only comes in a BGA package--I'm still thinking about whether or not I should switch over. With a BGA package, I'd have to do some sort of adapter board solution (schmartboard licensing?) or manually batch toaster-oven-reflow them and distribute them, since you obviously can't reach any of the pins with a soldering iron.


----------



## flecom

Quote:


  Originally Posted by *balou* /img/forum/go_quote.gif 
_and even worse, it has a DAC, headphone amp and digital potentiometer already integrated (all non-bypassable). And the headphone out requires an output capacitor...


 I just read this on the Wolfson page:
 um.. did I get that right, the possibility for a balanced output?

 I also read the description on the SCF5250... this chip is quite amazing, IDE and SPDIF onboard, added DSP instruction set... I wanted to ask how you plan to attach the HD, but my question has been answered. This will also allow direct attachment of a CF card for the later portable version... nice._

 

most DACs have balanced outputs, in the I/V stage they get turned into single-ended on most players...


----------



## balou

oh, another question: are you going to add the 32mb dram which are supported by the chip? in the standalone version, caching reduces noise and RF interference (would be definitely a plus) and power consumption (not so important). but in the battery-powered version, caching becomes absolutely crucial. A 1.8" HD consumes 100mA of power while idling - that's also one of the reasons why iPodlinux only has about half the run time compared to the standard ipod os, it seems like they haven't really implemented hd power down (at least not on the 5g ipod). Oh, and it gets a bit more drop proof (if drop occurs while hd is in power down, which it is most of the time)


----------



## threepointone

you have to be careful about balanced outputs in DACs these days--things are getting more and more integrated, and a lot of the new DACs don't need a I/V stage and can't do balanced. the pcm2702 in the alien dac can't, for example, and a lot of the stuff designed for portable players can't.

 I'm going to try to avoid thinking about the power consumption issues for the portable player until later--it's probably the most difficult thing for making something portable. The maximum sdram for the chip is already being included in the non-portable design (256Mb or 32MB), and I see no reason why it shouldn't be included in the portable design. Again, though, I'm going to avoid thinking about the portable design for now--honestly I'm not even sure if i'll stick with the SCF5250 or a coldfire chip at all, as I haven't even begun to think about the power budget / battery size of the portable player. For all I know, if memory prices go down enough, it might be designed primarily for flash memory.


----------



## Cauhtemoc

Quote:


  Originally Posted by *threepointone* 
_yep, balanced outputs =) an example is already in the datasheet. I'd have to figure out how to get balanced outs in the dual differential configuration, though (dual differential supposedly would perform even better)_

 

In dual differential mode each DAC outputs the same data on both channels. Just add the signals together with two resistors. There is an example of this in the WM8740 datasheet.


----------



## Rescue Toaster

Quote:


  Originally Posted by *balou* /img/forum/go_quote.gif 
_oh, another question: are you going to add the 32mb dram which are supported by the chip? in the standalone version, caching reduces noise and RF interference (would be definitely a plus) and power consumption (not so important). but in the battery-powered version, caching becomes absolutely crucial. A 1.8" HD consumes 100mA of power while idling - that's also one of the reasons why iPodlinux only has about half the run time compared to the standard ipod os, it seems like they haven't really implemented hd power down (at least not on the 5g ipod). Oh, and it gets a bit more drop proof (if drop occurs while hd is in power down, which it is most of the time)_

 

The trick with the portable hard drives is the most important factor is the speed at which you can read data from the drive relative to the speed data is consumed by the DAC, no matter how big the cache is. When playing .WAV or FLAC, you need a good disc driver so you can fill your cache quickly and get the drive shut back down. A basic no-DMA no-irq polled interface will have horrible performance, and if you're only pulling data off the disc at say twice the speed you're using it, no matter how big your cache is, the drive will be on 50% of the time. Cache size only determines how often it cycles on & off.

 EDIT: Don't forget that non-DMA'd hard drive access can eat up a lot of CPU time that you might want for FLAC decoding or DSP processing.


----------



## balou

Quote:


 the most important factor is the speed at which you can read data from the drive relative to the speed data is consumed by the DAC, no matter how big the cache is. 
 

Fortunately, the SCF5250 microprocessor has a DMA controller chip already integrated, so reading the data at sufficient speeds shouldn't pose a serious problem. Of course, if you had to write your own IDE accessing routines using only generic IO ports, this would be quite a problem.


----------



## OverlordXenu

Any news, per chance?


----------



## antonyfirst

Ok guys, a balanced lineout DAP is my portable dream. If someone makes one, I'll buy it in a blink!


----------



## mcmurray

Interesting ideas people. 

 I have been considering designing, from scratch, a 24bit desktop FLAC player (16bit files aswell) with built in DAC, ~1Tb of HDD. 

 Would a dual processor design say ARM like the iPod be useful to decouple the control logic from the playback engine? I envision a second processor would take care of buffering, decoding, signal processing and output to the DAC. 

 An expert in the area told me that quite a sophisticated ring buffering scheme will need to be written both for the input to the decoder and the output to DAC. It was also suggested that DMA be used to get the data from the HDD to memory and again for outputting from memory to the DAC. Sounds like a challenge 
	

	
	
		
		

		
			





 Just thinking out loud at this stage but first I think I will install linux and tinker with it as I'm pretty sure that will be the OS I will use. I have heard good things about RTLinux, has anyone here used it?


----------



## ezkcdude

I'm not sure you can make a *portable* audiophile-quality player. Forgetting about the control logic, processor, FPGA, SOC, let's just take a look at the DAC section, since most people around here are more familiar with that. Think about the board size of the DAC's considered "audiophile" quality. I won't even mention any (although I did once start a thread that still hasn't become sticky), but most of them are not that small. Good voltage regulation, low-jitter clocks, low-distortion output stages do not generally come in very small packages. Just think about all that needs to go into it. I have no doubt one could DIY a portable player, but in order to make it the size of an iPod, you really have to gut the audio parts to fit all the processing and have the whole thing fit in the palm of your hand. And forget about using boutique through-hole parts - it will be strictly smt affair. Just my two cents.


----------



## mcmurray

I understand, I have no intentions of making this thing small. I don't care if it turns out the size of a 5.1 receiver.


----------



## threepointone

yep, not gonna be small. might try to miniaturize it in the future, but unless we sacrifice some audio quality it probably won't get anywhere as small as most DAPs out there today.

 I think some other people have been working on the DAP too--any news on those? Sorry to disappoint, but I haven't really gotten to work on the DAP since my last update. Until maybe november or so i'm far, far, far too busy to touch the project. To be honest, I really shouldn't be on head-fi right now =P After that, I should have loads of free time.

 I admit, it's starting to smell a bit like vaporware =O


----------



## mcmurray

I think I will make my design single processor, not dual as mentioned before. I'm thinking maybe a Coldfire processor. Does anyone know where I could find a reasonably priced Coldfire Dev board?


----------



## threepointone

Dunno where the dual processor idea came from, but my current design (which has a lot to go) happens to be also based on the coldfire design. There might be some useful info in the previous posts in this thread (most importantly there's a link to a cheap coldfire BDM debugging cable somewhere in there). I don't know of any cheap coldfire dev boards, at least for freescale's audio processors that I've seen.


----------



## antonyfirst

What about the diy dap? I'd be really interested to get one.


----------



## threepointone

unfortunately, it's going to be quite a while before you can get one of the diy daps.

 good news: i managed to get myself a mcf5251 eval board =) Should make things easier. I'm rather tempted to use the mcf5251/mcf5253 uCs for the final project, but I have no idea how DIYers would be able to solder these things. I'm not even sure if I could do it reliably myself if I set up a hot air gun/toaster reflow soldering system, especially for a chip with so many balls--anyone done bga soldering before?


----------



## Cauhtemoc

Quote:


  Originally Posted by *threepointone* 
_anyone done bga soldering before?_

 

It can be done with a normal kitchen oven, a hot-air rework station, and a lot of patience. I have done it in the past, and I definitely wouldn't recommend it for a DIY project.


----------



## error401

Why not choose something like the AT91SAM9260 from Atmel? ARM9 core at 180MHz, and it's got basically everything the Freescale part has. Except it's easier to get; DigiKey carries it. The two big missing peripherals are the SPDIF interface and ATA controller, though if you're happy with Ethernet or SD, this part should be fine. I2S can be done with the SSC, and is explicitly mentioned in the documentation, and I know that was a big appeal for choosing the Freescale part.

 This chip is significantly faster than the Motorola as well, and I think it's probably fast enough to run embedded Linux with proper networking and standard user-mode FLAC etc. decoding libraries and some plain-jane C code to tie it together. You might end up having to write some simple drivers, but these shouldn't be too difficult.

 iPod uses an ARM core, so if you wanted to, porting Rockbox to your device would likely be no more difficult than targetting Coldfire. In fact, there's probably more ASM optimization in the ARM port. I bet the GNU toolchain for ARM is probably better than the Coldfire one. ARM seems to be a lot bigger than Coldfire in all sectors but mobile gadgets, where they seem to have about equal share.

 Check this guy's work out: http://www.mikrocontroller.net/artic...MP3/AAC_Player


----------



## labmat

The nice thing about the Atmel is the programing hardware is readily available and inexpensive. Nice for DIY!


----------



## casainho

Hello 

 I would like to invite everyone to look at our Free/Open hardware dap for use with Rockbox:
Rockbox Player

 If you can help, please join team and let's build the best Free/Open hardware dap which will work with the best open source firmware for mp3 players, written from scratch, the Rockbox  

 Thank you.
 ---
 Casainho - http://www.Casainho.net


----------



## Basil101

My idea for a DAP; why not use a Via pico motherboard as the base, it can run any x86 OS (a custom linux perhaps), it has USB ports for a DAC to connect and there are USB screens readily available. 
 The motherboard is a typical Via in that it is very power efficient therefore battery power is _possible_ (these are used in carputers that run from a 12V lead acid).
 Input could be from something like this mini wireless keyboard or just buttons on the casing.
 Personally I would have a motherboard, 60GB 2.5" HDD, running from a wallwart/PPA battery board, a USB powered Alien DAC which outputs to a standard 3.5mm jack and a mini wireless keyboard. Case the whole lot in a an enclosure like the hammond 1455N1601 for a great sounding luggable DAP. To get music on a USB CD drive would suffice.

 Or buy the kit and mod till your hearts content.


----------



## 00940

Anyone considered the VS1033 ? It has problems (it resamples everything to 48Khz and only accepts flash cards) but also has an I2S output so you can add your favorite dac directly to it.


----------



## ericj

Resampling, especially in short jumps such as 44.1khz to 48khz, is BAD. Causes aliasing unless done with extreme care. 

 Basically, in order to avoid alisaing when making a sampling change of +3.9khz, you have to upsample to a much higher rate (like 112khz, iirc), and then downsample back to your target sample rate. Google "helmholtz" "nyquist" "sampling theory" and "aliasing" for details. The math here is quite solid. 

 Best case scenario it only damages fidelity a little. Worst case scenario it sounds terrible. You cannot improve the quality of the stream by manipulating it. You might reduce some of the distortion at the DAC, but you've damaged the stream to do it.


----------



## 00940

I know that... That's why it was under "problems".

 Actually, I quoted the 48KHz from memory (coming from a diyaudio post). It's a bit more complex. Here are the relevant passage of the datasheet:

 "The sample rate converter upsamples all different sample rates to XTALI/2, or 128 times the highest usable sample rate with 18-bit precision. This removes the need for complex PLL-based clocking schemes and allows almost unlimited sample rate accuracy with one fixed input clock frequency. With a 12.288 MHz clock, the DA converter operates at 128 x 48 kHz, i.e. 6.144 MHz, and creates a stereo in-phase analog signal. The oversampled output is low-pass filtered by an on-chip analog filter. This signal is then forwarded to the earphone amplifier."

 "I2S CF MCLK ENA enables the MCLK output. The frequency is either directly the input clock (nominal 12.288 MHz), or half the input clock when mode register bit SM CLK RANGE is set to 1 (24-26 MHz input clock).

 I2S CF SRATE controls the output samplerate. When set to 48 kHz, SCLK is MCLK divided by 8,when 96 kHz SCLK is MCLK divided by 4, and when 192 kHz SCLK is MCLK divided by 2."


----------



## UserNotFound

I'd just like to throw in my two cents that if we're talking ARM architecture and BGA's, the Y in DIY means "YOURSELF". You're not gonna find a lot of existing designs and discussion to help you. It's really gonna be a project from scratch.

 I just did a quick and dirty project with an at91sam7x256 to interface with the CANbus in my car to retrieve the steering wheel radio controls and control my after market head unit via proprietary serial....as well as be able to monitor all my car's system's via ethernet...and it was far from what would constitute DIY.

 The ethernet option is a distinct advantage though, as if you're good with javascript and string parsing, you could create a fairly complex and detailed control structure for the DAP, including album art, etc.


----------



## error401

Just thought I'd resurrect this thread with a product I just stumbled across:

VS1033 - Very Low power MP3 Audio Player Chip

 It can decode most lossy compressed formats from a simple serial input stream, and has I2S outs. And it's easy to get.


----------



## 00940

The Vs1033 was discussed just four posts above


----------



## error401

Quote:


  Originally Posted by *00940* /img/forum/go_quote.gif 
_The Vs1033 was discussed just four posts above 
	

	
	
		
		

		
		
	


	


_

 

I'm an observant one, I am. Good find 00940, interesting chip .


----------

