AVX based FIR VST, crossover / EQ / DRC and delay

[soundcheck]

Originally Posted by KOON3876

Hi Soundcheck,
FFT based PC crossover setup on Windows is easy.
https://sites.google.com/site/koonau...-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

[KOON3876]

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.

[KOON3876]

Originally Posted by KOON3876

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.

[soundcheck]

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

[KOON3876]

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/koonau...ti-channel-i2s

[phofman]

Originally Posted by KOON3876;2761937
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
[url=http://www.knjn.com/shop.html

',pageTitle(),'[/url]

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.

[qusp]

you guys seen this rigisystems board?

[KOON3876]

Originally Posted by phofman

Your route is doubtlessly the most elegant one but requires very deep knowledge of several technologies.

===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.

[phofman]

Originally Posted by KOON3876

(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

[KOON3876]

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.