Phase correction accuracy depends on FIR filter length. In turn and as you pointed out, latency also depends on filter length. It's a trade-off
Can you explain what you would use limiters for?
Yes, via expansion port.
Excellent ideas!
Streaming of 2 channels is within the capabilities of the board.
There's plenty of tools available for free download from freescale's website. I personnaly use only the assembler: makes tight and efficient code
I don't believe there's a free C/C++ compiler out there.Consider me ready to drop cash
Cool
Updated list of requirements:
- up to 4-way crossovers
- Multi-platform (Python?)
- high-pass filters, low-pass filters, shelving filters, Notch filters
- Arbitrary slopes for all filters
- phase correction
- Attenuators
- Time delays
- Equalisation, with selectable preset/programmed filters
- system status (meters, inputs and muted channels).
- Control outputs to turn on/off/mute power amplifiers.
- Importing of measurements (impulse response or .frd), then visualizing/optimizing filters.
- Presets (full system) selectable by buttons
- Output limiters
- Digital volume control via rotary encoder or analog pot.
- USB audio streaming
- up to 4-way crossovers
- Multi-platform (Python?)
- high-pass filters, low-pass filters, shelving filters, Notch filters
- Arbitrary slopes for all filters
- phase correction
- Attenuators
- Time delays
- Equalisation, with selectable preset/programmed filters
- system status (meters, inputs and muted channels).
- Control outputs to turn on/off/mute power amplifiers.
- Importing of measurements (impulse response or .frd), then visualizing/optimizing filters.
- Presets (full system) selectable by buttons
- Output limiters
- Digital volume control via rotary encoder or analog pot.
- USB audio streaming
During times of vinyl, analogue recordings and RIAA levels output limiters in home/theater were probably not necessary. However, nowadays If you listen to a lot of digital formats from a computer like mp3, wav, flac etc.. they are invariably recorded at different levels. If you listen to your system fairly loud and then for example go to the bathroom during a track change the volume level can increase dramatically and you can find yourself running for the volume control! If you have a output limiter set it means you don't need to keep adjusting the volume levels.
col.
col.
Yes Python is cool
Python looks like the best solution for this project, because it's free and portable for most of the features.
There are a few issues though: Windows users will need to install Python (i think it's included by default on Mac and most Linux distributions), and every user will need to have the same version.
Also GUI stuff is not so much cross-platform i think.
Finally the wrapper for FTDI's API i had in mind is only for Windows...
Let's wait and see
I love python as well but package management and various versions can be a pain. On windows I think you may also need gTk or similar, but I'm not sure, I only do GUIs on the mac and X11.
Given that all but the crusty macs are intel based, if your app can run in wine, then you'll have the mac and Linux platforms covered albeit not as elegantly as with a cross-platform app.
Sheldon
Given that all but the crusty macs are intel based, if your app can run in wine, then you'll have the mac and Linux platforms covered albeit not as elegantly as with a cross-platform app.
Sheldon
The other solution would be to write the processing libraries in Ansi C/C++, and have only the GUI and USB stuff platform dependent.
That's probably the nicest solution in terms of performance and integration, but that also means more code to maintain and more development tools.
Are you thinking of a Windows application running on all hardware platforms? (with VM or equivalent)
WINE is an open source implementation of the Windows API. It's available for OSX and Linux.
WineHQ
WineBottler - Run Windows Programs directly on OS X for OSX
WineHQ
WineBottler - Run Windows Programs directly on OS X for OSX
I suggest you avoid unnecessary levels of complexity where possible. Consider how many users would be willing to dabble with unfamiliar operating system setups and compilations. If possible, make it a simple plug 'n play into Windows as the default app, but make the source code available to those who wish to port to other platforms.
For now, the Wine option seems the most attractive... assuming that Windows users do not have to install Wine as well...?
For now, the Wine option seems the most attractive... assuming that Windows users do not have to install Wine as well...?
Yeah, this topic is really a struggle. Try to avoid emulations (like wine). I think (IMO) it's probably worthwhile to attempt to manage the most cross-platform packages available. I think managing a bundle like GTK+ and Python for each platform might be worthwhile. Yeah, it's pain in the butt creating builds for each platform, but the results will be consistent.
And there's always Flex, if you can manage the USB interface from Flex; not too sure about that. But wow, very cross-platform.
..Todd
And there's always Flex, if you can manage the USB interface from Flex; not too sure about that. But wow, very cross-platform.
..Todd
Last edited:
FTDI is making a rather nice API/driver package for their chips.
I'd rather that we stick to it and use a Python wrapper as necessary so that we don't transform a DSP problem into a USB driver one. In my experience, a proper USB management can be a real pain...
This said, this thread is the right place for discussing this kind of issue, and i appreciate your input. I'll check Flex when i have time.
Maybe I'm a heretic, but as a Mac user on an Intel mac, I can run any software you can throw at me. It's trivial to run windows (either in a VM or native), the same goes for Linux. I can't speak for everyone, but I'd want the best quality most reliable and robust software you can produce. If that means a windows executable, I'll deal with it. So I'd recommend that you code in the environment that you are comfortable and proficient in (that's xcode for me), that will produce the best code. After it's out there and the devices are working, then we can think about porting the code.
Sheldon
Sheldon
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.