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

Status
Not open for further replies.
Jump to Latest
#21
KOON3876 said:
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 😕
Click to expand...

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
 
#22
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.
 
#23
KOON3876 said:
Now I have Windows+Reaper+my VST, no reason to go Linux.
Click to expand...
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

  • TAS5706_Modules.jpg
    TAS5706_Modules.jpg
    284.4 KB · Views: 384
#24
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
 
#25
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
 
#26
KOON3876;2761937 Most simple / cheap / realtime high speed / open sourced way to have multi I2S(or other hardware interface said:
',pageTitle(),'[/url]
Click to expand...

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.
 
#28
phofman said:
Your route is doubtlessly the most elegant one but requires very deep knowledge of several technologies.
Click to expand...
===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.
 
#29
KOON3876 said:
(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.
Click to expand...

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 🙂
 
#30
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.
 
#31
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.
 
#32
===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.
 
#33
KOON3876
Thanx very much for your work
hope to test fir filters in this week

one more addon
you can use VAC(Virtual audio cable)
In order to use VST not only from foobar
from everything you what!

also for some tests just multichannel 7.1 sound card can be used as output device
 
Status
Not open for further replies.
Top Bottom