• 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: Audio recording bitdepth
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Audio recording bitdepth


  • Subject: Re: Audio recording bitdepth
  • From: Bjorn Roche <email@hidden>
  • Date: Wed, 9 Dec 2009 18:22:57 -0500


On Dec 9, 2009, at 2:24 PM, Paul Davis wrote:

On Wed, Dec 9, 2009 at 2:07 PM, Bjorn Roche <email@hidden> wrote:

At the risk of starting a flame war, here is my follow-up:

http://blog.bjornroche.com/2009/12/linearity-and-dynamic-range-in-int.html

although i appreciate the focus of the two posts is on audio quality (as it should be), it would be instructive to follow up with a measure of the cache cost of using a conditional to determine negativity in the asymmetric method. cachegrind should do this relatively easily. we ran some small not very representative tests when revisiting the JACK ALSA backend conversion code and concluded that cost in branch-induced cache misses was larger than we were willing to pay in exchange for the extra sample value. although there are many cases where the user may wish to put fidelity over cpu cost, at least being able to estimate the likely cost (say, per channel of N bit samples at a given SR) would aid people in making this choice wisely.


Thanks for your comments. Perhaps I will look into it. I do this a lot and it's never come up for me in profiling, so it's not a big enough deal for me to care for my own purposes.

I am a bit confused by your comments, though: I think in this case you aren't going to deal with cache misses. The likely performance issue is branch prediction failures. If that turns into a cache problem somehow, it's beyond my knowledge. To my understanding, in the worst case, an incorrect branch predication should flush the processor pipeline. I don't really see that happening though, since each loop contains independent data, so on a branch prediction failure it should be able to continue with the next data even when the last data failed. Of course, should and does are different, but, again, that's where the profiler comes in.

	bjorn

-----------------------------
Bjorn Roche
XO Wave
Digital Audio Production and Post-Production Software
http://www.xowave.com
http://blog.bjornroche.com
http://myspace.com/xowave


_______________________________________________ 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: Audio recording bitdepth
      • From: "Ross Bencina" <email@hidden>
References: 
 >Re: Audio recording bitdepth (From: Doug Wyatt <email@hidden>)
 >Re: Audio recording bitdepth (From: Bjorn Roche <email@hidden>)
 >Re: Audio recording bitdepth (From: Bjorn Roche <email@hidden>)
 >Re: Audio recording bitdepth (From: Bjorn Roche <email@hidden>)
 >Re: Audio recording bitdepth (From: Paul Davis <email@hidden>)

  • Prev by Date: Re: Audio recording bitdepth
  • Next by Date: Re: Audio recording bitdepth
  • Previous by thread: Re: Audio recording bitdepth
  • Next by thread: Re: Audio recording bitdepth
  • Index(es):
    • Date
    • Thread