Home > TEST, USB AUDIO > Reading [the True] Sample Rate (and AC-1 FAQ)

Reading [the True] Sample Rate (and AC-1 FAQ)

Russ has been improving some of the code in AC1. Got new code to read the sample rate and I modified it to read Hz instead of KHz. (This sort of tells you that the code is easy to modify)

The sample rate displayed is the sample rate as determined by the Sabre32 DAC in the Buffalo II board. This rate is the true measure of the sample rate as it enters the DAC because it is derived from the DAC’s DPLL register values. This the the best way to check the sample rate especially If you don’t trust what the application or operating system tells you.

According to Russ in this post at diyaudio, monitoring the value of the DPLL registers would give you an indication of the quality of the incoming signal. (You can also modify the code to show you the DPLL register values rather than the sample rate)

Notice that sometimes it adjusts by 1Hz. That is the DPLL adjusting to maintain a lock in the incoming signal.

Note on the value of the sample rate: The variation from ideal (e.g. from 44,100 hz) can be mostly attributed to the accuracy or the crystal and clocks. With the musiland crystal at 100 ppm (typical value) and the Crystek oscillator at 20 ppm one can account for most if not all the variation from ideal. I did some quick calculation with worse case values for the crystal and clock for deriving and detecting a frequency of 192KHz. The Musiland crystal contributed 19.2 hz to the variation and the Buffalo clock 3.8 hz to the variation.

Here is a video showing the sample rate as I changed the sample rate output in the Musiland device driver control panel. (there is some loss of accuracy of a few Hz due to the use of integer operations).

Musiland control panel:

USEFUL TIPS FOR AC1/AC2

FOR LOADING NEW FIRMWARE INTO FEMTO

Install software

  • Loading/burning firmware into FEMTO
  • Download and Install FLIP
  • Copy libusb0.dll from usb directory to bin directory: copy the file C:\Program Files\Atmel\Flip 3.4.1\usb\libusb0.dll to C:\Program Files\Atmel\Flip 3.4.1\bin (Make sure you copy the file because it is needed on both directories)

Insert FEMTO into USB port and do the following sequence:

  • Push HWD button
  • Push RST button
  • Release RST button
  • Release HWD button

At this point Windows will recognize the device and will guide you though the driver installation. Select manual installation and you point the path to: C:\Program Files\Atmel\Flip 3.4.1\usb

Start the software and download firmware

  • Start FLIP
  • Start USB communication: Settings->Communication->USB
  • Select device: Device-Select->AT90USB162
  • Select hex file: File->Load Hex File->filename.hex
  • Click Run

MODIFYING SOFTWARE

Download and Install

  • AVR Studio
  • WinAVR (I think this is for the gcc compiler)

Create a new project

  • Start AVR Studio
  • Create new project

Select AVRGCC type
Select debug platform (I think anything will do)
Select target device (the Femto device)

Import existing files (the file you want to modify)

  • On the left side there are a series of folders right click on each and import existing files

Make your changes and compile

  • Edit source code
  • Save file
  • Build->build all

The hex file is created in a folder called “default” inside your project file. The project file is in the My Documents folder. Then use Flip to burn new code.

About these ads
  1. Russ White
    2010/04/08 at 14:16 | #1

    Don’t you love it when a plan comes together? :)

  2. 2010/06/01 at 09:21 | #2

    it’d be nice to see how the hiface does at this test if any possible :)

  3. Hifiduino
    2010/06/01 at 18:39 | #3

    Hi leeperry, I don’t have a Hiface but…

    In theory, the effect is the same. The clocks in the hiface are also availabe in the 20-100 ppm range. Assuming Hiface is in the business to maximize profits like any other business, then it would be safe to assume that the clock is rated at 100 ppm. It is also fair to assume that a 100 ppm crystal is close to the worse end of the spec because if it were more accurate, it would be marked 10 ppm or 1 ppm, thus commanding a higher price.

    100 ppm of 22.5792 MHz is 2257.92 Hz. So worse case frequency for the clock is 22581457.92 Hz (22.5792 MHz + 2257.92 Hz). Since the L/R clock of the spdif line is the same as a sample frequency, the high frequency clock must be divided by 512 -by the fpga- to arrive at the 44.1Khz frequency.

    22581457.92 Hz divided by 512 = 44104.41 Hz.

  4. 2010/06/01 at 18:52 | #4

    thanks for the details! but at the end of that PDF, m2tech claim to be using 2.5ppm PLL’s: http://www.m2tech.biz/public/pdf/White%20Paper%20on%20hiFace.pdf

  5. Hifiduino
    2010/06/01 at 18:58 | #5

    Possible. I was just looking at common oscillator specifications from Crystek. Even the high end clock used in the Buffalo DAC is specified at 25 ppm and TPA claims a custom build at 20 ppm.

  6. 2010/06/01 at 19:04 | #6

    so the hiface should be able to output 44100.xx if they’re not lying. whether this would be audible over 44105 is open for debate, though.

  7. Hifiduino
    2010/06/01 at 20:47 | #7

    I need to correct myself. The specifications for ppm has to do with frequency stability: how much would the frequency vary as a function of temperature. One can assume that if the temperature is constant, then the frequency would be pretty stable. The number in question is frequency accuracy from the stated value.

    So how much deviation from say 24.576 MHz is not really available from the specification. However one can call a clock 24.576 MHz even though it could measure 24.576499 Hz or even 24.575501 This deviation represents 1000 Hz or 500 Hz from the mid-point which represents 20 ppm

    For the 22.5792 clock, the potential deviation from specified value is 100 Hz (because the frequency needs to be specified with 4 decimal values) or 50 Hz from the midpoint and that is about 2 ppm

    For the musiland 24.000 Mhz clock, the potential maximum deviation from the midpoint is also 20 ppm

    To this value you must add the frequency variation with respect to operating frequency. lets assume that the chip is operating at 40 C whereas the stated frequency is at 20 C and therefore there is lets say 20 ppm variation for a 100 ppm spec’ed part (the 100 ppm typically refers to a temperature variation of 0 to 70C)

    So for the Musiland we come up with 40 ppm and according to my measurements, about half of the variation is still unaccounted for… Maybe the fpga and other circuitry contribute to some of the variations…

  8. 2010/06/01 at 21:34 | #8

    hehehe ok, I think M2tech make it sound like we never heard our music before they released their HiFace…and many ppl will feed you whatever bs to sell their products. I’ve seen some jitter measurements where it was close to the top-range Lynx cards, so if someone w/ the same DAC as yours could run the same test on an Hiface that’d be really great :)

  9. souther
    2010/07/06 at 03:16 | #9

    Amazing!
    How did you calculate from DPLL_NUM?

    • Hifiduino
      2010/07/29 at 00:56 | #10

      The data sheet for the Sabre has the formula to calculate sample rate

  1. 2010/10/15 at 05:23 | #1

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 183 other followers