[email protected] <[email protected]> wrote: >> Regarding: >>> Smartphone manufactures, for whatever reason, >>> sometimes design a sound system that delivers 22,150 samples per >>> second when my app requests that more standard 22,050. By the way, >>> this has not been a problem with Apple devices (iPhone/iPad), which >>> all seem to be close enough to nominal without custom calibration. >>> But Android devices and Windows laptops are a different story. > > On Tue, 29 Jan 2013 10:23:56 +0100, Uwe Klein > <[email protected]> wrote: > >>Can you modify your software to be rate agnostic/flexible? >>the samling rate error you show is 4000ppm while crystal deviation >>should not go beyond 50 .. 100 ppm ( 1 "cent" should be ~416ppm !?) >> > > My software is flexible with regard to audio sampling rate, provided I > know what that rate is. And that is exactly what my calibration does > - discover the actual sampling rate by comparison to an external > standard. When I said that some devices give me 22,150 samples per > second instead of 22,050 that was something I discovered through > calibration. There is no way for me to tell internally that the > sampling rate is 22,150. These devices do have an API that returns > what they think the actual sample rate is based on what I requested. > But even on the devices that are giving me 22,150 samples that API > still claims the sample rate is the requested 22,050. That API is > mostly for use when a non-standard sampling rate is requested and the > system has to find the nearest standard sampling rate that it can > support. > > That 4000 ppm deviation is probably systematic and intentional, but > you will have to ask the OEMs who designed the devices exactly what > their intentions were in doing so. I merely repond to what observe.
My theory would be that they require some crystal frequency elsewhere in the device, e.g. for UMTS or WiFi operation, and that they divide it by some integer to get the samplerate for the audio device. That saves them the cost and power consumption of an extra crystal oscillator. The given crystal frequency does not evenly divide to 22050 (or 44100), but they have chosen the nearest value. The normal use of the device is not affected, but your special use is. I would find it reasonable if they returned the actual sampling rate, but maybe that causes trouble with apps that don't expect that and error out when the returned rate is not equal to the value they set. Once you have sufficient experience with calibration results and maybe some inside knowledge from the developers of these phones, you may be able to reduce your fine calibration requirement to just a decision between a couple of alternative sample rates. E.g. when you know the rate is either 22050 or 22150, you can select the correct one much easier than when you need to determine the exact rate. What I still don't understand is why you cannot just use the local clock to do the calibration. Are you claiming that the devices that have the 22150 sample rate also have a local clock that is running fast by the same amount? I would not expect that. It would mean the clock would run fast by 6.5 minutes/day, something that some user would certainly notice and rightfully complain about. _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
