DSP plate amplifier solution with FIR filtering?

Status
Not open for further replies.
Jump to Latest
M

msmithers

Member
Joined 2013
#1
Hi,

I'm looking for a cost effective DSP plate amplifier solution (<200 watts), for powered 1 or 2-way loudspeakers, that includes FIR filtering capability. Anyone have any leads?

Here's what I've found so far. (Nothing quite fits the bill.)

Powersoft DCell504 (2ch)
- Amp power higher than needed
- Very noisy due to ADAU17xx DSP but amp channels could possibly be resistor padded.
- FIR only possible using Sigma Studio programming (not Armonia)

MiniDSP PWR-ICE 125
- Just the right amount of power
- Allows for arbitrary biquad coefficent loading
- No FIR

MiniDSP PWR-ICE 125WD + MiniDSP 2x4HD
- Just the right amount of power
- MiniDSP 2x4HD has FIR!!
- Allows for arbitrary biquad coefficent loading
- Combination is expensive and half the DSP capability is wasted in one speaker.
(Could substitute the 2x4HD with the 2x4, but the 2x4 is too noisy.)

Hypex PSC2.400
- Power output a little higher than needed.
- No FIR
- No arbitrary biquad coefficient loading
- Physically quite big

Powersoft LiteMod 1k
- Lower noise than the DCell504
- Much more power than needed.
- No FIR

Regards,
Michael
 
#3
An ARM Cortex-M7 microcontroller should be able to do the job, say two 1024-tap FIR filters operating at 44.1 kHz, providing a frequency resolution of 43 Hz.

You can buy the hardware here : STM NUCLEO-F746ZG

It suffices to manipulate the OTG micro USB connector, for persuading it to appear as a USB sound card dealing with stereo audio, for a Windows PC or for an Android TV-Box.
It suffices to manipulate two I2S ports, available on the expansion connector, for hooking a stereo DAC dealing with the bass, and for hooking a stereo DAC dealing with the treble.
It suffices to organize the way your PC and/or a local infrared remote control will define the listening volume.
Viewed from a certain distance, this looks nearly trivial.

Difficulties appear upon setting up the software development environment. There are so many. STM has one, it's here :
Openstm32.org
You need an utility named CubeF7 for configuring plenty of bits, clocks and peripherals inside the Cortex-M7 chip, it's here :
stm32cubef7.html

Speaking of USB, you need to reuse some USB drivers STM has published, quite complex, supposed to help you, not suited to your particular situation.
Speaking of I2S, you'll find yourself in a desert, needing to dig into the audio codec datasheet for knowing about master or slave, clock master, etc.

It would make sense to define Fc (-6 dB) = 3400 Hz, opting for a tweeter equipped with a rear chamber (own Fc = 850 Hz).

This way, in case you opt for a pseudo Linkwitz-Riley 2nd-order (pseudo because of the FIR filter exhibiting a linear phase), your tweeter will benefit from a 2nd-order highpass electric filtering between 3400 Hz and 850 Hz, receiving -24 dB at 850 Hz roughly. Below 850 Hz, the tweeter would remain at -24 dB, receiving almost no filtering, as the system will rely on its native 2nd-order highpass. That's feasible, that's elegant, provided you maintain the power below 100 watt. Minimal filtering would you say. And phase linear. Worth trying.

The woofer must be a quality woofer, not too big, say 5 inch, not exhibiting valleys and hills until 3400 Hz, and not exhibiting a pronounced directivity until 3400 Hz. The FIR filter will mute its resonances above 3400 Hz.

What about mounting two 5 inch woofers in a WTW configuration, for doubling the deep bass punch ?
The sound wavelength corresponding to 3400 Hz is 10 cm.
Considering a 66 mm tweeter (Tangband), the two woofers get separated by quite a distance. Their centres are separated by approx 70 mm (half woofer) + 70 mm (tweeter) + 70 mm (half woofer) = 21 cm. Which is a quite long distance, compared to the 10 cm of the sound wavelength at 3400 Hz. The blend may not function properly. Not sure the WTW configuration will sound better. Worth trying.

Voilà. If you feel home what's regarding above, you can design your own solution.

Don't worry about designing the actual FIR filters. It's nearly trivial.
Relying on a dual-channel 1024-FFT operating at 44.1 kHz, you need to compare the target acoustic transfer function (in amplitude and in phase), with the bare speaker acoustic function (in amplitude and in phase).
Get a decent mike, a decent mike preamp, and feed the line-in of the sound card that's connected on your PC. Try the Behringer UCA202, as it has RCA connectors. Grab a dual-channel FFT analyzer like spectra-Lab 4.32 running on any Windows PC, and make sure you configure it in dual-channel 1024-FFT for being able to measure both the amplitude, and the phase.
Copy the amplitudes and phases into a spreadsheet.
As said above, compare the target acoustic transfer function (in amplitude and in phase), with the bare speaker acoustic function (in amplitude and in phase).
The result of such comparison, is the required correction. It gets expressed in a 1024-FFT format. Job is nearly done.
Now look. Do an inverse 1024-FFT on such data.
You'll get the impulse response of the required correction function.
I guess you know that such impulse response, describes the convolver that's required to do the correction. In other words, the impulse response of the required correction, is the actual coefficient list of the 1024-tap FIR filter that you require, for doing such correction.

You do this, once for determining the the woofer correction, and once for determining the tweeter correction. No guesswork required.

This is the way to go.
It isn't expensive, what's regarding the hardware.
It is expensive what's regarding the DSP concepts and programming skills. Market price can be as high as one full month mission (180 hours * 100 dollars per hour = 18,000 dollars). Most of the time, the programmer doesn't know about PC audio, USB audio, async USB audio, STM32F7 USB interface, STM32F7 I2S interfaces, practical FFT and inverse-FFT on a PC, not to forget the GUI that you need for displaying the curves, etc.

Most of the time, you'll find yourself paying a lot more, and waiting a lot more, and being very busy, for teaching the basics to the programmer. I wonder when some genius will embrace all this, and come with a solid proposition.
 
#8
Kjeldsen said:
He was asking for a ready made solution. Not one that requires 5 years education and heavy investment in gear. He will need to skip the all in one solution and go for a FIR ready DSP front end, or a small PC.
Click to expand...
Unfortunately, most of the time, those ready-made systems don't embed the dual-channel FFT-1024 analyzer that's required for comparing the bare speaker drivers transfer functions (module and phase in frequency domain) with the target transfer functions, enabling to define the woofer 1024-tap FIR filter coefficients, and the tweeter 1024-tap FIR filter coefficients by applying an inverse 1024-FFT on the frequency domain comparison data. The dual-channel FFT-1024 analyzer is missing, because ordinary people and ordinary software developers can't believe that measuring then correcting a speaker driver, is so simple.
 
#9
Hi steph_tsf,

I think you've missed the point of the question. I'm after cost-effective ready-made plate amp solutions. I'm familiar with most of the pro solutions and some studio/hifi, like the miniDSP and Hypex.

It's not necessary to have dual-fft measurement embedded in the DSP. (In fact I've never seen it in pro or hifi solutions. Only in some mixing consoles.) Measurement is usually done by external measurement tools like SMAART, SysTune, REW and the like.

The DSP itself just does IIR biquads, delay, gain, and FIR filtering. FIR filters can be designed from measurements using like FIR Designer (www.eclipseaudio.com.au) - I'm the author. 🙂

Michael

steph_tsf said:
Unfortunately, most of the time, those ready-made systems don't embed the dual-channel FFT-1024 analyzer that's required for comparing the bare speaker drivers transfer functions (module and phase in frequency domain) with the target transfer functions, enabling to define the woofer 1024-tap FIR filter coefficients, and the tweeter 1024-tap FIR filter coefficients by applying an inverse 1024-FFT on the frequency domain comparison data. The dual-channel FFT-1024 analyzer is missing, because ordinary people and ordinary software developers can't believe that measuring then correcting a speaker driver, is so simple.
Click to expand...
 
#10
#12
msmithers said:
Hi steph_tsf, it's not necessary to have dual-fft measurement embedded in the DSP. Measurement is usually done by external measurement tools like SMAART, SysTune, REW and the like.
Click to expand...
From what I understand, you never witnessed a dual channel FFT-1024 measurement system continuously updating a 1024-tap FIR correction system working in closed loop, in realtime, that you see progressively converging to the target acoustic transfer function. You never witnessed what's happening when you modify the speaker to mike distance, or modify the target acoustic transfer function.

You say "it is not necessary" because you have not perceived yet the weaknesses and quirks of what you are using, currently. You tolerate such situation because by asking a 3rd-party software to take care of the (so important) measurements, assorted to careful averaging (time domain filtering of the FFT data that's continuously fluctuating), assorted to careful blanking (for avoiding ending up doing a room decorrelation job), you exonerate yourself from attaining and guaranteeing an optimal correction.

Possibly, you never succeeded in programming a FFT and/or an inverse FFT, because most "ready made" FFTs and inverse FFTs are underspecified, so you don't know how they organize their index, and/or you don't know what to do with the negative frequencies, etc.
Grab the info here : www.dspguide.com

Possibly, you are reluctant in relying on a typical Microsoft GUI.
Possibly, you want the GUI to run as a webpage.
This way, after recompiling the DSP, both the GUI and the DSP will run on Windows, Linux, Android TV-Box, OpenELEC, and Kodi.

I don't blame you. I'm not agressive towards you. You need to evolve, at your pace. Mastering all this is very rewarding, from an intellectual point of view. It can be very rewarding also, what's regarding money.

Take a blank sheet, and sketch the block diagram for a closed loop dual channel FFT-1024 measurement operating from a pink noise, feeding a 1024-tap FIR filter. There are some surprises, like how many audio inputs and how many audio outputs you need, for natively compensating the ADCs and DACs latencies, for graphing at the same time 1) the unfiltered speaker transfer function, 2) the target transfer function (user defined with some assistance from you), 3) the FIR filter correction that you apply and 4) the transfer function after correction (supposed to match the target transfer function).
This, for a 4-way speaker. I really mean : measuring the result when more than one speaker driver is active. It is getting funny, isn't ? And possibly, managing multiple mikes, like a mike facing the speaker, and another mike angled at 30 degree.

Once the convergence is done, you need to read the 1024 FIR filter coefficients, and revert to a plain trivial software executing the same 1024-tap FIR filtering.

Use MiniDSP USBStreamer.
It provides 8 x I2S in, and 8 x I2S out.
See it here : MiniDSP USBStreamer

Hook a few stereo ADCs and a few stereo DACs on it.
Try operating the USBStreamer in the Async USB audio mode, using a local crystal as master audio clock, especially when the audio is coming from the hard disk, and possibly when you query streamed audio.
Enable a few ASIO audio sources and a few ASIO audio sinks, possibly using callbacks, and you are nearly done.
Steinberg ASIO
PortAudio
PortAudio 2.0

Yes you can !
 
Last edited:
#13
Why wast DSP processing resources on dual FFT measurement - which only gets used during speaker tuning and not when the speaker is running?? I'd rather use the maximum resources of the DSP for filtering.

Also, SMAART and SysTune can do a far better job of realtime measurement, microphone averaging and transfer function calculations with windowing than can be implemented in most DSP's. Yes, they run closed-loop in realtime, so you can see the response change as you update filtering!

(I've coded dual FFT methods before in Matlab and C, but again, SMAART and SysTune are far more convenient.)

Also, taking good loudspeaker measurements often involves averaging measurements from multiple angles. Why do this in realtime with multiple microphones at high cost, when one can take the measurements in sequence, time align them appropriately and average them (including giving weight to directions that are more important) quickly offline?

Please don't presume to know my background and yes, you are being a little aggressive.

The original question was about plate amplifiers with DSP capable of FIR, and other's suggestions of Marani and Raspberry PI's were helpful. Please, let's just stop there.


steph_tsf said:
From what I understand, you never witnessed a dual channel FFT-1024 measurement system continuously updating a 1024-tap FIR correction system working in closed loop, in realtime, that you see progressively converging to the target acoustic transfer function. You never witnessed what's happening when you modify the speaker to mike distance, or modify the target acoustic transfer function.

You say "it is not necessary" because you have not perceived yet the weaknesses and quirks of what you are using, currently. You tolerate such situation because by asking a 3rd-party software to take care of the (so important) measurements, assorted to careful averaging (time domain filtering of the FFT data that's continuously fluctuating), assorted to careful blanking (for avoiding ending up doing a room decorrelation job), you exonerate yourself from attaining and guaranteeing an optimal correction.

Possibly, you never succeeded in programming a FFT and/or an inverse FFT, because most "ready made" FFTs and inverse FFTs are underspecified, so you don't know how they organize their index, and/or you don't know what to do with the negative frequencies, etc.
Grab the info here : www.dspguide.com

Possibly, you are reluctant in relying on a typical Microsoft GUI.
Possibly, you want the GUI to run as a webpage.
This way, after recompiling the DSP, both the GUI and the DSP will run on Windows, Linux, Android TV-Box, OpenELEC, and Kodi.

I don't blame you. I'm not agressive towards you. You need to evolve, at your pace. Mastering all this is very rewarding, from an intellectual point of view. It can be very rewarding also, what's regarding money.

Take a blank sheet, and sketch the block diagram for a closed loop dual channel FFT-1024 measurement operating from a pink noise, feeding a 1024-tap FIR filter. There are some surprises, like how many audio inputs and how many audio outputs you need, for natively compensating the ADCs and DACs latencies, for graphing at the same time 1) the unfiltered speaker transfer function, 2) the target transfer function (user defined with some assistance from you), 3) the FIR filter correction that you apply and 4) the transfer function after correction (supposed to match the target transfer function).
This, for a 4-way speaker. I really mean : measuring the result when more than one speaker driver is active. It is getting funny, isn't ? And possibly, managing multiple mikes, like a mike facing the speaker, and another mike angled at 30 degree.

Once the convergence is done, you need to read the 1024 FIR filter coefficients, and revert to a plain trivial software executing the same 1024-tap FIR filtering.

Use MiniDSP USBStreamer.
It provides 8 x I2S in, and 8 x I2S out.
See it here : MiniDSP USBStreamer

Hook a few stereo ADCs and a few stereo DACs on it.
Try operating the USBStreamer in the Async USB audio mode, using a local crystal as master audio clock, especially when the audio is coming from the hard disk, and possibly when you query streamed audio.
Enable a few ASIO audio sources and a few ASIO audio sinks, possibly using callbacks, and you are nearly done.
See here : sourceforge.net/projects/asio/

Yes you can !
Click to expand...
 
Last edited:
#14
Thanks for pointing SMAART and SysTune. They have more features than SpectraLab 4.32 I'm still relying on.

Embedding a closed-loop measurement system in a plate amp would be perceived as a simple one-stop-shop, but yes, I agree, more MIPS are required, just for the setup, kind of waste like you said.

I guess the ARM Cortex-M7 would be insufficient for this.

I'm confident that the Raspberry Pi 2 model B will be sufficient. The GUI may cost nothing, say a webpage through a smarthone or tablet or computer using WiFi. Unfortunately, the Raspberry Pi is not fully specified, so hooking the required amount of DACs and ADCs properly, without ending up with jitter or noise, remains uncertain.

There are Raspberry PI clones relying on other CPU chips, possibly featuring a TDM interface supporting multichannel audio, possibly exhibiting high quality audio clocks. Sparky

During normal operation, the ADC that was used for the measurements, may be recycled as superviser, measuring audio voltages or audio currents. Thus, practically, there is no waste.

By the way, what kind of audio input do you wish ?
Analog ? SPDIF ? TOSLINK ? USB ? Ethernet ?

Comes the need of governing the volume.

Back in 1994, Philips applied a trick on their DSS940 and DSS930 SPDIF speakers.
 
#15
A possibility is to rely on a $39 Beagle Bone Green. See it here : beagle-bone-green
Alternatively, one can rely on the official $59 Beagle Bone Black : Beagle Bone Black

The advantage over a Raspberry, is that the T.I. Sitara AM335x CPU of the Beagle Bone is fully documented, and followed by a community focusing on Linux Audio. See it here : SDK_Linux_Audio

Clearly, the AM335x McASP (Multichannel Audio Serial Port) supports I2S and TDM.

One could start, studying the way T.I managed Linux to drive a PCM5102a stereo DAC on the AM335x McASP of a Beagle Bone (original white). The PCM5102a requires the McASP to be configured as I2S. See it here : Sitara_Linux_Audio_DAC_Example
The Beagle Bone (original white) is here : Beagle Bone

The I2S lines are roughly the same as TDM lines. The LRCK pin (left / right toggle) becomes a frame_sync pin. The frame contains 4 or 8 audio channels in a row. Thus, having people succeeding in routing the required I2S lines to the 2 x 46 Beagle Bone headers, one can infer that you will succeed in routing the required TDM lines to the 2 x 46 Beagle Bone Black or Beagle Bone Green headers.

You'll find yourself hooking two stereo ADCs, and two stereo DACs. Four audio-in, and four audio-out.
This is all you require for building a closed-loop measurement + self-adjusting FIR filtering system, dealing individually with the 3 channels of a 3-way speaker.

See the attachements. They speak for themselves.
I'm using this, not yet relying on Linux + Beagle Bone.
Currently, I am relying on a Windows PC executing a Flowstone app, hooked to a 4-in 4-out USB soundcard equipped with RCA connectors.
 

Attachments

Last edited:
#16
Read this : AM335x Audio with WM8580 Codec - Sitara Processors Forum - TI E2E Community

This is typical literature about a AM335x CPU that's connected on a WM8580 Multichannel Audio Codec. Over there you'll find typical errors and misconceptions like messing with the clocks (Jarrod merged CLKOUT and MCLK, Josh indicated it was incorrect), and confusing DSP mode with I2S mode (in theory it should be I2S, but Josh measured it as DSP). Last but not least, there are 6 analog channels of audio (outputs), albeit DIN2 and DIN3 remaining unconnected, which may indicate that DIN1 was originally planned to operate in TDM mode. Unfortunately, the WM8580 doesn't support TDM. By the way, one may fear that the WM8580 clocking scheme, quite elaborate with no less than two internal PLLs, has not been setup properly. The quartz is 12 MHz. Some heavy work is still needed for guaranteeing the functionality of the AM335x CPU / WM8580 Multichannel Codec / Linux combination.
 
#17
steph_tsf said:
An ARM Cortex-M7 microcontroller should be able to do the job, say two 1024-tap FIR filters operating at 44.1 kHz, providing a frequency resolution of 43 Hz.

You can buy the hardware here : STM NUCLEO-F746ZG
...
It suffices to manipulate two I2S ports, available on the expansion connector, for hooking a stereo DAC dealing with the bass, and for hooking a stereo DAC dealing with the treble ... Viewed from a certain distance, this looks nearly trivial. ... Difficulties appear upon setting up the software development environment. There are so many. STM has one, it's here :
Openstm32.org ... You need an utility named CubeF7 for configuring plenty of bits, clocks and peripherals inside the Cortex-M7 chip, it's here :
stm32cubef7.html

Speaking of USB, you need to reuse some USB drivers STM has published, quite complex, supposed to help you, not suited to your particular situation.
Speaking of I2S, you'll find yourself in a desert, needing to dig into the audio codec datasheet for knowing about master or slave, clock master, etc.
...
This is the way to go.
It isn't expensive, what's regarding the hardware.
It is expensive what's regarding the DSP concepts and programming skills. Market price can be as high as one full month mission (180 hours * 100 dollars per hour = 18,000 dollars). Most of the time, the programmer doesn't know about PC audio, USB audio, async USB audio, STM32F7 USB interface, STM32F7 I2S interfaces,...
Most of the time, you'll find yourself paying a lot more, and waiting a lot more, and being very busy, for teaching the basics to the programmer. I wonder when some genius will embrace all this, and come with a solid proposition.
Click to expand...

Hi,

I'm just on that path for a some how simpler target: Asynch (ideally) USB input => Crossover + EQ DSP => 2xSPDIF

I'm already working on a STM32F4 that I had and will move to Nucleo F7 if I work the thing out to get the SPDIF output. I went to Keil, then had to switch beacuse of the code size limit to the OpenSTM32. I'm reading the 200p STM programming manual, have printed the 180 pages C programming book, and so on.

I will try to log progress in http://www.diyaudio.com/forums/digi...ow-jitter-achieved-stm32-microcontroller.html.

If you already went there and were ready to help from time to time, I would be very grateful. Entry fee is higher than I expected, but I see a lot of potential in the platform for audio as all the features we are lurking to are there.

My understanding is that one the correct "template" is set-up, developping specific applications could be almost easy.

By the way, one of my worry is a real Asynch USB code for those boards, with control flow feedback. From what I saw, the one they propose looks more like adaptative, modifying the STM32 clock slightly to adjust the flow (frm reading code comments).

Best regards,

JMF
 
#18
steph_tsf said:
An ARM Cortex-M7 microcontroller should be able to do the job, say two 1024-tap FIR filters operating at 44.1 kHz, providing a frequency resolution of 43 Hz.

You can buy the hardware here : STM NUCLEO-F746ZG

It suffices to manipulate the OTG micro USB connector, for persuading it to appear as a USB sound card dealing with stereo audio, for a Windows PC or for an Android TV-Box.
It suffices to manipulate two I2S ports, available on the expansion connector, for hooking a stereo DAC dealing with the bass, and for hooking a stereo DAC dealing with the treble.
It suffices to organize the way your PC and/or a local infrared remote control will define the listening volume.
Viewed from a certain distance, this looks nearly trivial.

Difficulties appear upon setting up the software development environment. There are so many. STM has one, it's here :
Openstm32.org
You need an utility named CubeF7 for configuring plenty of bits, clocks and peripherals inside the Cortex-M7 chip, it's here :
stm32cubef7.html

Speaking of USB, you need to reuse some USB drivers STM has published, quite complex, supposed to help you, not suited to your particular situation.
Speaking of I2S, you'll find yourself in a desert, needing to dig into the audio codec datasheet for knowing about master or slave, clock master, etc.

It would make sense to define Fc (-6 dB) = 3400 Hz, opting for a tweeter equipped with a rear chamber (own Fc = 850 Hz).

This way, in case you opt for a pseudo Linkwitz-Riley 2nd-order (pseudo because of the FIR filter exhibiting a linear phase), your tweeter will benefit from a 2nd-order highpass electric filtering between 3400 Hz and 850 Hz, receiving -24 dB at 850 Hz roughly. Below 850 Hz, the tweeter would remain at -24 dB, receiving almost no filtering, as the system will rely on its native 2nd-order highpass. That's feasible, that's elegant, provided you maintain the power below 100 watt. Minimal filtering would you say. And phase linear. Worth trying.

The woofer must be a quality woofer, not too big, say 5 inch, not exhibiting valleys and hills until 3400 Hz, and not exhibiting a pronounced directivity until 3400 Hz. The FIR filter will mute its resonances above 3400 Hz.

What about mounting two 5 inch woofers in a WTW configuration, for doubling the deep bass punch ?
The sound wavelength corresponding to 3400 Hz is 10 cm.
Considering a 66 mm tweeter (Tangband), the two woofers get separated by quite a distance. Their centres are separated by approx 70 mm (half woofer) + 70 mm (tweeter) + 70 mm (half woofer) = 21 cm. Which is a quite long distance, compared to the 10 cm of the sound wavelength at 3400 Hz. The blend may not function properly. Not sure the WTW configuration will sound better. Worth trying.

Voilà. If you feel home what's regarding above, you can design your own solution.

Don't worry about designing the actual FIR filters. It's nearly trivial.
Relying on a dual-channel 1024-FFT operating at 44.1 kHz, you need to compare the target acoustic transfer function (in amplitude and in phase), with the bare speaker acoustic function (in amplitude and in phase).
Get a decent mike, a decent mike preamp, and feed the line-in of the sound card that's connected on your PC. Try the Behringer UCA202, as it has RCA connectors. Grab a dual-channel FFT analyzer like spectra-Lab 4.32 running on any Windows PC, and make sure you configure it in dual-channel 1024-FFT for being able to measure both the amplitude, and the phase.
Copy the amplitudes and phases into a spreadsheet.
As said above, compare the target acoustic transfer function (in amplitude and in phase), with the bare speaker acoustic function (in amplitude and in phase).
The result of such comparison, is the required correction. It gets expressed in a 1024-FFT format. Job is nearly done.
Now look. Do an inverse 1024-FFT on such data.
You'll get the impulse response of the required correction function.
I guess you know that such impulse response, describes the convolver that's required to do the correction. In other words, the impulse response of the required correction, is the actual coefficient list of the 1024-tap FIR filter that you require, for doing such correction.

You do this, once for determining the the woofer correction, and once for determining the tweeter correction. No guesswork required.

This is the way to go.
It isn't expensive, what's regarding the hardware.
It is expensive what's regarding the DSP concepts and programming skills. Market price can be as high as one full month mission (180 hours * 100 dollars per hour = 18,000 dollars). Most of the time, the programmer doesn't know about PC audio, USB audio, async USB audio, STM32F7 USB interface, STM32F7 I2S interfaces, practical FFT and inverse-FFT on a PC, not to forget the GUI that you need for displaying the curves, etc.

Most of the time, you'll find yourself paying a lot more, and waiting a lot more, and being very busy, for teaching the basics to the programmer. I wonder when some genius will embrace all this, and come with a solid proposition.
Click to expand...

I was interested in a project like this, I have two research paths a cheap and non-cheap path. Pro version uses a SHARC DSP (I'm still studying the hardware interface for a DAC interface)

I have a slight advantage I have a good background in software development, and work alot with Windows, Web UI and back-end, I think alot of work is getting the firmware right, after that the other stuff is just lipstick.

Here is a picture of my progress
pcb_sharc_complete.jpg

SoundsReal - Home

The other route is cheaper and more public accessible, I haven't started on this yet, I might the STM32F7 but I'm looking at the C2000 Delfino F28377S more
launchxl-f28377s_angle_june5.jpg
 
Last edited:
#19
steph_tsf said:
A possibility is to rely on a $39 Beagle Bone Green. See it here : beagle-bone-green
Alternatively, one can rely on the official $59 Beagle Bone Black : Beagle Bone Black

The advantage over a Raspberry, is that the T.I. Sitara AM335x CPU of the Beagle Bone is fully documented, and followed by a community focusing on Linux Audio. See it here : SDK_Linux_Audio

Clearly, the AM335x McASP (Multichannel Audio Serial Port) supports I2S and TDM.

One could start, studying the way T.I managed Linux to drive a PCM5102a stereo DAC on the AM335x McASP of a Beagle Bone (original white). The PCM5102a requires the McASP to be configured as I2S. See it here : Sitara_Linux_Audio_DAC_Example
The Beagle Bone (original white) is here : Beagle Bone

The I2S lines are roughly the same as TDM lines. The LRCK pin (left / right toggle) becomes a frame_sync pin. The frame contains 4 or 8 audio channels in a row. Thus, having people succeeding in routing the required I2S lines to the 2 x 46 Beagle Bone headers, one can infer that you will succeed in routing the required TDM lines to the 2 x 46 Beagle Bone Black or Beagle Bone Green headers.

You'll find yourself hooking two stereo ADCs, and two stereo DACs. Four audio-in, and four audio-out.
This is all you require for building a closed-loop measurement + self-adjusting FIR filtering system, dealing individually with the 3 channels of a 3-way speaker.

See the attachements. They speak for themselves.
I'm using this, not yet relying on Linux + Beagle Bone.
Currently, I am relying on a Windows PC executing a Flowstone app, hooked to a 4-in 4-out USB soundcard equipped with RCA connectors.
Click to expand...

Both the AM335x and BCM2836 Soc was never designed as a Real Time Audio DSP processor, of course it can be used for demonstration purposes but it is not meant for real time audio applications. In digital audio deterministic reliable timing is
very critical, this is why a dedicated Processor or MCU (with enough MIPS) is used there is no Fat running with the firmware, also its very hard to develop code on a BCM2836 that will instruct Linux to place a priority on diy sound DSP code.. well unless you build a new Linux Image with only the critical driver code and have it run as a bare bones RTos.
 
Last edited:
Status
Not open for further replies.
Top Bottom