igorzwx wrote: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.

igorzwx wrote:ALSA is said to have a secret file /proc/asound/card0/pcm0p/sub0/hw_paramswhere 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 wrote: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.

igorzwx wrote:ALSA is said to have a secret file /proc/asound/card0/pcm0p/sub0/hw_paramswhere 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:

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.

cesium wrote: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 wrote: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.

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:

cesium wrote: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?

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.

cesium wrote: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?

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...).

cesium wrote: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".

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

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#Aliasinghttp://en.wikipedia.org/wiki/Nyquist%E2 ... iderationshttp://en.wikipedia.org/wiki/Nyquist%E2 ... m#AliasingThe 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.

cesium wrote: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.

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

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).

hiro wrote: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.