Re: openHiFi - high grade home music player Reply #45 – February 23, 2011, 06:30:21 am I may have them GND through cutable/solder jumper on a single ended board, or a physical jumper if it is a problem.Why would having the neg terminals GND "stress" a differential input? (I agree that in the input diff pair +/- x biases the pair differently than +2x/0) You said use the single GND for ref for all? I am afraid I don't follow how that would work if it is assuming LVDS on the decoder and sees a floating pin on each neg input. Last Edit: January 01, 1970, 01:00:00 am by Guest
Re: openHiFi - high grade home music player Reply #46 РFebruary 23, 2011, 08:53:03 am I think you can get by without any jumpers or 'bowtie' pads if you're willing to design a board to be just single-ended or just differential. I guess there might be an advantage to designing the board for differential but make it work if you leave off the differential driver/receiver, in which case the same PCB could be reused for both variations and be configured by jumpers, but I was thinking that folks interested in differential would have vastly different ideas for the other parts of the circuit too, so there might not be any point to having jumpers. In other words, the converter boards with really high-end DAC chips would always be designed for differential, but cheaper converter boards would always be designed single-ended to reduce parts counts and cost. Make sense? I realize I may be missing something, so feel free to point out anything.Stress is like this: If a differential driver is sending a '0', then '+' will be low and '-' will be high (3.3V?). But if a single-ended receiver has a trace connecting ground to every '-' pin, then the differential driver will be attempting to push 3.3V onto a grounded trace (although the ribbon will be in between with some amount of resistance). Therefore, the only solution seems to be that single-ended receivers should leave the '-' pin unconnected (floating). But the single-ended receiver still needs some reference for the '+' pin, so that has to be the common GND.Example:LVDS decoder -> single-ended converter; all pins are connected on the decoder, but the converter leaves BCLK- WCLK- and DATA- floating.Single-ended converter -> LVDS converter; BCLK- WCLK- and DATA- are grounded because they're transmitting, all pins are connected on the converter, too.The tricky part is MCLK-, because that depends upon whether the converter is master or slave. If the converter is master, then MCLK- will always be connected, either to the LVDS driver for differential or GND for single-ended. If the converter is slave, then MCLK- should float on single-ended boards or connect to the LVDS receiver chip if present. So far, it's easy on the converter board. The real problem is the decoder board, which has to work with both master and slave converter boards, and both single-ended and differential converter boards. Now that I think about it, this might require a jumper on the decoder board, but just for MCLK- (not any of the other pins which have a dedicated direction). You may already have thought of this.I really should check into LVDS and other differential chip solutions. I am assuming that a differential input will accept GND on its '-' input and still properly track the single-ended signal on the '+' input, but I am also sure there are some differential chips out there that need an actual negative or positive voltage on '-' (i.e., not zero, because that would be inconclusive). It's certainly possible to make such a single-ended-compatible differential receiver using discrete op-amp circuits, but that might be ridiculously complicated, so I am hoping there is a compatible driver chip. I don't think that EIA-485 (ne̩ RS-485) will work, because I seem to recall that it always outputs either positive or negative voltage, never gound, and further I recall that it might not receive '+' vs. GND very well (not a strong enough indication).By the way, I realize that the voltage should be part of the standard, too, otherwise it wouldn't be very compatible across multiple boards. What's the most common DAC digital I/O voltage these days? 3.3V? Are there still any significant 5V DAC chips? Can the 5V DACs just be handled with extra chips to interface from a 3.3V interconnect to 5V on the rest of the board? Are there many DAC chips with less than 3.3V logic I/O? Most processor chips seem to have 3.3V support for I/O, so hopefully that won't pose a problem. Even the processors that run on 1.2V internally use 3.3V for I/O. My inclination would be to make the most common voltage the default, so that the lowest parts count will be the most common. Boards with chips that work on other voltages would have to convert the voltage at the connector. Last Edit: January 01, 1970, 01:00:00 am by Guest
Re: openHiFi - high grade home music player Reply #47 – February 23, 2011, 10:40:59 pm I don't think you understood, what I meant about GNDs etc but I think we should put off any discussion of these tiny details until I actually have time to lay stuff out.I am much more interested in my query about library information, as that part of the system is very unconstrained by cost etc.I will say this though: LVDS and LVCMOS/LVTTL signaling aren't really compatible if you read the specs both boards need LVDS or single ended unless you want a complex mess. To support both even the option of both on ever board is likely to be burdensome. LVDS support would cost 3 dollars per board (6 for the system) roughly. Last Edit: January 01, 1970, 01:00:00 am by Guest
Re: openHiFi - high grade home music player Reply #48 – February 24, 2011, 12:07:46 am [quote author="brian"]I will say this though: LVDS and LVCMOS/LVTTL signaling aren't really compatible if you read the specs both boards need LVDS or single ended unless you want a complex mess. To support both even the option of both on ever board is likely to be burdensome. LVDS support would cost 3 dollars per board (6 for the system) roughly.[/quote]I only threw in LVDS as a specific because it was mentioned on diyAudio, and it seems like a convenient shorthand. I am actually thinking in terms of differential signalling versus single-ended. As I mentioned, at some point we'll have to talk about specific chips and see if they're compatible with positive-only single-ended signals. Or, more precisely, since you're probably not terribly interested in this, I'll have to investigate a reasonable solution and document whatever I find here. At a high level, the connector pin-out at least appears to be compatible with differential, and that's enough to satisfy me for now.Thanks for the feedback.As I learn more about ARM, I might be able to help out with your other tasks, but for now I hope that others here in the Dangerous Prototypes community will jump in. Last Edit: January 01, 1970, 01:00:00 am by Guest
Re: openHiFi - high grade home music player Reply #49 – February 24, 2011, 02:04:29 am I appreciate your input and I will do my best to support as many customizations as possible. Differential signaling maybe of use if people need very long interconnects between the decoder and DAC. I will look into it at a later date more. Last Edit: January 01, 1970, 01:00:00 am by Guest
Re: openHiFi - high grade home music player Reply #50 – February 24, 2011, 11:06:17 pm Another assumption I am making is that WCLK and BCLK can be derived from MCLK no matter who is Master. It that true? If not, then the direction of the other clock pins needs to reverse according to master/slave select as well. Last Edit: January 01, 1970, 01:00:00 am by Guest
Re: openHiFi - high grade home music player Reply #51 – February 25, 2011, 03:05:54 am WCLK and BCLK are created (I think) always by the sender be it slave or master. They are simply synced to the master clock. In other news, the RockBox decoder for FLAC looks pretty portable. Although it only supports a subset of the full FLAC (standard reference encoder blocksizes etc).The reference decoder API for libFLAC is woefully complex. I will probably do some more work trying to port libFLAC before I commit because I like BSD a lot more than LGPL but so far the smallest size I have gotten for a FLAC->WAV converter is 600 kB!!! vs 16 kB for the FFMPEG based RockBox version. I am sure libFLAC can be made smaller, but there was also a comment on RockBox mailing list that after they switched the FFMPEG based decode their were much faster. FFMPEG is also more actively developed and is being backported to RockBox on occation whereas there is essentially no development now on FLAC/libFLAC (as far as I know). I am actually using an ancient branch of RockBox for study because some of the code contributed by the original author of the FLAC decoder was hacked in such a way to make it much more specific to RockBox whereas the original decoder was more portable. It isn't that large a code base, I will just go though function by function and update it if needed. Last Edit: January 01, 1970, 01:00:00 am by Guest
Re: openHiFi - high grade home music player Reply #52 – February 25, 2011, 10:31:21 am I have never tried porting FLAC, but are you leaving out libFLAC++? Seems like you might get an oversized image if you include both libFLAC and libFLAC++. libFLAC++ is really just a wrapper on top of libFLAC ... you don't need libFLAC++ (you may already know this, but others have certainly been confused). Have you looked at the assembly output to see where the big chunks of code are coming from? What about debugging printf() statements? Those seem like unnecessary baggage, and I assume there is some kind of #define to remove them. Admittedly, I'm doing a lot of hand-waving here without having looked into the source in years, especially not with a mind for embedded targets, but maybe these comments will help you.Active development is kinda meaningless when the main FLAC sources are from the original author and represent the official specification. Why would anything need to change? To use a Steve Jobs-ism: It Just Works. The fact that FFMPEG is actively under development just tells me that they're still catching up to a very stationary target. Personally, I prefer projects that are not actively under development, because I do not like downloading updates, changing code, or re-compiling repeatedly. Last Edit: January 01, 1970, 01:00:00 am by Guest
Re: openHiFi - high grade home music player Reply #53 – February 25, 2011, 01:35:34 pm Now I didn't use the C++ wrapper. You can find lots of comments on how big libFLAC is if you dig on google (mostly mail list stuff). There are functions that handle every part of the spec of course 90% of them you don't need. The makefile environment is *huge* and there is essentially no documentation for #defines to remove code.The closest thing you get is "you can prune it by editing the automake file" well... yes of course... if you knew what was safe to cut, but you don't. More over automake! I never use that for bare metal stuff... It was certainly written with OS media players in mind not embedded (the Codec was for everything but the library I don't feel was targeted at all for embedded though it is mentioned as I note in the docs that you could prune the .am files).You are correct there is nothing that needs to be improved to make things work for libFLAC and for all PC like targets any optimization would be meaningless. There are ASM optimizations for x86 in it but none for ARM. On the other hand FFMPEG and RockBox both have ARM optimizations. Anyway....The good news is that the RockBox decoder is pretty good. It supports up to 24-bit in theory though I have only tested with 16 bit 44.1 kHz stereo files...The decoder as written requires 32-bit * frameLength * channels + max(FrameSize) + a huge File buffer. This does not fit in the 96 kB of SRAM on the target micro however, some minor changes and huge File buffer can be made as small as you want with a hit to performance.The upshot to this is I have working ARM FLAC code done already. It reads a .flac and spits out a .wav both over USB mass storage. I believe the main bottleneck is write performance and file system performance in general which I will check again later...Over USB FS (12 Mbit) I recall the read thoughput was about 720 kB/s, writing to a flash tends to be slower even if it isn't really saturating the card, because you are writing individual sectors that are smaller than the block size of the flash it is slower. So it might only write at 400 kB/s or less... Add to that that it is basically 50% of the throughput because there is only 1 pair of differential data lines and you start to see the issue....Discarding the decoded data the task runs at about 2x realtime and with a very fast USB flash it goes at about 75-80% of real time for read+write back. I haven't added the ARM optimizations as yet but if it is as I think limited by the file system this might not make much difference. Give that the WAV is larger and the "write" part of the operation the slowness is not surprising. I should probably try it with a USB hard disc. Anyway, since this is pretty unoptimized and you don't actually need to do a filesystem write during decode I see no reason why this CPU won't be more than enough to do at least 16-bit stereo FLAC which is my very most important thing to do. This totally avoids having to pay for a $$$ coprocessor chip (VS1053 or otherwise).While the decoder will fit in the SRAM in the CPU, it does not leave a ton for other purposes (probably less than 10 k for everything else when the file system is taken into account as well). So external memory might still be a good idea... My development board certainly will have the RAM. If it looks like the openHiFi can run without extra memory, I will lay out the board in such a way that those pins can be used if the SDRAM is not places. (It is a *lot* of pins). Last Edit: January 01, 1970, 01:00:00 am by Guest
Re: openHiFi - high grade home music player Reply #54 – February 25, 2011, 03:50:10 pm [quote author="brian"]You can find lots of comments on how big libFLAC is if you dig on google (mostly mail list stuff). There are functions that handle every part of the spec of course 90% of them you don't need. The makefile environment is *huge* and there is essentially no documentation for #defines to remove code.[/quote]./configure --helpQuoteThere are ASM optimizations for x86 in it but none for ARM. On the other hand FFMPEG and RockBox both have ARM optimizations.Eric Wong ported to ARM7TDMI in March, 2009, although I haven't checked to see if that link is still valid. His must be the reference to ARM that I remember.In April of 2010, Josh Coalson claimed that FLAC had already been built for ARM in many places, and that he built a version for nslu from the original sources with no modifications. You might want to try joining the FLAC Developer mailing list if you're running into problems.QuoteThe decoder as written requires 32-bit * frameLength * channels + max(FrameSize) + a huge File buffer. This does not fit in the 96 kB of SRAM on the target micro however, some minor changes and huge File buffer can be made as small as you want with a hit to performance.Why do you need a huge file buffer? You should use the streaming protocol and convert one block at a time before passing it off to the DAC.QuoteDiscarding the decoded data the task runs at about 2x realtime and with a very fast USB flash it goes at about 75-80% of real time for read+write back. That's probably a decent test for prototyping purposes, but it sure seems like the wrong approach for a FLAC player. Last Edit: January 01, 1970, 01:00:00 am by Guest
Re: openHiFi - high grade home music player Reply #55 – February 25, 2011, 07:54:00 pm I will def look at that guy's ARMTDMI7 port as that is close to Cortex M3...[quote author="rsdio"][quote author="brian"]QuoteDiscarding the decoded data the task runs at about 2x realtime and with a very fast USB flash it goes at about 75-80% of real time for read+write back. That's probably a decent test for prototyping purposes, but it sure seems like the wrong approach for a FLAC player.[/quote][/quote]I thought that was rather self evident, that this was just a test...A stream approach can also work but all it saves you is the frame buffer, it also makes it much slower because you transfer each subframe which are smaller. For flash based things that will be much slower. The buffersize is only the size of a frame and how big it will be decoded. The smallest buffersize would be the size of the smallest subframe and the size that would be decoded. Both libFLAC and FFMPEG/RockBox require substantial rewrites I think to go to just subframe buffers. Again it will be much slower that way.I am sure you read this at some point since I am pretty sure that is you writing:http://www.mail-archive.com/flac-dev@xi ... 01047.htmlBut really Dave is quite right. They used libFLAC and abandoned it, that should tell you something.Believe me if I can make things work nicely with libFLAC I will because of my personal preference for permissive licenses over copyleft for most things.PS: (./configure --help) yes I already read that...PPS: This is the sort of chip that is typically used in a portable playerhttp://www.austriamicrosystems.com/eng/ ... ers/AS3525 320 kB SRAM... look at how poor the DAC is though :-) Not only that, it seems to use S/PDIF internally. This is the chip in the some of the newer Sansa players. Last Edit: January 01, 1970, 01:00:00 am by Guest
Re: openHiFi - high grade home music player Reply #56 – February 25, 2011, 10:35:19 pm FLAC speed @ 80 MHz Cortex M3 Flash ~ r/w time 1:24 (write ~ 60s; read ~ 30s)Decode time to .WAV/dump to flash ~ 2:44File length 4:03 (16-bit stereo 44.1 kHz)Nominally 33% of CLK to decode -> 26.6 MHz for realtimeWith file read overhead 45% of clockhttp://www.rockbox.org/wiki/CodecPerfor ... RM7TDMI_41The second (Sourcery G++ Lite 2009q3-67) table suggests that ~ 13.5 MHz should be achievable with ASM code included.The ASM code needs porting to Cortex-M3 (thumb2 only).The performance listed above is already probably good enough actually... The RockBox people care about CPU overhead because of the impact on battery life. Here all that matters is enough time to service other IRQs. Last Edit: January 01, 1970, 01:00:00 am by Guest
Re: openHiFi - high grade home music player Reply #57 – February 26, 2011, 01:40:48 am [quote author="brian"]The ASM code needs porting to Cortex-M3 (thumb2 only).[/quote]I've only just started learning about ARM, but isn't THUMB2 a superset of THUMB? ... or is it that the ARM instructions are missing from Cortex-M3? It's a little confusing when some ARM chips support ARM, THUMB, and Jazelle... Last Edit: January 01, 1970, 01:00:00 am by Guest
Re: openHiFi - high grade home music player Reply #58 – February 26, 2011, 02:51:06 am THUMB is a simplified ARM instruction set, thumb-2 is a superset of thumb. The code appears to be written for ARM5/ARM6 based cores like the ARM9 (I know it is confusing how they are numbered).It would have to work on ARM7TDMI (the T stands for thumb) but this core is obsolete though still used a lot (all the .NET boards you see for enthusiast people are ARM7TDMI). Most of the errors that came up were due to certain kinds of Loads not being allowed, I will have to double check that it is calling instructions that really don't exist... There might be equivalents for Thumb2.You can read some about Thumb2 here:http://infocenter.arm.com/help/index.js ... 02s01.htmlThere are a lot of conditional instructions used in the ASM code in the library which if you are compiling to thumb aren't allowed also. I would have to use explicit conditions. Pretty much it will have to be rewritten, but the old version is a good guide on how to do so.The functional if non-optimal code base I have now is a proof for doing debugging against and testing improvements, which I can roll together.I am now talking to the RockBox people also to see if I can make the hardware easier for someone over there to port it to this platform. I myself am not likely to do that amount of coding, as what I need is not a RockBox but not having that OSS tied to close source hardware could be good for everyone. Though they are focused on portable audio, I suspect those willing to work hard to get FLAC on their X portable might be the type that would want a openHiFi also (if they don't already have some special purpose computer for it).Edit: This might be a better place to start to learn about the differences between thumb and regular ARMhttp://www.arm.com/products/processors/ ... ctures.phpI actually am learning these details myself now also... I haven't used anything but cortex Ms which all use Thumb. M3 is Thumb2 only meaning it can't run regular ARM instructions. This is why there will have to be a port to make it go.The basic idea with Thumb/Thumb2 is to reduce code size so that ARM can kill off 8/16 bit computers. The full ARM instruction set is the most robust (mostly) but if you are mostly working with bytes it has more overhead, thus slower. Last Edit: January 01, 1970, 01:00:00 am by Guest
Re: openHiFi - high grade home music player Reply #59 – February 26, 2011, 05:05:33 am [quote author="brian"]I am now talking to the RockBox people also to see if I can make the hardware easier for someone over there to port it to this platform. I myself am not likely to do that amount of coding, as what I need is not a RockBox but not having that OSS tied to close source hardware could be good for everyone. Though they are focused on portable audio, I suspect those willing to work hard to get FLAC on their X portable might be the type that would want a openHiFi also (if they don't already have some special purpose computer for it).[/quote]Right; rather than port RockBox to the processor you first selected, why not just select another ARM chip that will run the RockBox FLAC code as is? Is there a big difference between M3 and A3, for example? I think we may have covered this on the forum before (sorry).QuoteI actually am learning these details myself now also... I haven't used anything but cortex Ms which all use Thumb. M3 is Thumb2 only meaning it can't run regular ARM instructions. This is why there will have to be a port to make it go.I did not realize there were THUMB2-only ARM chips that did not run regular ARM instructions, but your original message did imply thatI have been investigating the iPhone lineage, which started on an ARM11 chip that runs ARMv6 code. They're now on ARMv7, and the build environment builds separate code images for v6 and v7. The impression that I was starting to get is that everything is backwards compatible, but that's obviously the wrong impression. Folks were already pointing out that the old ARMv6 iPhones support VFPv2, and the new ARMv7 iPhones support NEON, but not every ARMv6/v7 chip supports those extensions, so there are clearly groups of added features which are not present on every ARM chip. I just ended up with the mistaken impression that ARM always implements the ARM instruction set, although in hind sight I guess it makes sense that removing the original 32-bit ARM instructions could save some resources and lower the cost.QuoteThe basic idea with Thumb/Thumb2 is to reduce code size so that ARM can kill off 8/16 bit computers. The full ARM instruction set is the most robust (mostly) but if you are mostly working with bytes it has more overhead, thus slower.Well, I don't know about killing off 8/16 computers!Basically, it seems that ARM was designed as a more-or-less 'pure' 32-bit RISC processor without consideration for embedded applications. However, once ARM discovered that they were exploding in the embedded market, they realized that it would be smart to cater to the limitations of embedded systems. Breaking from the pure 32-bit model is beneficial when you have limited memory resources, especially if your bus is limited to 16-bit or even 8-bit. Basically, ARM started out more efficient than most general processors, and lately they've been tweaking it to be even more efficient for the embedded applications where it is being used more and more. Last Edit: January 01, 1970, 01:00:00 am by Guest
Topic: openHiFi - high grade home music player (Read 49931 times)
previous topic - next topic
Open Source Hardware