Hi Soundcheck,
FFT based PC crossover setup on Windows is easy.
https://sites.google.com/site/koonaudioprojects/exau2i-FFT-crossover
maybe there will be another free VST (FFT EQ) and VST host.
bruteFIR is FFT based, algorithm O(N x log N). not required to be faster.
straight FIR algorithm is O(N x M), so large N,M requires much computing power.
for exaU2I now there is Mac driver, please ask exa065 for source or Linux.
? soundwise
I mean - what do you prefer -- your SD-player or the PC as transport??
I doubt that exa065 would hand out sources. The port to Linux would be pretty difficult I guess.
If I look at the Reaper VST etc stuff under Windows, I'd prefer a brutefir/mpd/squeezeplayer setup ( see Vortexbox) on a headless Linux machine.
Cheers
Hi Soundcheck,
If I'm satisfied with conventional IIR filter, I just need my SDHC player + TAS5518 amplifier.
SDHC - dsPIC33 - TAS5518 - TAS5142 x 4
(File) - (read and I2S) - (4way crossover, PWM) - (8ch driver)
This is minimum 4 way multi-amp system as far as I know.
I want to have "True" FIR system, so I need computing power(some GMACS, Giga multiply and add per second).
previous it was CUDA but now AVX can work for me.
Now I have Windows+Reaper+my VST, no reason to go Linux.
If I'm satisfied with conventional IIR filter, I just need my SDHC player + TAS5518 amplifier.
SDHC - dsPIC33 - TAS5518 - TAS5142 x 4
(File) - (read and I2S) - (4way crossover, PWM) - (8ch driver)
This is minimum 4 way multi-amp system as far as I know.
I want to have "True" FIR system, so I need computing power(some GMACS, Giga multiply and add per second).
previous it was CUDA but now AVX can work for me.
Now I have Windows+Reaper+my VST, no reason to go Linux.
I mean.. in this ASIO environment, Windows sound system does nothing.
Single Clock on the exaU2I pulls all data stream.
===============
Attached, I made 3 of TAS5706 amplifier module.
Left: original TAS5706 amplifier, supply I2C volume control
upper 3 modules: TAS5706 I2S input amplifier.
mid: buffer board, by 74HC541/74HC574, very clean waveform
lower right: exaU2I
Crossover is in the PC, so TAS5706 just accepts I2S for each driver (Low, MidL, MidH, High).
One MCU will control volume through I2C. PIC, Atmel, Arduino, anything can do.
Attachments
Cool. A very nice and simple solution
Looks much simpler, that new board layout.
Ok. You left out the SPDIF/Toslink stuff. That makes live much easier.
And no more preregulation for the 3.3V?!?!?
What are the buffers for?
No more PIC??
Why don't you let the I2S traces run staight to a header? The sharp corner
routing is not that good, I think.
Now I just need to find a three-way I2S interface for Linux.
I won't go that Windows route. I really want a little headless no frills Linux blackbox that does the DSP job.
Cheers
Looks much simpler, that new board layout.
Ok. You left out the SPDIF/Toslink stuff. That makes live much easier.
And no more preregulation for the 3.3V?!?!?
What are the buffers for?
No more PIC??
Why don't you let the I2S traces run staight to a header? The sharp corner
routing is not that good, I think.
Now I just need to find a three-way I2S interface for Linux.
I won't go that Windows route. I really want a little headless no frills Linux blackbox that does the DSP job.
Cheers
Hi Soundcheck
Pre-regulation: there was no heat on previous board, so removed. (and no more CS8416, TOSLINK receiver)
Buffers: for the case if driving ability of NVE isoLoop is not sufficient.
PIC: still exists on master board. issues I2C command to all 4 boards at same time.
I2S trace: I care fast (>10MHz) signal and power lines, but other signals usually I don't care, just connect them.
=======================
just FYI, I don't have this plan.
Most simple / cheap / realtime high speed / open sourced way to have multi I2S(or other hardware interface, already used for CNC) output from Linux should be
http://www.knjn.com/shop.html
Dragon PCI board: can be accessed from PCI memory area.
it has prototyping area to place IL712 isolation, 74HC541 buffers, TCXO and power supply.
and modify my VHDL posted here. this VHDL does not require USB, only require FIFO and master clock.
https://sites.google.com/site/koonaudioprojects/usb-to-multi-channel-i2s
Pre-regulation: there was no heat on previous board, so removed. (and no more CS8416, TOSLINK receiver)
Buffers: for the case if driving ability of NVE isoLoop is not sufficient.
PIC: still exists on master board. issues I2C command to all 4 boards at same time.
I2S trace: I care fast (>10MHz) signal and power lines, but other signals usually I don't care, just connect them.
=======================
just FYI, I don't have this plan.
Most simple / cheap / realtime high speed / open sourced way to have multi I2S(or other hardware interface, already used for CNC) output from Linux should be
http://www.knjn.com/shop.html
Dragon PCI board: can be accessed from PCI memory area.
it has prototyping area to place IL712 isolation, 74HC541 buffers, TCXO and power supply.
and modify my VHDL posted here. this VHDL does not require USB, only require FIFO and master clock.
https://sites.google.com/site/koonaudioprojects/usb-to-multi-channel-i2s
Your route is doubtlessly the most elegant one but requires very deep knowledge of several technologies. IMO the most simple and least expensive way is to use any 7.1 card based on Envy24 (Revolution 7.1, Prodigy7.1, etc.) and tap the I2S lines of ICE1724. Multiple clock crystals, clock logic, PCI logic, drivers for all major OSes, datasheet, all is there ready to use and the price on ebay is negligible.
===off topic===
Hi phofman,
Once Linux people make their own PCI digital sound card, the life of the card = life of PCI bus. should be very longer than Envy24 card inventory.
And the minimum cost will be, PCI blank board ($30?) + small FPGA (< $10).
I'm looking here
fpga4fun.com - PCI Reads and Writes
fpga4fun.com - PCI software driver for Linux
It looks like easy to make some visible memory on the Dragon PCI card, and read/write them from Linux (so easy, than windows).
(1) Linux sound driver should have some samples of PCM data
(2) and, it will check the request/status register.
(3) If available, write next data. cycle will be 1msec or so. no IRQ required.
(4) I2S VHDL module will process byte by byte, to I2S. this is just a parallel - Serial conversion and sample VHDL already exists.
I am afraid such setup without DMA would be very prone to underruns. The need to refresh via CPU every 1ms is pretty strict. Plus would there be enough IO space available for 1ms of 192/24/8channels?
For pure playback, I prefer setting the DMA buffers to max, feeding fresh samples to the buffer just a few times a second, or even less often, and let the card do its job via DMA for the rest of the time.
Of course all of that can be programmed on the FPGA, but that is why I am talking about the level of knowledge required
I see, that is a "deep knowledge". DMA, IRQ, large SRAM buffer on board, and related drivers.
I thought Linux people who uses audio functions, mainly using RT-Linux. (I heard Ubuntu studio Kernel is realtime linux)
(1) normal Linux, large buffer, DMA, interrupt: deep knowledge for VHDL, driver
(2) RT-Linux, tiny task runs every msec, only to pass Audio buffer to PCI board.
I thought method (2), this is simple.
192/24/8 uses 4608 bytes / msec. XC2S100 has 40K block RAM, it's enough.
I thought Linux people who uses audio functions, mainly using RT-Linux. (I heard Ubuntu studio Kernel is realtime linux)
(1) normal Linux, large buffer, DMA, interrupt: deep knowledge for VHDL, driver
(2) RT-Linux, tiny task runs every msec, only to pass Audio buffer to PCI board.
I thought method (2), this is simple.
192/24/8 uses 4608 bytes / msec. XC2S100 has 40K block RAM, it's enough.
I know very little about PCI, but would not this The size limit of IO space in each BAR of a PCI card cause a problem with 4kB of PCI IO space, using the mentioned simple in/out calls?
Your solution would certainly work but I would not want to use it in a more demanding or more multitasking environment. The RT linux kernel is just soft realtime and having to refresh the card every 1ms regardless of the actual latency required sounds like a tough call to me.
Your solution would certainly work but I would not want to use it in a more demanding or more multitasking environment. The RT linux kernel is just soft realtime and having to refresh the card every 1ms regardless of the actual latency required sounds like a tough call to me.
===sorry still off topic===
Thanks phofman
”The RT linux kernel is just soft realtime”
oh. really? Then it will be hard to execute every msec.
should have large buffer, like IDT72V04 FIFO memory. (handling FIFO is much easy, than handling RAM from FPGA, and FIFO can be expanded)
and by using FIFO there are no limitation problem for I/O area address issue.
anyway, there is at least 1 way to build completely free / open digital sound card for Linux.
Thanks phofman
”The RT linux kernel is just soft realtime”
oh. really? Then it will be hard to execute every msec.
should have large buffer, like IDT72V04 FIFO memory. (handling FIFO is much easy, than handling RAM from FPGA, and FIFO can be expanded)
and by using FIFO there are no limitation problem for I/O area address issue.
anyway, there is at least 1 way to build completely free / open digital sound card for Linux.
"As Sound Card"..?
Reaper has the component "ReaRoute", It looks like ASIO device from other player software.
and VST component can be connected to ReaRoute.
I posted how-to here.
https://sites.google.com/site/koonaudioprojects/exau2i-FFT-crossover
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.