• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Basic sample code for FFT audio frequency spectrum?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Basic sample code for FFT audio frequency spectrum?


  • Subject: Re: Basic sample code for FFT audio frequency spectrum?
  • From: William Stewart <email@hidden>
  • Date: Mon, 9 Jul 2007 11:55:01 -0700

James, et al,

Just to add to Evan's comments; in many respects its not even IP issues that drive this as well - but time. All of the time that everyone puts in here is donated - it is no-one's job to support this list. As such, we try to limit the conversations to specific technical issues about using CoreAudio APIs and how audio and MIDI are expected to work on Mac OS X. We also generally discourage questions of the sort "i want to know how to do X", because (as Evan outlined) that takes a lot to answer.

All of that said, it is perfectly reasonable to ask questions that are general because most of the people on the list have been in similar enough situations to you in the past; we have a lot of sympathy! In some cases too, there are good answers of the "go and have a look at this <CODE/DOC/etc>" variety.

In fact, for your question I have exactly this kind of answer. In Leopard we are shipping some sample code (/Developer/Examples/ CoreAudio) called AUSonogramView that does something along the lines of what you want. It is an audio unit, and it will analyze audio as it passes through it, displaying a live sonogram view of that audio. You can build and run this audio unit in an app like AULab (/ Developer/Applications/Audio). It is provided as a starting off point, so that developers like yourself wanting to this kind of thing will have somewhere to start.

HTH

Bill

On 08/07/2007, at 4:22 AM, James T. Rogers wrote:

Ev, as a retired software/hardware engineer, I understand your concerns for giving away intellectual property. Thank you for sharing the pointers you have provided.

My interest as an amateur radio operator is in building an audio unit that provides the control, filtering and detection for a software defined radio. I don't think my humble efforts would ever be a challenge to your or anyone else's product(s). I cannot speak for the intent of IgnisFatuus so will leave that to him/her. Personally, I was looking for help with the "view". It has been a very long time since I did any work with graphics, and that was on an Apple II!

FFTW, the fastest FFT in the West is open sourced to all who are interested and you can google FFTW to find it and it is quite easily installed as a static library on your intel mac. There is also rather nice documentation and I believe sample code as well.

DttSP (Danger to themselvesSP), a DSP engine by Drs Bob McGwier and Frank Bickle, the leading DSP engineers in our nation today, is also readily available, open sourced and you can folllow its development and references to its use on the "dttsp-linux" group on Yahoo groups. DttSP provides a "radio core" providing filtering, detection, generation of various modes of communication i.e. CW (morse), Single Sideband, FM etc.

I will make one last comment, the thing about protecting your intellectual property is certainly a valid consideration. If your product is as good as it ever can be, then rest easy, you have achieved the perfect application. If it is not, and you share some of your expertise with the "newbie", he/she may take a fresh look and you, indeed, may be rewarded with far more information than you shared, and thus enabling your product to move to the next level. It is for that very reason, a consulting firm I founded in 1986, hired fresh, college level programmers. They brought to our staff, freshness, enthusiasm and an adventurous nature. The things this old man learned from those guys and gals, no institution could ever match. The old addage, "Give in order to receive" is certainly a valid one.

Jim Rogers, W4ATK


On Jul 7, 2007, at 2:41 PM, Evan Olcott wrote:

Matt

I know you're looking for an easy answer, but what you're looking for isn't easy, and people (like myself) spend months implementing and perfecting the things you're trying to describe, and make a living doing it. We're not about to give up all our answers and all our hard work when we have commercial products available that we sell that do this very thing.

I realize that you're looking for something a little bit different, but let me give you a quick run down of why what you're looking for is a little bit complex and will not be an "easy app":

1. Loading an entire audio file into memory is NOT a good idea, especially when you're dealing with large multi-track files that you're talking about. Loading 30MB into memory for a single track will bring your system to a grinding halt before too long. You will need to set up multiple reading buffers that read from specific positions in files at any given time. If you want to deal with different file formats (AIFF, WAV, SDII, CAF), you'll have to treat them all differently. That in itself is a complex task.

2. Getting an FFT of an audio file "as a whole" is not really the way to approach this, as frequencies of certain tracks may change over time. A simple average may not be a useful approach, not to mention what would be the optimal FFT window to use for such a task. Some tracks, like a Kick, may be consistent throughout the song, but drum overheads would not be. You would probably want to do it in groups, or windows, with respect to time - which then brings us to issue 3:

3. Drawing. If you are drawing a spectrogram, be prepared to get into some math regarding logarithmic versus linear in order to get a readable output. Brush up on your algebra and logarithms - be ready for it to be a handful more complex if you want it resizable, scrollable or zoomable. Since a spectrogram is a 2D snapshot (unless you want to animate it), you lose the time dimension. If you want to have respect for time over the course of the song, you'll need to do a sonogram, where you'll have to start thinking about color gradients with respect to amplitudes and how to draw them efficiently in addition to the spectrogram drawing complexities. If you want to do it with any sort of visual speed, brush up on your OpenGL.

4. Implementation. If you're dealing with looking at multiple audio tracks, is your app recording them? Or is this a "sidecar" app for a multitrack app? Why would a user switch back and forth between your app and a multitrack to see a frequency spectrum, when it might just be implemented by the multitrack app eventually anyway? Are you going to monitor all changes to the files the multitrack app makes and update your FFTs? Or are you writing a brand new multitrack app? Besides the already saturated multitrack market, I can tell you that there are other audio companies (not ours) already making new ones as well -- and you may have just given them a new idea.

What you're aiming for is an interesting goal, and I can appreciate the idea. But believe you me, it's not just a simple task, and any developer worth their salt would be investing 6 mo or more in this to get it right, even with a basic implementation. Perhaps you're not looking to make a commercial app out of this, perhaps it's a hobby app...that I can understand. But understand that what you're undertaking is not something that a lot of us are going to just come out and give you the answers for. As they say in tech support, RT(F)M...

You'll need to read up on a lot of different disciplines to do this: Quartz, OpenGL, Accelerate.framework, AudioBufferList, calloc/malloc/general memory management, various audio file format specs, and the list goes on. It's possible to learn it, and it is fun to do, take it from me - I love it. But if you expect us to walk you through it and give you the answers outright, it ain't gonna happen. I don't want to come off as being mean, but you gotta do some of the work yourself. Tough love, indeed.

Ev
Technical Knowledge Officer
Head Programmer/Designer
Audiofile Engineering

http://www.audiofile-engineering.com/



_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40bellsouth.net


This email sent to email@hidden

_______________________________________________ Do not post admin requests to the list. They will be ignored. Coreaudio-api mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden

--
mailto:email@hidden
tel: +1 408 974 4056
________________________________________________________________________ __
"Much human ingenuity has gone into finding the ultimate Before.
The current state of knowledge can be summarized thus:
In the beginning, there was nothing, which exploded" - Terry Pratchett
________________________________________________________________________ __


_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


References: 
 >Re: Basic sample code for FFT audio frequency spectrum? (From: Evan Olcott <email@hidden>)
 >Re: Basic sample code for FFT audio frequency spectrum? (From: "James T. Rogers" <email@hidden>)

  • Prev by Date: Re: True RMS value for audio samples
  • Next by Date: Re: True RMS value for audio samples
  • Previous by thread: Re: Basic sample code for FFT audio frequency spectrum?
  • Next by thread: Logic + Sidechain
  • Index(es):
    • Date
    • Thread