On 04/19/2011 08:56 AM, Kevin Dixon wrote:
Hello list,
I'm experienced in developing DSP routines in C/C++ for desktop
computers, and have gotten my feet wet on TI MSP430, doing boring
things.
My project chiefly involves implementing a MIDI interface and also
implement an LFO.
I also need to read
On 04/22/2011 09:52 AM, Nils Pipenbrinck wrote:
On 04/21/2011 04:21 AM, Andrew McPherson wrote:
Eventually I hope to communicate with the audio board directly from the C64x,
which could allow very low-latency audio processing while using the ARM for
less time-critical user interaction tasks.
On 04/22/2011 11:44 AM, Nils Pipenbrinck wrote:
My driver is DSP only. It is the low latency posibility that I'm after.
However, I studied the linux kernel driver a lot. If you take the
existing code and change all references from McBSP2 to McBSP3 the driver
will still work and the audio will app
On 11/15/2011 06:30 AM, shanxS wrote:
Could somebody recommend a free software,
This is method is little long, but if you make a bash script it should
work like a charm:
Step 1. Convert wav to mp3 using lame. On bash command will be like:
$ lame -i input.wav output.mp3
Step 2. Convert mp3
On 04/09/2012 10:16 AM, robert bristow-johnson wrote:
i hadn't heard of this dev board before. at
http://www.st.com/internet/evalboard/product/252419.jsp it says that the
single unit prices is US$14.9 . is that right? that's nearly free.
where do the software tools (the compiler/linker/loader/e
On 04/12/2012 05:53 PM, robert bristow-johnson wrote:
it was pretty spare in the mail. essentially just the board and a cute
little card in a bubble box.
Yes, that's pretty much all you get. Bring your own mini-USB cable.
the card has some "Getting started" instructions and number 5. says to
On Apr 12, 2012, at 9:29 PM, robert bristow-johnson wrote:
> well, i just figgered out that this thing has a D/A only. no A/D. so no
> "passing" audio.
Correct. The STM32 MCU has a pretty decent 12-bit multi-channel ADC, as well as
a 2-chl 12-bit DAC, so if you use those you could do some lo
> On 13 Apr 2012, at 06:01, Eric Brombaugh wrote:
>
>> There are builds of ARM GCC that work on the Mac. It's entirely possible to
>> edit/compile on a Mac, but downloading to flash and realtime debug are still
>> iffy.
--
dupswapdrop -- the music-dsp mailing list an
I've been working with some folks who sell DAW plugins to port their synth &
effects code to the Beagleboard and Beaglebone embedded computers. So far it
appears to work pretty well - the Cortex A8 processor is sufficiently powerful
to run the algorithms and the development environment is genera
I've done a bit of audio DSP on the Beagleboard. It worked fine - we
were doing a reasonably complete realtime MIDI synth emulation with
filters, oscillators, lfos, etc running as a foreground application
under Angstrom Linux and it wasn't breaking a sweat.
The paper you referenced gave the co
The STM32F4 series parts are cheap, fast, powerful for their class. Not
really on par with the Cortex A8 and Atom machines but great for embedded.
I've got a little audio signal processing project based on the STM32F4
going now:
http://ebrombaugh.studionebula.com/synth/stm32f4_codec/index.htm
er.
Eric
On 09/25/2012 11:51 AM, Andy Farnell wrote:
How do you develop code for these Eric? What is your toolchain?
best
Andy
On Tue, Sep 25, 2012 at 09:43:09AM -0700, Eric Brombaugh wrote:
The STM32F4 series parts are cheap, fast, powerful for their class.
Not really on par with the Cortex A8
I've been discussing this Adapteva outfit's Kickstarter with a bunch of
other embedded processing / ASIC / DSP guys and it just doesn't add up.
For $99 they're promising a devboard which in addition to their parallel
processing chip also contains a Xilinx Zync SoC that costs more than
$200 in 1
I'm pretty sure this is based on the STM32F4xx series of parts. These
parts are perfectly capable of supporting 16, 24 or even 32-bit audio
data - just depends on the codec you choose. I've got a project with the
STM32F4 and a Wolfson I2S codec:
http://ebrombaugh.studionebula.com/synth/stm32f4
I've done a fair amount of work with dsPIC for audio processing. It's
not a bad architecture - you can program it in C or assembly and the
cost is low. I've been able to do some reasonably complex algorithms on
it - a vocoder, Bode-style frequency shifter, variable delays with sinc
interpolatio
I've used the dsPIC33FJ64GP802 with on-chip stereo audio DAC in a couple of
well-recieved mass-produced products (Euro-rack synth modules) and the on-chip
DAC is decent enough. It does suffer from some limit cycling at 1/2 the sample
rate if you try to drive constant data, but I always ran it at
Yes, I use MPLAB X on Mac, Linux and Windows for developing on Microchip
MCUs. It's... quirky... but it does work.
Eric
On 10/14/2014 04:08 AM, STEFFAN DIEDRICHSEN wrote:
Eric,
Are you using the MPLab IDE? I saw that it runs on Mac OS X as well, which
makes it a bit more attractive.
--
dup
Nice work! Seems like it would be fairly straightforward to add support
for additional hardware platforms. Given that it's open source code,
what's your feeling about this being used as a front-end for other
hardware besides your own?
Eric
On 12/05/2014 01:05 PM, Johannes Taelman wrote:
Hi,
Here's the guts of the Pono:
http://mikebeauchamp.com/2014/12/pono-player-teardown/
DAC is an ESS ES9018K2M
http://www.esstech.com/PDF/ES9018-2M%20PB%20Rev%200.8%20130619.pdf
"32-bit" - Wonder what the actual ENOB is...
Output driver is a discrete design.
Main MCU is apparently a TI OMAP sim
Sean Costello of Valhalla DSP recently presented at the Seattle chapter
of AES with some interesting info on Reverberation.
https://valhalladsp.wordpress.com/2015/06/19/slides-from-my-aes-reverb-presentation/
Doesn't tell you *how* to do it (there are many ways), but it's an
interesting story.
On 11/20/2010 01:00 AM, Ross Bencina wrote:
Nigel Redmon wrote:
Synchronization (between equipment not locked to a master clock).
I've heard that called "asynchronous sample rate conversion" a lot
lately... I have to implement some this week as it happens :/
Been there, but not in an audio c
On Aug 23, 2015, at 6:21 PM, robert bristow-johnson wrote:
>
> hey Peter, why don't you come over to the USENET newsgroup comp.dsp and see
> how nice we are there.
>
> one interesting Russian-American, Vlad, might engage you, but the sad thing
> is that he passed away very recently.
Oh wow -
On 08/29/2016 02:07 AM, Stefan Stenzel wrote:
I strongly recommend Paul’s Teensy as a start for any new DSP development,
especially as a floating point version of this is already planned.
The Cortex-M4 has many special DSP instructions, and it makes much more sense
to program in C/C++ and focu
On 09/06/2016 12:18 PM, Max K wrote:
I narrowed down the selection to these ICs:
- TI Sitara A9 AM4376 (1GHz, 2500DMIPS)
- TI Sitara A8 AM3351/AM3352 (600MHz / 1000MHz, 1200/2000 DMIPS)
- ST STM32F7x6 (Cortex M7 based, up to 216MHz, 462 DMIPS, only one that
comes in a LQFP package)
- Microch
I coded up the spectral freeze core of the Audio Damage "Spectre" module
in a similar way:
http://www.audiodamage.com/hardware/product.php?pid=ADM15
It's a basic phase vocoder with forward and inverse FFTs but we added
some fun little tweaks to shift, stretch and randomize the spectrum. It
ru
ze are you using? Are you running the FFT in a
separate thread?
Giulio
*From:* Eric Brombaugh
*To:* music-dsp@music.columbia.edu
*Sent:* Friday, 16 September 2016, 19:12
*Subject:* Re: [music-dsp] Help w
*From:* Eric Brombaugh
*To:* music-dsp@music.columbia.edu
*Sent:* Friday, 16 September 2016, 19:50
*Subject:* Re: [music-dsp] Help with "Sound Retainer"/Sostenuto Effect
Probably shouldn't reveal
This is what happens when you let "software architects" try to do DSP.
It seems that what he's doing is maximizing instantaneous dynamic range
by subtracting a mixing product. That achieves his goal of normalizing
the sum but adds in anharmonic components that weren't in the original
signals.
The original Csound source has a set of coefficients for this type of
hilbert transform but they don't say how the coefficients were derived
and the performance is fairly lackluster. The only reference I've come
across for this was Olli Niemitalo's:
http://yehar.com/blog/?p=368
He gives a bit
ssage ----
> Subject: Re: [music-dsp] ± 45° Hilbert transformer using pair of IIR APFs
> From: "Eric Brombaugh"
> Date: Sat, February 4, 2017 8:55 pm
> To: music-dsp@music.columbia.edu
> -
t know how i might set up
> an optimization problem. probably the best measure is the negative frequency
> rejection with regard to the positive frequency gain.
>
> r b-j
>
>
>
> ---- Original Message
> Subje
On Feb 5, 2017, at 12:54 PM, robert bristow-johnson wrote:
> using the analytic filter to get the instantaneous amplitude envelope (and,
> also, instantaneous frequency by differentiating phase) is something that
> works only with single sinusoids that are AM'd or FM'd. for music, i think i
>
On 02/05/2017 07:52 PM, robert bristow-johnson wrote:
> I'm curious what aspects of a music make the complex magnitude of the
analytic signal inappropriate for estimating the envelope? In
communications signal processing we use this often, even for signals
that are fairly wide-band with respect
On Feb 6, 2017, at 8:24 PM, robert bristow-johnson wrote:
> > On 02/05/2017 07:52 PM, robert bristow-johnson wrote:
> >>
> >> > I'm curious what aspects of a music make the complex magnitude of the
> >> analytic signal inappropriate for estimating the envelope? In
> >> communications signal proce
On Feb 6, 2017, at 11:19 PM, robert bristow-johnson wrote:
> with a harmonic musical note this beat frequency would be the difference
> between two harmonics, which could be any integer times the fundamental.
> that's much faster than beating. an r.m.s. envelope would be the square root
> of
On 02/07/2017 07:49 AM, Ethan Fenn wrote:
So I guess the general idea with these frequency shifters is something like:
pre-filter -> generate Hilbert pair -> multiply by e^iwt -> take the
real part
Am I getting that right?
Now that I think about it, another application might be in stereo
imagi
As the author of one of the pages listed below I'd note that STM32 + codec is a
fairly capable combination. I'd caution however that the WM8731 may not be the
best choice - the DACs are fine but ADC side is fairly noisy. It's probably
fine for some things, but with a little care and a few extra
+ codec, as far as a
low-cost HW/FW audio prototyping platform.
spencer
On Sun, Feb 19, 2017 at 6:22 AM, Eric Brombaugh mailto:ebrombau...@cox.net>> wrote:
As the author of one of the pages listed below I'd note that STM32
+ codec is a fairly capable combination. I'd cau
Maybe try locking a PLL to the sinewave to get the expected frequency
and phase, then look for differences between them?
Eric
On 01/10/2018 09:08 AM, Benny Alexandar wrote:
Hi,
I want to do some time domain analysis on a sine wave signal which is
continuously streaming.
My objective is to de
I've done a few different systems similar to what you're describing - a
radio front-end tuner that generates baseband I & Q at audio rates
that's then further processed by a DSP to extract true audio.
Normally what I do is slave the DSP rate to the tuner audio rate. That's
usually possible sin
There's an open-source wavetable editor:
https://github.com/AndrewBelt/WaveEdit
This was written by Andrew Belt (author of VCV Rack) under commission
from Synthesis Technology for creating wavetables for their line of
Eurorack wavetable oscillators. Several other Eurorack manufacturers are
al
On 03/10/2018 12:40 PM, Andy Drucker wrote:
Just to note, WaveEdit *does* let you draw in the spectrum. It's the
only tool I can think of that seamlessly allows edits in both domains at
once, and allows non-mathematical users to "puzzle out" the relation
between the two in a hands-on way.
Th
On 05/21/2018 12:35 PM, Chris Cannam wrote:
And I hear what you are saying about the the post, looking at the code
was easier for me:
http://blogs.zynaptiq.com/bernsee/repo/smbPitchShift.cpp
Yes, the actual shifting step is bizarrely crude considering the work done in
the rest of the code (a
On 07/26/2018 01:11 PM, robert bristow-johnson wrote:
even though i have never myself developed anything for any FPGA (i come
from the time of PALs), i still think the non-recurring engineering
costs (NRE) is much higher for FPGA than with an off-the-shelf CPU or DSP.
FPGA implementations of D
Wow - interesting discussion.
I've implemented a real-time SDFT on an FPGA for use in carrier
acquisition of communications signals. It was surprisingly easy to do
and didn't require particularly massive resources, although FPGAs
naturally facilitate a degree of low-level parallelism that you
m, so very suited to
dedicated massively parallel hardware. I know FPGAs are pretty powerful
these days so might well do the job (but some transformations are pretty
cpu-intensive too!). The Bath Uni team said they were using a
"mid-range" graphic card (on a Linux workstation).
Ric
46 matches
Mail list logo
