• 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: FFT-AU: strange behaviour
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: FFT-AU: strange behaviour


  • Subject: Re: FFT-AU: strange behaviour
  • From: Benjamin Federer <email@hidden>
  • Date: Tue, 17 Apr 2007 11:47:24 +0200

Hi William,

I recently solved my problem. I did some debugging line by line and in the end realized that I
had messed up my memory allocation routines for the arrays, needed by the FFT. It's been a while
since my last C++ intermezzo... Anyway: big thank you for your reply!


But another question popped up: Is there a easier way to debug an AU? I saw some AUDebugDispatcher,
but don't know how to handle it. Is there any documentation about it - besides the code itself?


Sorry, if someone's annoyed by my newbie questions. I'm learning ;-)


.beni



William Stewart schrieb:
Beni,

It looks like you will probably have to do some more learning about using the FFT - in the crash in auval below it is deliberately asking you to do an odd number of samples in your render call (in the Process call, you should see this 137 number come in as the number of frames you have to render). This is not a number that is evenly divisable by a power of 2 (let alone by 4) - so you probably have to deal with this in a particular manner with the FFT algorithm; perhaps do some buffering so that if you don't get enough samples in one call, then you just put those ones in a buffer, return silence (zero) then wait until you get enough. This also shows up to the outside world as latency (and we have an AU Property so that you can report that).

HTH

Bill

On 14/04/2007, at 7:36 AM, Benjamin Federer wrote:

I forgot to include this information from auval:


[...]

RENDER TESTS:
Input Format: AudioStreamBasicDescription: 2 ch, 44100 Hz, 'lpcm' (0x0000002B) 32-bit big-endian float, deinterleaved
Output Format: AudioStreamBasicDescription: 2 ch, 44100 Hz, 'lpcm' (0x0000002B) 32-bit big-endian float, deinterleaved
Render Test at 512 frames
Slicing Render Test at 64 frames
PASS


Render Test at 64 frames, sample rate: 22050 Hz
Render Test at 137 frames, sample rate: 96000 Hz
Bus error


thanks again .beni



Benjamin Federer schrieb:
Hi all,


I am new to this list and got some questions (naturally). I already searched this list's archive
over and over again, but was not finding something useful.


I am trying to do a fft (using the apple real fft provided with the vDSP library)
inside a audio unit. Using the stripped-down fft code from the Apple tutorial works
fine on itself, as well as the audio unit does - without the processing. As soon as
I implement the vDSP routines into process(), the AU behaves strange (I am using
AU Lab for testing, my AU instantiated on the stereo master channel):


- Sometimes it crashes on startup, more often it starts up flawlessly.
- On removing and/or re-instantiating it crashes often but not always.
- As soon as an input device (sfplayer or internal mic) is opened, the AU
either crashes, cuts the audio or passes only one of the stereo channels.
- Once crashed the report tells me this:
Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_INVALID_ADDRESS (0x0001) at 0x3f63f7b7


I am sorry if I am missing something obvious, but as I said, I am new to this subject.
If you know of any sample code about AUs with FFT, please let me know - I guess I am
not the first one trying this.
Also I'd like to request the host's signal vector size or frame packet size (or whatever
it is called within this context). Do you know of any method I could use?



Thanks in advance for any replies

.beni
_______________________________________________
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



_______________________________________________ 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


  • Follow-Ups:
    • Re: FFT-AU: strange behaviour
      • From: William Stewart <email@hidden>
References: 
 >FFT-AU: strange behaviour (From: Benjamin Federer <email@hidden>)
 >Re: FFT-AU: strange behaviour (From: Benjamin Federer <email@hidden>)
 >Re: FFT-AU: strange behaviour (From: William Stewart <email@hidden>)

  • Prev by Date: Re: FFT-AU: strange behaviour
  • Next by Date: Re: 3D Mixer Equal Power Panning - Follow up on panning
  • Previous by thread: Re: FFT-AU: strange behaviour
  • Next by thread: Re: FFT-AU: strange behaviour
  • Index(es):
    • Date
    • Thread