Re: Peak and averagePowerForChannel are nice, but what about the actual current power?
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>) |