cesium wrote:I think you're working with a wrong deduction: SRC => distortions and therefor distortions => SRC is on. The first can be tested and may be true, but the second formulation isn't necessarily true and can't be so easily established! There are other ways to mess up and create distortions. e.g. it's possible OSS uses a too small fragment size/number when "talking" to the card. You can try reattaching vmix with '-M' option to see if a bigger size/number helps when using vmix**. Also, some cheap cards used to have distortions when volume was set too high (bad clipping inside chip).
I studied the method of "scientific deduction" with the stories of Sherlock Holmes, and from my subjective point of view, your notion of "wrong deduction", of "fragment size/number", and of "bad clipping inside chip" is beside the point.
Have you noticed that I designed a clear-cut empirical test which proves that the true cause of audible distortions is sample rate conversion (SRC)
? The clear-cut empirical test is easy to reproduce.
I created two test files with Audacity:
1. 10Hz + 20kHz (44100Hz, 16bit)
2. 10Hz + 20kHz (48000Hz, 16bit)
I play them with ossplay, and the difference is pretty obvious. Why? Because the first file is resampled by a low quality resampler. Is it obvious now?
There are, perhaps, other distortions, but they are insignificantly small in relation to the distortion produced by a low quality resampler. Indeed, when you play "10Hz + 20kHz (48000Hz, 16bit)", you hear nothing, and this proves the point.NOTE:
The so-called "bad clipping" can be produced by the algorithm of resampling itself. It seems that libsamplerate (best) can fix this problem, if it is not a real-time
Code: Select all
$ sndfile-resample -to 48000 -c 0 Risset_Bell-44100Hz_16bit.wav Risset_Bell-48000Hz_16bit-libsamplerate-best.wav
Input File : Risset_Bell-44100Hz_16bit.wav
Sample Rate : 44100
Input Frames : 441000
SRC Ratio : 1.088435
Converter : Best Sinc Interpolator
Output file : Risset_Bell-48000Hz_16bit-libsamplerate-best.wav
Sample Rate : 48000
Output has clipped. Restarting conversion to prevent clipping.
Output Frames : 480000
What do you think about this "smoking gun"?
Risset Bell was created with Audacity (default settings). It is easy to reproduce.http://audacity.sourceforge.net/download/nyquistplugins
Can "Production quality" produce a kind of "bad clipping"? You may also try "Fast" resampler with Risset Bell.
Do not forget to create two Risset Bells, one for 44100Hz, another for 48000Hz. Otherwise, one may come to believe that it is "bad clipping" inside speakers, or soundcard, or else.
Is "bad clipping inside chip" a kind of deception, a sort of mythology?
If, for example, ALSA has an invisible resampler, which cannot be disabled, the users may hear a kind of "bad clipping" with any test files, and it may lead them to the idea about "bad clipping inside chip", although such clipping might also be produced by the invisible resampler of ALSA. The result might be a myth of "bad clipping inside chip" which explains "why sound quality is so bad".
As it was already clearly stated, the problem of sound quality in Linux is simply a problem of conversion from one audio format to another.
Broken drivers can be fixed. But the problem of sound quality will never be solved, if the nature of sound is misunderstood. In applied sciences, the problem of sample rate conversion was solved one hundreds years ago, and the proper algorithms were already created, but this problem continues to persist in Linux, and there is a little hope that it will be solved in the near future.
cesium wrote:most new cards lost HW mixing capability.
The card is likely to have HW SRC
cesium wrote:since the card likely has no HW SRC, you need a software one.
. This may explain the results of this test:
Code: Select all
$ ossmix | grep vmix0-enable
vmix0-enable ON|OFF (currently ON)
$ ossmix | grep vmix0-src
vmix0-src <Fast|High|High+|Production|OFF> (currently Production)
$ ossmix vmix0-src OFF
Value of mixer control vmix0-src set to OFF
$ ossmix | grep vmix0-src
vmix0-src <Fast|High|High+|Production|OFF> (currently OFF)
$ ossplay 10Hz+20kHz_44100Hz_16bit.wav
Warning: Playback using 48000 Hz (file 44100 Hz)
This means that the test file seems to be resampled, despite the fact that all resamplers are disabled. Is it a deception? Is there a kind of "invisible resampler" which always resamples everything (as it may happen with ALSA)? Or it is simply that mysterious HW SRC, that is, a hardware resampler of the soundcard? But the very existence of HW SRC would contradict your market theory of soundcards. If I understood you correctly, HW SRC should not exist, simply because HW soundcard does not exist as such, it is merely a software emulation.
I made some further empirical research, and this produced more questions than answers. Perhaps, there was something wrong in the methodology of the research.
It seems that now I can disable vmix, and "ossplay -R" works as it should. But there is a reason to suspect that it is just another deception.
cesium wrote:** When vmix isn't attached or '-R' is used, than the number/size is controlled by the program (SNDCTL_DSP_SETFRAGMENT), or OSS uses some default values. Later, I'll send a source to test that...
If you have a magic tool to test that, I would be very happy to try.
Actually, this is the most important thing to test.