cannot disable resampling for ICH6 (OSS4)

[cesium]

I have already tried your magic tool on another computer. It works. It printed on terminal certain parameters which you loaded into ioctl.

Well, you can tell by the result what the program is really doing. If you apply it on pcm_play, you can tell how it set up the card. "strace -e trace=ioctl,open" should tell us if it really overrides vmix.

ALSA is said to have a secret file /proc/asound/card0/pcm0p/sub0/hw_params
where you may find all the information you need.
Is it possible to find such information in OSS4?

Usually 'ossinfo -v3' (for card info) and 'ossmix -a' (for mixer controls) have all the useful info. For more specalized stuff, 'cat /dev/sndstat' has the OSS build parameters (if one built it manually this might be useful). If one is interested in startup logs than /var/log/soundon.log (which contains 'ossinfo -v3' output already) is useful.

[igorzwx]

I have already tried your magic tool on another computer. It works. It printed on terminal certain parameters which you loaded into ioctl.

Well, you can tell by the result what the program is really doing. If you apply it on pcm_play, you can tell how it set up the card. "strace -e trace=ioctl,open" should tell us if it really overrides vmix.

ALSA is said to have a secret file /proc/asound/card0/pcm0p/sub0/hw_params
where you may find all the information you need.
Is it possible to find such information in OSS4?

Usually 'ossinfo -v3' (for card info) and 'ossmix -a' (for mixer controls) have all the useful info. For more specalized stuff, 'cat /dev/sndstat' has the OSS build parameters (if one built it manually this might be useful). If one is interested in startup logs than /var/log/soundon.log (which contains 'ossinfo -v3' output already) is useful.

I need the current state of the device during the process of playing.

I tested "trace=ioctl,open" on another computer (not Intel HDA) with "ossplay -R" and "pcm_play -e".
This is the result:

Code: Select all

$ ./strac* -e trace=ioctl,open ossplay *.wav -R
open("/etc/ld.so.cache", O_RDONLY)      = 3
open("/lib/libdl.so.2", O_RDONLY)       = 3
open("/lib/libc.so.6", O_RDONLY)        = 3
open("/dev/dsp", O_WRONLY|O_EXCL)       = 3
ioctl(3, 0x4004501e, 0xbfb5bc3c)        = 0
open("Tabla.wav", O_RDONLY) = 4
open("/dev/dsp", O_WRONLY|O_EXCL)       = 3
ioctl(3, 0x4004501e, 0xbfb5b17c)        = 0
ioctl(3, 0x40405902, 0xbfb5bcb4)        = 0
ioctl(3, SNDCTL_DSP_GETODELAY or SNDCTL_DSP_PROFILE, NORMAL => NORMAL) = 0
ioctl(3, SNDCTL_DSP_SETFMT or SOUND_PCM_READ_BITS, S16_LE => S16_LE) = 0
ioctl(3, SNDCTL_DSP_CHANNELS or SOUND_PCM_READ_CHANNELS, 2 => 2) = 0
ioctl(3, SNDCTL_DSP_SPEED or SOUND_PCM_READ_RATE, 44100 => 44100) = 0
^C

Code: Select all

$ ./strac* -e trace=ioctl,open pcm_play *.wav -s oss -f 48000 -b 16 -e
open("/etc/ld.so.cache", O_RDONLY)      = 3
open("/usr/lib/libasound.so.2", O_RDONLY) = 3
open("/usr/lib/libstdc++.so.6", O_RDONLY) = 3
open("/lib/libm.so.6", O_RDONLY)        = 3
open("/usr/lib/libgcc_s.so.1", O_RDONLY) = 3
open("/lib/libc.so.6", O_RDONLY)        = 3
open("/lib/libpthread.so.0", O_RDONLY)  = 3
open("/lib/libdl.so.2", O_RDONLY)       = 3
open("/lib/librt.so.1", O_RDONLY)       = 3
=================================================================
Module Info:

Short name: WAVE Player
Long name : Player for WAVE PCM file
Copyright : Copyright (c) 2009-10 PetrovSE
Version   : 1.0.3.4
Build     : Oct  9 2010, 19:23:46
=================================================================

open("Tabla.wav", O_RDONLY) = 3
Opening file "Tabla.wav" ...Ok.
Samples rate    = 44100 Hz
Channels        = 2
Bits per sample = 16 (fixed)

Sample rate converter is activated.

Wave system [oss]: Open Sound System
open("/dev/dsp", O_WRONLY|O_EXCL)       = 4
ioctl(4, 0x4004501e, 0xbfa5e24c)        = 0
ioctl(4, SNDCTL_DSP_SETFRAGMENT, maxfrags: 8, fragsize : 4096 => maxfrags: 8, fragsize : 4096) = 0
ioctl(4, SNDCTL_DSP_SETFMT or SOUND_PCM_READ_BITS, S16_LE => S16_LE) = 0
ioctl(4, SNDCTL_DSP_CHANNELS or SOUND_PCM_READ_CHANNELS, 2 => 2) = 0
ioctl(4, SNDCTL_DSP_SPEED or SOUND_PCM_READ_RATE, 48000 => 48000) = 0
ioctl(4, SNDCTL_DSP_GETOSPACE => bytes : 32768, fragments : 8, fragsize : 4096, fragstotal : 8) = 0
ioctl(4, SNDCTL_DSP_RESET)              = 0
Wave device []: "/dev/dsp" !

H/W parameters:
Samples rate    = 48000 Hz
Channels        = 2
Bits per sample = 16 (fixed)

[#--------------------------------------------------] ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(0, SNDCTL_TMR_START or TCSETS, {B38400 opost isig -icanon -echo ...}) = 0
[------#--------------------------------------------] [>>]  0:06 (149 ms)     
Done.
ioctl(0, SNDCTL_TMR_START or TCSETS, {B38400 opost isig icanon echo ...}) = 0


What is telling about "vmix"? It may tell exactly that what the programmer loaded to ioctl.

The question is: "What does this test tell us about 'overriding vmix'. Do we need some other tests to clarify what is really going on?"

[cesium]

open() uses the O_EXCL flag when opening /dev/dsp, so pcm_play does try to override vmix. We can tell pcm_play is telling the truth about H/W params by comparing it's device setup ioctls (SNDCTL_DSP_SPEED/SNDCTL_DSP_SETFMT/SNDCTL_DSP_CHANNELS args) to its output which is the same. We can see also that it tries to choose fragments' number/size in advance, which isn't being told to us by the programs' output.

[igorzwx]

open() uses the O_EXCL flag when opening /dev/dsp, so pcm_play does try to override vmix. We can tell pcm_play is telling the truth about H/W params by comparing it's device setup ioctls (SNDCTL_DSP_SPEED/SNDCTL_DSP_SETFMT/SNDCTL_DSP_CHANNELS args) to its output which is the same. We can see also that it tries to choose fragments' number/size in advance, which isn't being told to us by the programs' output.

It is still confusing for me.
Does "ossplay -R" override vmix?
Does "pcm_play -e" override vmix?

[cesium]

Both of them do, unless you modified "excl_policy" setting in osscore.conf.

[igorzwx]

Both of them do, unless you modified "excl_policy" setting in osscore.conf.

This means that you think that they do, and it is probably the case.
But the problem is that I need a method with which I can test if it is true, or not.
Is there any other method to test this?

[cesium]

Try to open the same device with another program while they play. If it fails, vmix is (temporarily) disabled. It the playback is too short to test, you can give '-l' switch to ossplay to loop it.

[igorzwx]

Try to open the same device with another program while they play. If it fails, vmix is (temporarily) disabled. It the playback is too short to test, you can give '-l' switch to ossplay to loop it.

Thanks!!! Now it looks much more credible.

Code: Select all

$ ossplay *.wav
/dev/dsp: Device or resource busy

There is some other application using this audio device.
Exit it and try again.
You can possibly find out the conflicting application bylooking

Do you have other ideas?

I will test all these with ICH6 as soon as I can.

[igorzwx]

Fujitsu-Siemens notebook, Intel HDA ICH6

Code: Select all

$ lspci | grep Audio
00:1b.0 Audio device: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) High Definition Audio Controller (rev 04)

Code: Select all

$ ossinfo -a -v9

Audio devices
HD Audio play front               /dev/oss/oss_hdaudio0/pcm0  (device index 0)
    Legacy device /dev/dsp0
    Caps: DUPLEX TRIGGER MMAP
    Modes: IN/OUT
      Out engine  1: 0/HD Audio play front
                     Available for use
      Engine      2: 7/HD Audio play front (vmix)
                     Available for use
      Engine      3: 8/HD Audio play front (vmix)
                     Available for use
      Engine      4: 9/HD Audio play front (vmix)
                     Available for use
      Engine      5: 10/HD Audio play front (vmix)
                     Available for use
    Input formats (0x00001010):
      AFMT_S16_LE   - 16 bit signed little endian
      AFMT_S32_LE   - 32 bit signed little endian
    Output formats (0x00001010):
      AFMT_S16_LE   - 16 bit signed little endian
      AFMT_S32_LE   - 32 bit signed little endian
    Device handle: PCI201717c0-0000:00:1b.0-au01
    Related mixer dev: 0
    Sample rate source: 0
    Preferred channel configuration: Not indicated
    Supported number of channels (min - max): 2 - 8
    Native sample rates (min - max): 8000 - 48000 (8000,11025,16000,22050,32000,44100,48000)
    HW Type: Not indicated.
    Minimum latency: Not indicated

HD Audio play rear                /dev/oss/oss_hdaudio0/pcm1  (device index 1)
    Legacy device /dev/dsp1
    Caps: TRIGGER MMAP
    Modes: OUTPUT
      Out engine  1: 1/HD Audio play rear
                     Available for use
    Input formats (0x00001010):
      AFMT_S16_LE   - 16 bit signed little endian
      AFMT_S32_LE   - 32 bit signed little endian
    Output formats (0x00001010):
      AFMT_S16_LE   - 16 bit signed little endian
      AFMT_S32_LE   - 32 bit signed little endian
    Device handle: PCI201717c0-0000:00:1b.0-au02
    Related mixer dev: 0
    Sample rate source: 0
    Preferred channel configuration: Not indicated
    Supported number of channels (min - max): 2 - 2
    Native sample rates (min - max): 8000 - 48000 (8000,11025,16000,22050,32000,44100,48000)
    HW Type: Not indicated.
    Minimum latency: Not indicated

HD Audio play center/LFE          /dev/oss/oss_hdaudio0/pcm2  (device index 2)
    Legacy device /dev/dsp2
    Caps: TRIGGER MMAP
    Modes: OUTPUT
      Out engine  1: 2/HD Audio play center/LFE
                     Available for use
    Input formats (0x00001010):
      AFMT_S16_LE   - 16 bit signed little endian
      AFMT_S32_LE   - 32 bit signed little endian
    Output formats (0x00001010):
      AFMT_S16_LE   - 16 bit signed little endian
      AFMT_S32_LE   - 32 bit signed little endian
    Device handle: PCI201717c0-0000:00:1b.0-au03
    Related mixer dev: 0
    Sample rate source: 0
    Preferred channel configuration: Not indicated
    Supported number of channels (min - max): 2 - 2
    Native sample rates (min - max): 8000 - 48000 (8000,11025,16000,22050,32000,44100,48000)
    HW Type: Not indicated.
    Minimum latency: Not indicated

HD Audio play spdif-out           /dev/oss/oss_hdaudio0/spdout0  (device index 3)
    Legacy device /dev/dsp3
    Caps: TRIGGER MMAP
    Modes: OUTPUT
      Out engine  1: 3/HD Audio play spdif-out
                     Available for use
    Input formats (0x00000410):
      AFMT_S16_LE   - 16 bit signed little endian
      AFMT_AC3      - AC3 (Dolby Digital) encoded audio
    Output formats (0x00000410):
      AFMT_S16_LE   - 16 bit signed little endian
      AFMT_AC3      - AC3 (Dolby Digital) encoded audio
    Device handle: PCI201717c0-0000:00:1b.0-au04
    Related mixer dev: 0
    Sample rate source: 0
    Preferred channel configuration: Not indicated
    Supported number of channels (min - max): 2 - 2
    Native sample rates (min - max): 44100 - 48000 (44100,48000)
    HW Type: Not indicated.
    Minimum latency: Not indicated

HD Audio play modem               /dev/oss/oss_hdaudio0/mdmout0  (device index 4)
    Legacy device /dev/dsp4
    Caps: TRIGGER MMAP
    Modes: OUTPUT
      Out engine  1: 4/HD Audio play modem
                     Available for use
    Input formats (0x00000010):
      AFMT_S16_LE   - 16 bit signed little endian
    Output formats (0x00000010):
      AFMT_S16_LE   - 16 bit signed little endian
    Device handle: PCI201717c0-0000:00:1b.0-au05
    Related mixer dev: 0
    Sample rate source: 0
    Preferred channel configuration: Not indicated
    Supported number of channels (min - max): 1 - 1
    Native sample rates (min - max): 8000 - 16000 (8000,9600,16000)
    HW Type: Not indicated.
    Minimum latency: Not indicated

HD Audio rec rec-srcmic-mix       /dev/oss/oss_hdaudio0/pcmin0  (device index 5)
    Legacy device /dev/dsp5
    Caps: DUPLEX TRIGGER MMAP
    Modes: IN/OUT
      In engine   1: 5/HD Audio rec rec-srcmic-mix
                     Available for use
      Engine      2: 7/HD Audio play front (vmix)
                     Available for use
      Engine      3: 8/HD Audio play front (vmix)
                     Available for use
      Engine      4: 9/HD Audio play front (vmix)
                     Available for use
      Engine      5: 10/HD Audio play front (vmix)
                     Available for use
    Input formats (0x00001010):
      AFMT_S16_LE   - 16 bit signed little endian
      AFMT_S32_LE   - 32 bit signed little endian
    Output formats (0x00001010):
      AFMT_S16_LE   - 16 bit signed little endian
      AFMT_S32_LE   - 32 bit signed little endian
    Device handle: PCI201717c0-0000:00:1b.0-au06
    Related mixer dev: 0
    Sample rate source: 0
    Preferred channel configuration: Not indicated
    Supported number of channels (min - max): 2 - 2
    Native sample rates (min - max): 8000 - 48000 (8000,11025,16000,22050,32000,44100,48000)
    HW Type: Not indicated.
    Minimum latency: Not indicated

HD Audio rec modem                /dev/oss/oss_hdaudio0/mdmin0  (device index 6)
    Legacy device /dev/dsp6
    Caps: TRIGGER MMAP
    Modes: INPUT 
      In engine   1: 6/HD Audio rec modem
                     Available for use
    Input formats (0x00000010):
      AFMT_S16_LE   - 16 bit signed little endian
    Output formats (0x00000010):
      AFMT_S16_LE   - 16 bit signed little endian
    Device handle: PCI201717c0-0000:00:1b.0-au07
    Related mixer dev: 0
    Sample rate source: 0
    Preferred channel configuration: Not indicated
    Supported number of channels (min - max): 1 - 1
    Native sample rates (min - max): 8000 - 16000 (8000,9600,16000)
    HW Type: Not indicated.
    Minimum latency: Not indicated


Nodes
  /dev/dsp -> /dev/oss/oss_hdaudio0/pcm0
  /dev/dsp_in -> /dev/oss/oss_hdaudio0/pcm0
  /dev/dsp_out -> /dev/oss/oss_hdaudio0/pcm0
  /dev/dsp_ac3 -> /dev/oss/oss_hdaudio0/spdout0
  /dev/dsp_mmap -> /dev/oss/oss_hdaudio0/pcm0
  /dev/dsp_multich -> /dev/oss/oss_hdaudio0/pcm0


TEST with strace + "pcm_play -e"

Code: Select all

$ ./strac* -e trace=ioctl,open pcm_play *.wav -s oss -f 48000 -b 32 -e
open("/usr/lib/libv4l/v4l1compat.so", O_RDONLY) = 3
open("/etc/ld.so.cache", O_RDONLY)      = 3
open("/usr/lib/libasound.so.2", O_RDONLY) = 3
open("/usr/lib/libstdc++.so.6", O_RDONLY) = 3
open("/lib/libm.so.6", O_RDONLY)        = 3
open("/usr/lib/libgcc_s.so.1", O_RDONLY) = 3
open("/lib/libc.so.6", O_RDONLY)        = 3
open("/lib/libpthread.so.0", O_RDONLY)  = 3
open("/usr/lib/libv4l1.so.0", O_RDONLY) = 3
open("/lib/libdl.so.2", O_RDONLY)       = 3
open("/lib/librt.so.1", O_RDONLY)       = 3
open("/usr/lib/libv4l2.so.0", O_RDONLY) = 3
open("/usr/lib/libv4lconvert.so.0", O_RDONLY) = 3
=================================================================
Module Info:

Short name: WAVE Player
Long name : Player for WAVE PCM file
Copyright : Copyright (c) 2009-10 PetrovSE
Version   : 1.0.3.4
Build     : Oct  9 2010, 19:23:46
=================================================================

open("Sonate.wav", O_RDONLY) = 3
Opening file "Sonate.wav" ...Ok.
Samples rate    = 44100 Hz
Channels        = 2
Bits per sample = 16 (fixed)

Sample rate converter is activated.

Wave system [oss]: Open Sound System
open("/dev/dsp", O_WRONLY|O_EXCL)       = 4
ioctl(4, 0x4004501e, 0xbfe4112c)        = 0
ioctl(4, SNDCTL_DSP_SETFRAGMENT, maxfrags: 8, fragsize : 8192 => maxfrags: 8, fragsize : 8192) = 0
ioctl(4, SNDCTL_DSP_SETFMT or SOUND_PCM_READ_BITS, S32_LE => S32_LE) = 0
ioctl(4, SNDCTL_DSP_CHANNELS or SOUND_PCM_READ_CHANNELS, 2 => 2) = 0
ioctl(4, SNDCTL_DSP_SPEED or SOUND_PCM_READ_RATE, 48000 => 48000) = 0
ioctl(4, SNDCTL_DSP_GETOSPACE => bytes : 65536, fragments : 8, fragsize : 8192, fragstotal : 8) = 0
ioctl(4, SNDCTL_DSP_RESET)              = 0
Wave device []: "/dev/dsp" !

H/W parameters:
Samples rate    = 48000 Hz
Channels        = 2
Bits per sample = 32 (fixed)

[#--------------------------------------------------] ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(0, SNDCTL_TMR_START or TCSETS, {B38400 opost isig -icanon -echo ...}) = 0
[--#------------------------------------------------] [||]  2:40 (149 ms)

Verification TEST:

Code: Select all

$ ossplay *.wav
/dev/dsp: Device or resource busy

There is some other application using this audio device.
Exit it and try again.
You can possibly find out the conflicting application bylooking

TEST with strace + "ossplay -R"

Code: Select all

$ ./strac* -e trace=ioctl,open ossplay *.wav -R
open("/usr/lib/libv4l/v4l1compat.so", O_RDONLY) = 3
open("/etc/ld.so.cache", O_RDONLY)      = 3
open("/lib/libdl.so.2", O_RDONLY)       = 3
open("/lib/libc.so.6", O_RDONLY)        = 3
open("/usr/lib/libv4l1.so.0", O_RDONLY) = 3
open("/usr/lib/libv4l2.so.0", O_RDONLY) = 3
open("/lib/libpthread.so.0", O_RDONLY)  = 3
open("/usr/lib/libv4lconvert.so.0", O_RDONLY) = 3
open("/lib/librt.so.1", O_RDONLY)       = 3
open("/lib/libm.so.6", O_RDONLY)        = 3
open("/dev/dsp", O_WRONLY|O_EXCL)       = 3
ioctl(3, 0x4004501e, 0xbfcbe05c)        = 0
open("Sonate.wav", O_RDONLY) = 4
open("/dev/dsp", O_WRONLY|O_EXCL)       = 3
ioctl(3, 0x4004501e, 0xbfcbd59c)        = 0
ioctl(3, 0x40405902, 0xbfcbe0d4)        = 0
ioctl(3, SNDCTL_DSP_GETODELAY or SNDCTL_DSP_PROFILE, NORMAL => NORMAL) = 0
ioctl(3, SNDCTL_DSP_SETFMT or SOUND_PCM_READ_BITS, S16_LE => S16_LE) = 0
ioctl(3, SNDCTL_DSP_CHANNELS or SOUND_PCM_READ_CHANNELS, 2 => 2) = 0
ioctl(3, SNDCTL_DSP_SPEED or SOUND_PCM_READ_RATE, 44100 => 44100) = 0
^C

Verification TEST:

Code: Select all

$ ossplay *.wav
/dev/dsp: Device or resource busy

There is some other application using this audio device.
Exit it and try again.
You can possibly find out the conflicting application bylooking

In both tests, the same audio file was played: 16bit, 44100Hz

pcm_play made explicit resampling to 48kHz

ossplay made a kind of implicit resampling to 48kHz in the sense that the file was resampled by an invisible resampler of low quality. It might be a kind of HW resampler inside the soundcard, or it might be something else.

To verify the existence of the invisible resampler, I created two test file with Audacity Nyquist:

Code: Select all

$ ls
10Hz+20kHz_44800-stereo.wav 
10Hz+20kHz_44100-stereo.wav 

Such files can be created with Audacity in this way:

1. Audacity Menu → Generate → Silence (5 seconds are enough)
2. Audacity Menu → Edit → Duplicate
3. Audacity Track Menu → Audio Track → Make Stereo Track
4. Audacity Menu → Effects → Nyquist prompt

Nyquist command:

Code: Select all

(mult (sum (hzosc 10) (hzosc 19500)) 0.49)

TEST 1 (44800Hz - silence):

Code: Select all

$ ossplay 10Hz+20kHz_44800-stereo.wav -Rl

TEST 2 (44100Hz - specific sound):

Code: Select all

ossplay 10Hz+20kHz_44100-stereo.wav -Rl

Now, if programs might try to use different rates, then you'll need a resampler somewhere... and since the card likely has no HW SRC, you need a software one. If vmix's SRC isn't good enough - you can try a software audio server. ESD, Pulse, JACK, the late NaS and aRts etc. etc.

"Pulse" means "PulseAudio". Right?
If I understood you correctly, you going to say something like this: "Install PulseAudio and forget about problems". Right?
This is your message to the ignorant. Right?

To summarize: The clear-cut empirical tests proved the existence of an invisible resampler.

1. If you believe that ICH6 has no HW SRC, could you please explain how to disable the invisible resampler of OSS4?

2. If you agree that ICH6 has HW SRC, could you please explain how to verify this?

[cesium]

ossplay made a kind of implicit resampling to 48kHz in the sense that the file was resampled by an invisible resampler of low quality. It might be a kind of HW resampler inside the soundcard, or it might be something else.

Well, we can see it opened the device with 44K, and vmix is not enabled.

If I understood you correctly, you going to say something like this: "Install PulseAudio and forget about problems". Right?
This is your message to the ignorant. Right?

I was saying that if vmix isn't good enough for a user, there's no choice left to most users.
And In general, I suggest slow migration from ALSA/Pulse, and keeping Pulse and libasound2 installed - otherwise, a user has to fight with the package system on the common distros, and that's a very bad idea for the ignorant.

To summarize: The clear-cut empirical tests proved the existence of an invisible resampler.

1. If you believe that ICH6 has no HW SRC, could you please explain how to disable the invisible resampler of OSS4?

2. If you agree that ICH6 has HW SRC, could you please explain how to verify this?

First, I have looked at the OSS source, and I don't see any "invisible" resampler. If vmix is disabled and there's an SRC it's an HW one. That should appear somewhere in the chip's sheet from intel.

[edit: complicated idea scraped for now]

[igorzwx]

I was saying that if vmix isn't good enough for a user, there's no choice left to most users.
And In general, I suggest slow migration from ALSA/Pulse, and keeping Pulse and libasound2 installed - otherwise, a user has to fight with the package system on the common distros, and that's a very bad idea for the ignorant.

If I understood you correctly, human beings are divided into two main categories: (1) a kind of technocratic elite and (2) the ignorant masses. The latter are not "technically-minded", and, therefore, they are to be treated as children, their participation in decision-making is be restricted, and their freedom of choice is to be restricted too. Right?

It seems that Arch Linux is grounded on another ideology. There is not a division into distinct classes, such as: (1) the elect (e.g. self-proclaimed technocrats) and (2) the ignorant. As a result, you have a kind of democracy without discrimination, "apartheid", or "racial segregation". The developers and the users use the same tools and the same wiki, and the users are invited to vote and contribute their packages to the AUR repository. The freedom of choice seems to be guaranteed.

If you really believe that the users are so stupid, you have to formulated your answers in another way. Otherwise, nobody may understand them.

Since I do not pretend to be "technically-minded", could you please explain in an understandable way how to find out whether ICH6 soundcard has an HW Sample Rate Converter, or not?

[cesium]

I think that most of the ignorance out there is rational - after all, they have people like us to help, right? The crazy stupid people are us who bother with this for free, and therefor we are far too stupid to be running anything (I do recall Eisenhower also warned against a scientific-technological elite as well as the Military-Industrial complex in his exurgal speech).

I had an idea on how to test this but I don't think it would work now (connect output to line-in. Play a low rate output and record it, and than test if the result sounds fine in a low rate. But the recording process's ADC is a sort of SRC too, so I'm not sure how to distinguish...).

[igorzwx]

I think that most of the ignorance out there is rational - after all, they have people like us to help, right? The crazy stupid people are us who bother with this for free, and therefor we are far too stupid to be running anything (I do recall Eisenhower also warned against a scientific-technological elite as well as the Military-Industrial complex in his exurgal speech).

It seems that you like to help. Perhaps, it is nice to be busy with this. However, a kind of LiveCD together with a comprehensible "howto" may essentially reduce the number of questions, and we may have enough time to discuss ideological problems.

Ideology has a practical value, simply because nothing is free. Linux may cost a lot of your valuable time. You may agree to spend your time for this, if the promise is freedom, namely, the freedom of action, that is, the freedom to do what you want and how you want. However, sooner or later, a Windows refugee may arrive to OSS4 forum, where he may learn an "unpleasant truth", which might be revealed in this way: "You will never get the much desired freedom, because you are not intelligent enough to remove PulseAudio".

That should appear somewhere in the chip's sheet from intel.

Such intel sheets usually claim that you can get with Intel HDA anything what you can imagine.
http://www.intel.com/design/chipsets/hdaudio.htm

Intel HD Audio delivers significant improvements over previous generation integrated audio and sound cards. Intel HD Audio hardware is capable of delivering the support and sound quality for up to eight channels at 192 kHz/32-bit quality, while the AC‘97 specification can only support six channels at 48 kHz/20-bit.

I certainly want to have 192 kHz/32-bit quality with ICH6, but what I actually have with Linux drivers for ICH6 is 48 kHz/32-bit quality. I also want to have HW mixing with ICH6. I do have it with ICH4 with ALSA and OSS4. I am not going to take your "market theory of soundcards" for granted. I am not going to fool myself trough the help of your economic theories. When reliable technical information is missing, or it is a secret, the information vacuum might be filled with mythology, but this is not what I am asking for. I do know, although it is a kind of secret, that the algorithm of recording, which is implemented in Linux, is that same lossy algorithm. Therefore, you need at least 192 kHz/32-bit to ensure a minimal quality of digital recording. Why 192 kHz/32-bit? This is because of the voodoo of the lossy sampling algorithm and "failure of bandlimitation" which tends to be "referred to as aliasing"
http://en.wikipedia.org/wiki/Analog_rec ... g#Aliasing
http://en.wikipedia.org/wiki/Nyquist%E2 ... iderations
http://en.wikipedia.org/wiki/Nyquist%E2 ... m#Aliasing
The problem is that the lossy sampling algorithm (which is implemented in Linux for everything, for which it should not be applied) does not satisfy the conditions of the Nyquist theorem

The [Nyquist] theorem also leads to a formula for reconstruction of the original signal. The constructive proof of the theorem leads to an understanding of the aliasing that can occur when a sampling system does not satisfy the conditions of the [Nyquist] theorem. http://en.wikipedia.org/wiki/Nyquist%E2 ... ng_theorem

The lossy sampling algorithm of Linux is fundamentally wrong simply because it does not satisfy the conditions of the Nyquist–Shannon sampling theorem. That is why I really want to disable any unwanted resampler.

I had an idea on how to test this but I don't think it would work now (connect output to line-in. Play a low rate output and record it, and than test if the result sounds fine in a low rate. But the recording process's ADC is a sort of SRC too, so I'm not sure how to distinguish...).

It is difficult to believe that it is an unsolvable problem. There is a particular soundcard. There are drivers which work in some way. This means that somebody knows something about the soundcard.

[hiro]

There is no sure way to test for that hardware SRC.
Some SRCs are simply too good to be possibly noticed after DA conversion. Look at these funny guys with high-end oversampling DACs for an example. The sound doesn't get any better, but also doesn't get worse

This is no excuse for Alsa's bad linear SRC, but I'd like to point out that SRC in itself is NOT evil.

And I bet you won't hear all 32bits in your analog signal, there is too much noise in most of these cards.
That's because your soundcard is not "hdaudio". Your soundcard is also what is built around this little chip. Even if hdaudio may theoretically support 32bits it's possible that you may not even hear 16 of these bits.
I'm not sure about the actual bottleneck on your card, but it may very well be in the analog stage, the clock, or the power supply.

44.1kHz->DAC->ADC->192kHz is often worse than 44.1kHz->random-SRC->192kHz.

Simply don't use the cheapest soundcard around and you'll be fine... Also no alsa

[igorzwx]

There is no sure way to test for that hardware SRC.

In this particular case, I can easily detect that there is an unknown resampler. There are special test files for this. However, it is still unclear whether it is a hardware SRC, or it is a kind of invisible PulseAudio inside OSS4. It seems that this invisible resampler does not make any significant harm, if an audio file is already converted to 48kHz. The Russian Ultimate Player (with the magic plugin) can perform such conversion "on the fly", and, therefore, I can play comfortably FLAC and APE (with CUE and without), and enjoy genuine sound.

However, if there is a kind of invisible PulseAudio inside OSS4, it should be disabled, or removed (if possible). Otherwise, it may cause troubles sooner or later. Another problem is that I got "bad clipping" with all resamplers of OSS4 (including "production quality) trying to play 192kHz → 48kHz and 96kHz → 48kHz with ICH7 (Ubuntu). This should be tested with other soundcards. The obvious workaround is to use the Russian Ultimate Player (with the magic plugin).

Simply don't use the cheapest soundcard around and you'll be fine... Also no alsa

Perhaps, you may publish a comprehensible "howto" and name those expensive soundcards with which you can get high quality playback "out of the box". Otherwise, I do not see any practical use of your advices.

I do use the cheapest soundcards with both ALSA and OSS4. The quality of playback of lossless formats seems to be perfect with both ALSA and OSS4. Perhaps, it is not ideal, but it is certainly good enough to enjoy music. To make it possible, certain magic tools were installed:
1. ALSA: Petrov's plugin (with very fast and very exact SRC).
2. OSS4: The Russian Ultimate Player with Petrov's plugin http://deadbeef.sourceforge.net/
This magic plugin allows to disable redirection to virtual mixer engines and sample rate/format conversions (similar to "ossplay -R"). This ensures that the only exact resampler is in use.