• 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: Peak and averagePowerForChannel are nice, but what about the actual current power?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Peak and averagePowerForChannel are nice, but what about the actual current power?


  • Subject: Re: Peak and averagePowerForChannel are nice, but what about the actual current power?
  • From: Brian Willoughby <email@hidden>
  • Date: Mon, 18 May 2009 01:19:05 -0700

Hi Ochen,

Hamish has done a fine job of responding to your other questions, as well as explaining how complex the issue is. If you survey all of the programs out there which have to solve your problem, you'll find a slightly different technique in each of them.

So I will just comment on a question that referred to something I wrote...

On May 15, 2009, at 21:39, Ochen Kaylan wrote:
Average not spanning multiple buffers: I'm not sure I follow you here. The only time I'm having a problem with falloff is using the AVAudioPlayer meter functions. Are you saying that there is a way to set the falloff time of AVAudioPlayer meter readings? I'm not aware of one, so if there is, can you point me to where I can find out more about it? If you're saying that by using AudioQueue, I can limit falloff, why would I do that if I can access the actual sample levels and avoid falloffs all together? I don't think I'm following what you're saying.


I left out one important distinction. Analog meters effectively take an average of the signal over a period of time. This has nothing to do with buffers, because only digital audio is buffered. In order to get a digital meter response that behaves like an analog meter, the code must process buffers of audio samples, but must also maintain some sort of state between buffers so that the time frame average is continually shifting. One side effect of a large time window is the falloff time you're seeing. An analog meter has this same falloff time, but it's usually a capacitor or inductor holding the state.

Basically, I skipped over all of this and hinted that if you don't want the falloff time, then you don't need a sliding time window for your average. You can simply look at your buffers of audio samples and make a calculation based on the current sample in the buffer, with no consideration of state from any previous buffers. I admit that it was a bit confusing to jump directly from your desire to eliminate the falloff time to my comments about not saving state between buffers.

As for your questions about AVAudioPlayer meters, I'm saying that what you want is not compatible. You have to process the audio samples yourself. They will be provided to your code in buffers, not one sample at a time. You cannot remove the falloff time from the AVAudioPlayer meters, but you can implement your own metering code without falloff. I never made any statements about AVAudioPlayer being capable of providing what you want.

In general, meters are designed for real-time display of the current level. But you're trying to draw a waveform overview, and that really requires quite different code than a meter. You're going to have to write this code yourself, you won't be able to efficiently use the AVAudioPlayer meters, and you'll have to process the entire audio file in buffers or blocks.

Brian Willoughby
Sound Consulting

_______________________________________________
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: 
 >Peak and averagePowerForChannel are nice, but what about the actual current power? (From: Ochen Kaylan <email@hidden>)
 >Re: Peak and averagePowerForChannel are nice, but what about the actual current power? (From: Hamish Allan <email@hidden>)
 >Re: Peak and averagePowerForChannel are nice, but what about the actual current power? (From: Ochen Kaylan <email@hidden>)
 >Re: Peak and averagePowerForChannel are nice, but what about the actual current power? (From: Hamish Allan <email@hidden>)
 >Re: Peak and averagePowerForChannel are nice, but what about the actual current power? (From: email@hidden)
 >Re: Peak and averagePowerForChannel are nice, but what about the actual current power? (From: Hamish Allan <email@hidden>)
 >Re: Peak and averagePowerForChannel are nice, but what about the actual current power? (From: email@hidden)
 >Re: Peak and averagePowerForChannel are nice, but what about the actual current power? (From: Hamish Allan <email@hidden>)
 >Re: Peak and averagePowerForChannel are nice, but what about the actual current power? (From: email@hidden)
 >Re: Peak and averagePowerForChannel are nice, but what about the actual current power? (From: Brian Willoughby <email@hidden>)
 >Re: Peak and averagePowerForChannel are nice, but what about the actual current power? (From: Ochen Kaylan <email@hidden>)

  • Prev by Date: Rendering to a file
  • Next by Date: Re: MIDI Sequencing (data structs & speed)
  • Previous by thread: Re: Peak and averagePowerForChannel are nice, but what about the actual current power?
  • Next by thread: callback still being called after AudioQueue is disposed
  • Index(es):
    • Date
    • Thread