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: foobar Output Formats - Internal Workings (Read 2858 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

foobar Output Formats - Internal Workings

Hi, I have a question about the internal workings of foobar's "Output data format" setting.  I have an SB Audigy  2 soundcard that has 24 bit playback capabilities.  So, in Preferences -> Playback -> Output if I set the output data format to 24 bit, my understanding is that foobar will internally handle all samples in 24 bit.  For example, if I'm playing back a 24 bit audio file it will read the samples in as 24 bits and do any processing all in 24 bits and then send the data to my soundcard (via DirectSound or WaveOut API) as 24 bit data.

On the other hand, if I'm playing a 16 bit audio file with the "Output data format" setting set to 16 bit it would internally always handle the data in 16 bit format and then send the data to my soundcard (via DirectSound or WaveOut API) as 16 bit data.

What I am uncertain about is how the soundcard itself determines what audio format it will decide to playback the audio at.  Concerning the 24 bit playback example, I think the Audigy2 could choose to playback the 24bit audio as 16bit - or in the 16 bit example I think the Audigy2 could choose to playback as 24 bit.  I think all of this is occuring at some lower level that is not reachable by the DirectSound or WaveOut API's.

Does this make sense what I am saying?  To clarify I will use an example with DirectSound.  If I setup the WAVEFORMATPCMEX structure as follows:

waveFormatPCMEx.Format.wFormatTag = WAVE_FORMAT_EXTENSIBLE;
waveFormatPCMEx.Format.nChannels = 2;
waveFormatPCMEx.Format.nSamplesPerSec = 44100L;
waveFormatPCMEx.Format.wBitsPerSample = 24;
waveFormatPCMEx.Format.cbSize = 22;   
waveFormatPCMEx.Format.nBlockAlign = (waveFormatIEEEFloatEx.Format.nChannels * waveFormatPCMEx.Format.wBitsPerSample) / 8;
waveFormatPCMEx.Format.nAvgBytesPerSec = waveFormatIEEEFloatEx.Format.nBlockAlign * waveFormatPCMEx.Format.nSamplesPerSec;
waveFormatPCMEx.Samples.wValidBitsPerSample = 24;
waveFormatPCMEx.dwChannelMask = 0;
waveFormatPCMEx.SubFormat = KSDATAFORMAT_SUBTYPE_PCM;


...now, if I understand correctly, this is just telling the DirectSound API that the audio samples to be played back will be in a 24 bit format  - it's not dictating that the soundcard playback the audio in 24 bit.  For all we know somewhere beyond the DirectSound API and the actual Audigy 2 hardware a determination will be made at what actual bit resoultion the audio is played back at.  If the OS or soundcard just decides to playback at 16 bit the 24 bit data we've sent will just be converted to 16 bit.

Does that make sense? I've tried to word it the best I could.  I'm very interested in knowing for sure that the audio is played back at 24 bit and not converted to 16 bit somewhere along the line.

Anyone thoughts?  Any feedback would be greatly appreciated.  Thank you.

Terry