Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: How do I find out which sample rates my card can output? (Read 21398 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

How do I find out which sample rates my card can output?

Hello guys,

Earlier today I was wondering which sample rates my sound card can output natively (that is, without resampling them) and realized that I had no idea. So, I'd just like to know if there's something I can use in order to find that out.

Thanks in advance.

How do I find out which sample rates my card can output?

Reply #1
Well, you could google the brand and model number of your sound card for starters. Another option is using an output like Asio or Wasapi (which disables windows mixer resampling) and try some formats. Any non-supported format will not work and throw an error.
To found out the native sample rate you're looking for specs on the DAC chip specifically. If you can figure out which one has been used you can look up the spec sheets for it.

How do I find out which sample rates my card can output?

Reply #2
Your soundcard driver knows. Either it is told directly by the device itself as in the case for USB audio protocol, or the author hard-coded the information into the source code.

Now the question is how to ask the driver. The easiest way is in linux which has tools that will ask and tell you. USB cards capabilities are listed too. Or you (or someone else) can look at the source code for your specific card and read the supported rate values. You can run linux e.g. by temporary booting a live CD or flash drive.

In windows - it would take a bit of trial/error as described in the post above. Perhaps someone has already written a tool doing that but I have never heard of it. Surprising as it should be relatively simple.

How do I find out which sample rates my card can output?

Reply #3
To found out the native sample rate you're looking for specs on the DAC chip specifically. If you can figure out which one has been used you can look up the spec sheets for it.


The thread title says it is an onboard "card", so most likely some Realtek codec chip. It can be found out from the datasheet what sample rates it supports, but the Windows driver might not support some rarely used ones like 176400 Hz, even if the hardware does. So, it is best to actually test it like already suggested.

How do I find out which sample rates my card can output?

Reply #4
So, it is best to actually test it like already suggested.

But are certain rates (such as 44.1 and 88.2 kHz) not resampled by the hardware itself? That's what I'd like to avoid.

How do I find out which sample rates my card can output?

Reply #5
Quote
But are certain rates (such as 44.1 and 88.2 kHz) not resampled by the hardware itself? That's what I'd like to avoid.
That's why Propheticus suggested ASIO or WASAPI drivers. 

The standard drivers (WDM?) will do the various conversions and happliy report what the hardware and driver can do together back to the application.  As long as the application and the hardware/driver can share a format, they are happy.

As far as I know, resampling is done by the driver and never truly done in hardware... At least not with a regular consumer soundcard/soundchip.

How do I find out which sample rates my card can output?

Reply #6
But are certain rates (such as 44.1 and 88.2 kHz) not resampled by the hardware itself? That's what I'd like to avoid.
Why?
It's only audiophile if it's inconvenient.

How do I find out which sample rates my card can output?

Reply #7
Earlier today I was wondering which sample rates my sound card can output natively (that is, without resampling them) and realized that I had no idea. So, I'd just like to know if there's something I can use in order to find that out.


It is possible and even not uncommon for an audio interface to disguise the details of its internal operations from the outside world.

One can sometimes infer an audio interface's actual operations from technical tests of frequency response and dynamic range.

For example, an audio interface can read and write data in 24 bit data words, but internally have no more than 8 or 12 or 16 or 20  bits of resolution. It can read and write data at sample rates that are well beyond its actual capabilities.

Properly performed technical tests are very difficult or impossible to spoof.  One can infer actual internal resolution from tests of dynamic range, and frequency response tests can be used to infer actual internal sample rates.  These tests can show the results of resampling and upsampling, for example.



How do I find out which sample rates my card can output?

Reply #8
For example, an audio interface can read and write data in 24 bit data words, but internally have no more than 8 or 12 or 16 or 20  bits of resolution. It can read and write data at sample rates that are well beyond its actual capabilities.


Theoretically they can do anything. But do you have a specific example of such device? Many accept 32bit samples for technical convenience reasons but deploy 24 bit converters, that is very common. But apart of that and the old ac97-resampling-to-48kHz and soundblaster-resampling-to-48kHz  I have not had such experience.

How do I find out which sample rates my card can output?

Reply #9
For example, an audio interface can read and write data in 24 bit data words, but internally have no more than 8 or 12 or 16 or 20  bits of resolution. It can read and write data at sample rates that are well beyond its actual capabilities.


Theoretically they can do anything. But do you have a specific example of such device?


In some sense they may all read and write data that is beyond their actual capabilities because I know of no audio interface that actually performs at the identical same level of dynamic range as would be suggested by the size of the data words it handles. 

Remember, 16 bits should represent something like 93-98 dB unweighted dynamic range depending on the dithering.

There are some pro cards that come close enough to providing 16 bit dynamic range in their 16 bit modes that we can probably give them a pass. 

I know of no audio interface or off-the-shelf DAC or ADC that provides the 144 dB unweighted dynamic range that 24 bit data suggests.

32 bit floating - well that just ain't gonna happen until we discover some new rules of science! ;-)


How do I find out which sample rates my card can output?

Reply #10
Using WASAPI and playing back a 44.1 kHz audio file yields no errors (however, if I put a resampling DSP and set it to upsample the signal to, say, 64 kHz, I _do_ get an error)... does that mean that everything is left as-is by the DAC and the output is basically bit-perfect?

How do I find out which sample rates my card can output?

Reply #11
Most cheap DACs these days have a 24 bit mode. Its usually immeasurably different then 16 bit though.

How do I find out which sample rates my card can output?

Reply #12
Using WASAPI and playing back a 44.1 kHz audio file yields no errors (however, if I put a resampling DSP and set it to upsample the signal to, say, 64 kHz, I _do_ get an error)... does that mean that everything is left as-is by the DAC and the output is basically bit-perfect?


I don't think so. I locked my X-Fi's clock at 44.1k and foobar plays 48k files without errors as well, using WASAPI and empty DSP. It showed an error when playing 37.8k files (Playstation XA format) though.

Also, there are ASIO drivers with resampling capability as well, like ASIO4all and kX drivers.

The safest test method is use another audio interface to record the digital output of your onboard device and analyze it.

How do I find out which sample rates my card can output?

Reply #13
Quote
It is possible and even not uncommon for an audio interface to disguise the details of its internal operations from the outside world.
Right...  That's sort-of a goal of Windows...    i.e. You can send an image to your printer that has higher resolution than your printer, or print-out a size/resolution that requires pixel interpolation or extrapolation, and the application never has to know.  (The application does have to know if the image won't fit on the paper.) 

Basically, Windows sits between the application and the driver.  As long as the application can communicate with Windows, and the manufacturer-supplied driver can communicate with the hardware and Windows, any application can work with any hardware... Good idea, right? 

In the old DOS days, your word processor application would come with a disk-full of printer drivers.    Hopefully, a driver for your printer was included.  If a printer manufacturer introduced a new printer, each application developer would have to write a new driver (or the printer wouldn't work).  If the software company went out of business or was no longer developing drivers for that application, your new printer wouldn't work.  (Well, sometimes it would work, or sort-of-work, with the wrong driver.)

Each driver only worked with one application and one printer.  Your spreadsheet (and other applications) also came with a disk-full of drivers.  It was a mess!!!

With Windows, Microsoft created a standard protocol so as long as the hardware (with the driver) and software can talk to Windows, they don't have to talk to each other...  The application developer doesn't have to know the internal details of the hardware, and the hardware manufacturer doesn't need to know anything about the applications.

How do I find out which sample rates my card can output?

Reply #14
With Windows, Microsoft created a standard protocol so as long as the hardware (with the driver) and software can talk to Windows, they don't have to talk to each other...  The application developer doesn't have to know the internal details of the hardware, and the hardware manufacturer doesn't need to know anything about the applications.


True but it would not have taken much to create a standard low-level protocol exposing the actual sound card capabilities. IMO it is a bit of shame an external company had to deliver one (ASIO), with all the negative effects such as manufacturers having to supply two sets of drivers for a single OS, applications having to support several output modules, and users having to fight this maze.

Hopefully the WASAPI will solve this, a decade late but here.

How do I find out which sample rates my card can output?

Reply #15
To me WASAPI is just frustration. Similar to KS in Win2000 and XP, it seems to be able to bypass resampling but actually soundcard drivers can cheat and let Windows believe some sample rates are natively supported. I am not a programmer so I don't know about the internal differences between KS and WASAPI but the main difference exposed to me is that WASAPI  let users to select a specific sample rate but some of the sample rates are actually resampled. In XP I just need to set the sample rate in my soundcard driver's control panal but now I need to set the sample rate twice in the driver's control panal AND Windows sound properties to prevent resampling.

How do I find out which sample rates my card can output?

Reply #16
Well, that sounds crazy indeed

I do not understand why the application itself cannot talk directly to the soundcard low-level driver (without the resampling/format adjusting layer) and tell the driver to setup the samplerate and buffer sizes for it. If the soundcard is already busy or if the requested parameters are not supported by the soundcard, the request would return error.

Perhaps the wasapi exclusive mode is something like that?

How do I find out which sample rates my card can output?

Reply #17
foobar's WASAPI plugin is running in exclusive mode
http://www.foobar2000.org/components/view/foo_out_wasapi

But this video tells the fact:
http://youtu.be/lJP0ovZObqc

If I am using Creative's native ASIO driver, the control panel of my soundcard will reveal format changes and it will make a switching noise which can only be heard when using analog output (therefore can't be heard in the video).

However, when using WASAPI exclusive mode. The above did not happen because my soundcard driver didn't tell the truth to WASAPI.

People using other audio interfaces may experience differently but if Creative can do that, then it means WASAPI exclusive mode is not 100% reliable in showing the truth to users.

Another thing I observed is that in XP, my soundcard support 32-bit integer playback and recording in internal loopback mode. This can be checked using RMAA, 32-bit integer modes have -194 to -197dB noise (dithering) level but in Win7 it only supports up to 24-bit. When using 32-bit integer mode to test, it shows -400dB. RMAA can't display -inf dB (digital silence), it shows -inf dB as -400dB. That means 32-bit integer is truncated to digital silence.

http://www.hydrogenaudio.org/forums/index....st&p=434295
ASIO, IIRC, is meant as an extremely direct access method to the bare hardware. Floating point I/O on sound cards is quite rare. Anything that would require software floating-point to integer conversion would be bloody painful and might affect latency numbers.


ASIO definitely supports floating point audio, both in 32bit and 64bit precisions.  However, the ASIO driver for most sound cards will probably just refuse the format, or possibly convert it on the fly.

ASIO is not direct access to the bare hardware.  It's simply an API<->driver layer that avoids the OS audio stack, with its associated latency and quality problems.


I guess WASAPI behaves similarly. Maybe there are some potential danger (BSOD or whatever) to let Windows talk to the hardware directly.

How do I find out which sample rates my card can output?

Reply #18
I do not understand why the application itself cannot talk directly to the soundcard low-level driver (without the resampling/format adjusting layer) and tell the driver to setup the samplerate and buffer sizes for it. If the soundcard is already busy or if the requested parameters are not supported by the soundcard, the request would return error.


Its the sound card driver that's resampling. You can talk to whatever you want but unless you wrote the driver you can't be sure what happens.

How do I find out which sample rates my card can output?

Reply #19
Its the sound card driver that's resampling. You can talk to whatever you want but unless you wrote the driver you can't be sure what happens.


There are systems where the kernel driver does nothing else but offers the core functions of the hardware in standardized format, common for all models of that particular type of hardware. The rest is part of userspace libraries, common for all drivers. And your application (i.e. you) can easily specify which part of that chain you want to use. The lowest level does not offer anything extra, the upper layers offer automatic format conversion (very useful), automatic channel count adjustment, automatic resampling to the nearest supported rate, automatic mixing of multiple streams, ... All selected by you, working the same way for ANY supported soundcard. And each layer reports what is currently doing, including the driver which reports the current format, samplerate, channel count entering the soundcard. For any driver, all in the same standardized format. Of course it is possible only because all the drivers share a lot of common code, are not supplied by each manufacturer separately, but are built on top of common code. That is one of advantages of open source, code sharing. Another just as important is you know what your computer actually does.

Those using proprietary systems are missing a lot from their computing experience, especially if they are interested in how hardware actually operates.

How do I find out which sample rates my card can output?

Reply #20
Providing access to low level functions of hardware is a bad idea. Manufacturers will do their own thing and thus you end up having to write code for every card you want to support. The whole point of having a common API above that is that it's common and all software can use it and know what it does. They shouldn't care what happens at the lowest level.

 

How do I find out which sample rates my card can output?

Reply #21
Another thing I observed is that in XP, my soundcard support 32-bit integer playback and recording in internal loopback mode.


Most 24bit PCI  cards as well as many modern USB DACs communicate with the PC in 32bit samples only.

How do I find out which sample rates my card can output?

Reply #22
Providing access to low level functions of hardware is a bad idea. Manufacturers will do their own thing and thus you end up having to write code for every card you want to support. The whole point of having a common API above that is that it's common and all software can use it and know what it does. They shouldn't care what happens at the lowest level.


Of course, the low level API I am talking about (linux alsa) is common for all soundcards. They all share basically the same functionalities. They differ only in parameters of these functionalities.

BTW it is similar to USB audio v.2 - that is an API too.

How do I find out which sample rates my card can output?

Reply #23
Another thing I observed is that in XP, my soundcard support 32-bit integer playback and recording in internal loopback mode.


Most 24bit PCI  cards as well as many modern USB DACs communicate with the PC in 32bit samples only.


My meaning is in XP, the soundcard support true 32-bit integer resolution (internal loopback mode) but in Win7 it only supports 24-bit padded to 32-bit. Of course there is no audible difference but in fact something is actually lost.

When using external I/O (SPDIF), actual quality is always 24-bit only, in both XP and Win7

How do I find out which sample rates my card can output?

Reply #24
Providing access to low level functions of hardware is a bad idea. Manufacturers will do their own thing and thus you end up having to write code for every card you want to support. The whole point of having a common API above that is that it's common and all software can use it and know what it does. They shouldn't care what happens at the lowest level.


Of course, the low level API I am talking about (linux alsa) is common for all soundcards. They all share basically the same functionalities. They differ only in parameters of these functionalities.

BTW it is similar to USB audio v.2 - that is an API too.


Alsa is little different then on windows. You still have no idea what the sound card is clocked at.