• 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: sample data types (iOS)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: sample data types (iOS)


  • Subject: Re: sample data types (iOS)
  • From: Brian Willoughby <email@hidden>
  • Date: Fri, 11 Feb 2011 20:16:50 -0800


On Feb 11, 2011, at 18:40, Schell Scivally wrote:
What is the proper way to scale the right 24 bits of an 8.24 SInt32 into a SInt16?

Assuming you're treating 8.24 as SInt32, you should start by rounding or dithering the value to 16-bit. One rounding technique would be to add 0x00000080 to the SInt32 before subsequent shifting and truncating. 0x00000080 is equivalent to adding 0.5 to the SInt16 result, as we're familiar with doing when rounding float. Dithering is a bit advanced, so I won't get into it in a brief email, but rounding is far better than plain truncation if you can't manage true dither. There is no need to do both rounding and dithering, though, so choose whichever one you can handle. Sites like MusicDSP.org have workable examples of Triangular Probability Density Function dither if you feel like tackling something beyond simple rounding.


To prevent overflow, you should saturate the value by comparing to 0x007FFFFF and 0xFF800000, then clipping any values that fall outside that range - i.e., values larger than 0x007FFFFF should be set to 0x007FFFFF, while values below 0xFF800000 should be set to 0xFF800000. After the above steps have been completed at 32-bit resolution, you can shift right by 8 bits and then convert the lowest 16 bits of the SInt32 result into an SInt16. Because the rounding/ dithering is done at higher than 16-bit resolution, the 'lost' bits will not represent excessive quantization noise.

Apple probably provides an efficient 32-to-16 conversion in their AudioConverter, but you would probably still have to handle rounding/ dithering before calling the converter, and I don't think Apple provides saturation (clipping) either. In OSX, saturation is handled in the audio driver, but that only works when the canonical format is float. On iOS, there is no way to distinguish out-of-range values after converting to SInt16, so you'll have to handle it yourself before creating the SInt16. I would usually recommend leveraging Apple's code, but it seems that AudioConverter is missing too many necessary steps.

It might be helpful to write all of the above in assembly, or using intrinsics for efficiency. At the very least, check your code to make sure that you're not using inefficient math. The optimizing compiler will probably do a nearly optimal job, but it's always possible that your particular coding style might result in inefficient operations.

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: 
 >sample data types (iOS) (From: Schell Scivally <email@hidden>)
 >Re: sample data types (iOS) (From: Brian Willoughby <email@hidden>)
 >Re: sample data types (iOS) (From: Schell Scivally <email@hidden>)
 >Re: sample data types (iOS) (From: Schell Scivally <email@hidden>)
 >Re: sample data types (iOS) (From: Brian Willoughby <email@hidden>)
 >Re: sample data types (iOS) (From: Miles Egan <email@hidden>)
 >Re: sample data types (iOS) (From: Schell Scivally <email@hidden>)

  • Prev by Date: Re: Changing buffer size on iOS when app is in background
  • Next by Date: Simple play notes example/help
  • Previous by thread: Re: sample data types (iOS)
  • Next by thread: Re: sample data types (iOS)
  • Index(es):
    • Date
    • Thread