Greetings, I am building a data collection system that will ultimately have 28 channels and multi-rates up to 2 M/sec. I need some sort of lossless format framing and header system to transfer the data to a desktop PC over USB. Rather than reinvent, I looked around to see what others are using and for existing tools for testing. Surprisingly, I found few general purpose data formats that can handle many channels and high multi-rate data. However, ogg and oggPCM looks like a good fit. I have some questions getting started. Is the oggPCM codec just header definition on a web page? Is anyone using it? I have not found the header file yet, does it exist? Has anyone built libogg and/or liboggz using a cross compiler such as the arm-elf GNU port? I am looking at using the oggz wrapper function due to the excellent documentation and examples. The configure-make works great on the desktop but I don't know if it could be easily switched over for an embedded target. oggFLAC had a makefile.lite that looked geared toward embedded development but the FLAC library size was HUGE, plus other limits. I am hoping to fit executable on 128K of FLASH memory. Thanks for any advice. +BillJ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/ogg-dev/attachments/20061208/f24a533d/attachment.htm
Bill Johnson wrote:> Greetings, > I am building a data collection system that will ultimately have 28 > channels > and multi-rates up to 2 M/sec. I need some sort of lossless format framing > and header system to transfer the data to a desktop PC over USB. Rather > than > reinvent, I looked around to see what others are using and for existing > tools for testing. Surprisingly, I found few general purpose data formats > that can handle many channels and high multi-rate data. However, ogg and > oggPCM looks like a good fit. I have some questions getting started. > Is the oggPCM codec just header definition on a web page? Is anyone using > it? I have not found the header file yet, does it exist? > Has anyone built libogg and/or liboggz using a cross compiler such as the > arm-elf GNU port? > I am looking at using the oggz wrapper function due to the excellent > documentation and examples. The configure-make works great on the desktop > but I don't know if it could be easily switched over for an embedded > target. > oggFLAC had a makefile.lite that looked geared toward embedded development > but the FLAC library size was HUGE, plus other limits. I am hoping to fit > executable on 128K of FLASH memory. > Thanks for any advice. > +BillJ >Yes, it sounds like FLAC isn't what you want, especially as it's geared to audio compression and mightn't cope well with other data. OggPCM files do exist, <http://lists.xiph.org/pipermail/ogg-dev/2006-February/000248.html> That message also suggests Illiminable's DirectShow filters work with oggPCM too, so there'll be code somewhere to produce the header, but I don't think there's a Xiph implementation if that's what you're looking for. Don't know about the cross-compiling/embedded aspect, sorry. <meta if OggPCM is regarded as stable, then it needs a link from the www.xiph.org front page, and possibly a static .html so people aren't put off by the fact they're looking at a wiki /> -- imalone
Hi Bill, I'm not aware of any actual audio tools that support OggPCM, but at least the headers can be read by OggDSF, liboggz and HOgg -- so you can get some diagnostics on such files, which might help with debugging your application. As for your questions about liboggz: * yes it has been cross-compiled for ARM. We used it at CSIRO to develop applications for Symbian-based phones. You can even strip down the build to disable writing or reading support if you want to make it smaller for your platform. It's also been extenhsively checked for memory leaks, as these can be fatal on suc systems ;-) The Symbian cross-compile to arm uses gcc. * if you additionally write an Ogg Skeleton track, as described at http://wiki.xiph.org/OggSkeleton , then liboggz will be able to seek on such files, provide timestamps for each packet in oggzdump and show file durations in oggzinfo. * by doing this (writing Ogg Skeleton) you are free to make up your own data format instead of using OggPCM. Then you can create custom headers that are more appropriate for your application than those provided by OggPCM (which are of course geared to audio). Being able to wrap arbitrary data in Ogg was one of the design goals of Ogg Skeleton. cheers, and thanks for the nice words about liboggz :-) Conrad.
On Fri, Dec 08, 2006 at 01:37:15AM -0500, Bill Johnson wrote:> Has anyone built libogg and/or liboggz using a cross compiler such as the > arm-elf GNU port?Conrad didn't mention is explicitly, but libogg also works find on arm. For a small embedded app, I'd just compile the two source files into a static library manually. If you're not using a smart linker, you may also want #ifdef out one or both of the bitpacker implementations (oggpack*) to save additional footprint.> oggFLAC had a makefile.lite that looked geared toward embedded development > but the FLAC library size was HUGE, plus other limits. I am hoping to fit > executable on 128K of FLASH memory.FLAC isn't quite as lightweight an implementation as the other codecs, but a reduced-capability codec could definitely fit in 128K flash. FLAC would probably also work for any smoothly varying time-series data. But if you have the bandwidth, sending uncompressed data is must less work (for you and your processor). As a final note, there's an experimental zero-copy Ogg implementation in our svn repository. The API is necessarily different and liboggz hasn't been ported, but if you find memory bandwidth is a bottleneck at your data rates, it will help. libogg does at least one memcpy() on all data that goes through it. http://svn.xiph.org/trunk/ogg2/ Sounds like a fun application. Keep us posted. :) -r
Thanks all for the great response. I will follow the leads. +BillJ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/ogg-dev/attachments/20061208/8bbc172e/attachment.html