ARM/DSP based open source Hi-Fi

Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.
What I always use as part of my manufacturing instructions is the paragraph on how they should process my solder mask, in the attached PDF file.
This gives the manufacturer room to get the best yield whilst preventing exposed copper.
 

Attachments

  • Solder Resist.pdf
    8.2 KB · Views: 66
Has anyone come across any GStreamer crossover elements/bins? It strikes me that GStreamer would be an ideal way to create whatever open source cascade/transform you would care to design. You could build a crossover pipeline with a graphical gui (gstedit for a start) if the elements and bins were available. A bit like this DVD playback pipeline..

http://www.cin.ufpe.br/~cinlug/wiki/images/4/43/Gst-editor.png

I may consider writing GStreamer elements for my project that harness the C674x DSP attached to the Cortex-A8.
 
I have been busy working on a n-channel GStreamer audio sink.

SINK -> 31-band PEQ per channel -> multi way XO per channel -> McASP i2s or DIT PCM. I am developing a node based UI for the XO and i2s configuration so that users can build whatever chain they wish to any number of i2s outputs.

The sink uses a GstAdaptor to fill up buffer 2ms of audio frames to be processed by the DSP. The node tree created by the XO UI is used to build the crossover from the available DSP blocks that I am developing. It will require some work to get the pipeline working properly and latency low.

The 31 band EQ with all bands active currently uses 23MHz DSP (4% utilisation) for a stereo 44.1kHz stream. Quite a bit still to do to optimize the biquad stages and register management.

Hardware schematics and PCB are well under way for the mainboard. I should have something substantial to share later in March.
 
Thanks! I have the double precision stereo 31 band PEQ down to 52k cycles (all bands active) for a 1ms buffer (48kHz). Each channel has independent PEQ. The use of "restrict" type in certain areas really brought down the cycle count. I am now trying to shoehorn my PEQ into a DSP accelerated gstreamer element ( https://github.com/felipec/gst-dsp is quite useful ) that outputs directly to McASP from the DSP side.
 
In terms of software support I'm creating a layer for Angstrom Distribution with my changes and a few custom recipes. I picked up the TI EVM last week so I can really start work in earnest now.

Amongst my many tasks
- trying to figure out the McASP initialization and setup on the DSP side and how I can switch between i2s and DIT per serializer and also data direction.
- selection of a good 20Mhz system clock.

In terms of hardware the board will be fully populated. I expect to have a breakout board for i2s and SPDIF at the time of release.
 
I've been doing some top level planning regarding the gstreamer crossover /dsp setup. See below.

http://www.lucidchart.com/publicSegments/view/4f5a9e77-e7f0-4740-9db3-53d40a7c6148

The crossover editor will be a node based system, similar to what you find in modern 3d rendering/compositor apps. See Soft Image ICE, Blender etc. The node tree data structure and params will be sent to the DSP for processing. It editor could quite easily be web app so you can update your crossovers in your arm chair with and iPad 3 adjusting tweeter delays and phase on the fly.
 
I've been doing some top level planning regarding the gstreamer crossover /dsp setup. See below.

http://www.lucidchart.com/publicSegments/view/4f5a9e77-e7f0-4740-9db3-53d40a7c6148

The crossover editor will be a node based system, similar to what you find in modern 3d rendering/compositor apps. See Soft Image ICE, Blender etc. The node tree data structure and params will be sent to the DSP for processing. It editor could quite easily be web app so you can update your crossovers in your arm chair with and iPad 3 adjusting tweeter delays and phase on the fly.

I love the DSP user interface on the KX-Project. It's extremely intuitive and they make it easy for others to create plug-ins (DSP processing blocks) that you may connect together to realize routing and processing. I think ease of use is the primary goal here as well as the freedom to design custom processing blocks.
Web interface sounds like a really good idea. Or even just having the Editor run on a remote computer.

233163d1311975700-build-thread-ardor-point-source-monitor-fig2-eq.png


EDIT: I wrote this without any knowledge of GStreamer. I'm reading about it now.
 
Last edited:
Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.