How to enable "production quality with extra precision"?

[igorzwx]

It seems that it works!!!

I should check it more carefully, of course.

--------------------------------------------------------
EDIT: Now I have the same options as with 4.1:

vmix0-src <Fast|Medium|High|High+|Production|OFF> (currently Production)

"PX production quality (prod quality with extra precision)" is missing.

The best option now is "production quality" (without extra precision).
Such a "production quality" seems to cost about 3% CPU on my ancient box of 2001.

Sound quality seems to be very good, but with "extra precision" it might be even better, I presume.

Many thanks!!!

[angry_vincent]

And how to recompile the package with "production quality" in Gentoo? I have only <Fast/High/OFF> in vmix-src

[igorzwx]

And how to recompile the package with "production quality" in Gentoo? I have only <Fast/High/OFF> in vmix-src

It seems that it is possible to compile something in Gentoo
http://wiki.amule.org/index.php/HowTo_Compile_In_Gentoo
http://www.google.com/search?hl=en&q=ho ... f&oq=&aqi=

Otherwise, you may try Linux From Scratch
http://www.linuxfromscratch.org/
QUOTE:
"If you've got time and are looking for a learning experience, Linux From Scratch is what you want. Yes, everything in Gentoo is compiled from scratch, but it's all handled by Portage, and you can bootstrap a Gentoo system without learning a single thing. LFS is a fantastic learning experience and much more rewarding (at least in my experience) than Gentoo."

[cesium]

And how to recompile the package with "production quality" in Gentoo? I have only <Fast/High/OFF> in vmix-src

Before running configure/make, patch the configure file like this:

Code: Select all

GRC_MIN_QUALITY=6
GRC_MAX_QUALITY=6

(You can use some sed command for this. e.g. "sed -ie "/GRC/ s/3/6/ configure"). This should enable production quality and make it default (actually, it would make it the only option besides "OFF").

[igorzwx]

And how to recompile the package with "production quality" in Gentoo? I have only <Fast/High/OFF> in vmix-src

Before running configure/make, patch the configure file like this:

Code: Select all

GRC_MIN_QUALITY=6
GRC_MAX_QUALITY=6

(You can use some sed command for this. e.g. "sed -ie "/GRC/ s/3/6/ configure"). This should enable production quality and make it default (actually, it would make it the only option besides "OFF").

The problem is that words can be deceptive.
You should not be naive, first of all.
The term "production quality" may mean "low quality" as well. To find out the true meaning of the term, we have to compare it with something else

Let us compare it with SoX. The reason is simple. SoX makes resampling in real time, on the fly, and of very high quality. What is more, "high quality" is the default option of SoX.

More exactly, SoX has several options for resampling:

-q --- quick resampling
-l --- low quality resampling
-m --- medium quality resampling
-h --- high quality resampling (Default)
-v --- very high quality resampling

"Production quality" with OSS4 seems to be equivalent to "low quality resampling" with SoX

This should be tested more carefully, of course.
You can create a test file (20Hz + 20kHz), resample it with SoX, and study the spectrum.
You can also play the test file with SoX Player (play), resampling it on the fly.

On Ubuntu with OSS4:

sudo apt-get install sox libsox-fmt-oss libsox-fmt-base libsox1

sudo apt-get purge libsox-fmt-alsa

SoX Player (real time resampling, examples):

play test.wav rate -q 48k

play test.wav rate -l 48k

play test.wav rate -m 48k

play test.wav rate -h 48k

play test.wav rate -v 48k

play test.wav rate -v -I -b 90 48k

Default (high quality):

play test.wav -r 48000

play test.wav -r 48k

play test.wav rate 48k

Supported Effects -> rate
http://sox.sourceforge.net/sox.html#lbAZ
http://sox.sourceforge.net/SoX/Resampling

Resampling with SoX (examples):

sox 10Hz+20kHz_44100.wav 10Hz+20kHz_44100_to_48000_quick.wav rate -q 48k

sox 10Hz+20kHz_44100.wav 10Hz+20kHz_44100_to_48000_low.wav rate -l 48k

sox 10Hz+20kHz_44100.wav 10Hz+20kHz_44100_to_48000_medium.wav rate -m 48k

sox 10Hz+20kHz_44100.wav 10Hz+20kHz_44100_to_48000_high.wav rate -h 48k

sox 10Hz+20kHz_44100.wav 10Hz+20kHz_44100_to_48000_very_high.wav rate -v 48k

sox 10Hz+20kHz_44100.wav 10Hz+20kHz_44100_to_48000_very_high_special.wav rate -v -I -b 90 48k

sox 10Hz+20kHz_44100.wav -b 24 10Hz+20kHz_44100_to_96000_very_high_24bit.wav rate -v -I -b 90 96k

sox 10Hz+20kHz_44100.wav -b 32 10Hz+20kHz_44100_to_96000_very_high_32bit.wav rate -v -I -b 90 96k

----------------------------------
EDIT: Presumably, "production quality with extra precision" is the maximum quality which you can get with ancient soundcards (that is, non-HDA, no high definiton audio) such as Intel ICH4, for example. Perhaps, "production quality with extra precision" with OSS4 might be a little better than "low quality resampling" with SoX.
EDIT 2: In other words, "production quality with extra precision" is likely to be an ancient algorithm of resampling (designed in 2001, or so) which was optimal for ancient soundcards and ancient processors.

[igorzwx]

It might be stating the obvious, but the absence of information and knowledge does not help to solve practical problems. There is a bug in OSS v.4.2. This bug spoils sound quality, and, therefore, it should be fixed as soon as possible.

Some soundcards may not be severely affected, but certain soundcards are in trouble (I have already tested some of them).

The problem is sample rate conversion. You want to have a kind of a virtual mixer (for practical purposes) and you have it (vmix). All the signals are to be converted to a single rate. This rate, by default, is 48kHz. A low quality algorithm of sample rate conversion would degrade the sound quality of 44100 material played through a mixed device, and produce
harmonic distortion. A large majority of users may not notice the difference, but the difference might be obvious for all, when certain special test files are played.

With OSS v.4.1 you have these options for resampling:
vmix0-src <Fast|High|High+|Production|OFF> (currently Production)

With OSS v.4.2 you have only a few options for resampling:
vmix0-src <Fast|High|OFF> (currently High)

"Fast resampling" is something really very bad.

"High quality resampling" seems to be a very rudimentary linear interpolation algorithm. It produces strong harmonic distortions.

High+ is not much better than High (they seem to be about equivalent).

Of course, I do not know precisely what that "High quality" algorithm is, but the sound of harmonic distortions is exactly the same as that of "rudimentary linear interpolation algorithm". I made various tests. In particular, another sound system was installed on the same computer and various resampling algorithms were tested.

"Production quality" algorithm does not produce very strong harmonic distortions, but it is not likely to be something very sophisticated.

Which soundcards are in trouble?

According to Dr. Google, certain soundcards resample everything to 48khz themselves : AC'97 onboard chipsets, all Creative Live and Audigy series, Hercules Fortissimo I/II/III ( not the IV ). Due to their limited power and flexibility, they perform quite crappy resampling on non-48khz material.

I tested some old AC'97 soundcards:

00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 30)
00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 01)

For such old AC'97 soundcards, the effect of bad resampling is pretty obvious.
You can play the test wave of 44100Hz directly (with vmix disabled), or through vmix (with 48kHz default).
The best quality is produced by vmix with "Production quality" algorithm.
The worst quality is produced by vmix with "Fast" algorithm.
The quality of direct playback (without vmix) is comparable to "High quality" algorithm (which is, presumably, a simple linear algorithm).

There is a reason to believe that Intel HDA ICH8 and the like may have similar problems, although the quality of sound might be better.

Generally speaking, we have two cases:
1. "Production quality" is better than the quality of resampling made by the soundcard itself (e.g. old AC'97 onboard chipsets).
2. "Production quality" is worse than the quality of resampling made by the soundcard itself (some new sophisticated soundcards).

In the first case, you may want to have at least "Production quality".
In the second case, you may want to have something better than "Production quality".

***********************************************

How to use test files?

There are many different test files, but the idea is about the same. Such files contains certain inaudible frequencies.
If there is something wrong with resampling algorithm, it produces audible artefacts (harmonic distortions).
I created a test file 10Hz + 20kHz, as described above.

PRECAUTIONS: It is advisable not to use sophisticated equipment (speakers) for testing sound.

I do not pretend to be a specialist in such matters, and I tend to use very cheap (PC) speakers for testing sound quality (no special filters, etc.). On the other hand, simple speakers may not produce marginal frequencies (and this is good, perhaps).

For those, who want to test sound quality, there are instructions in the net.
This one was found with Google (for a test file: 1kHz + 20kHz):
http://www.hydrogenaudio.org/forums/ind ... 2&hl=udial
QUOTE:
For everybody fighting with occasional clipping (or perfectionists wanting to test everything) you should try the attached sample, udial.

Testing:
play the sample in your favourite player (decoded or not, having disabled all DSPs and EQs that can interfere)
if the output sounds weird at any time you should:
1. lower the output vol. in your soundcard config (should be the speaker icon in your system tray).
2. For some soundcards 48kHz is better (audigy 2 etc.).
3. lower the vol. till the sample doesn't sound weird at any time.

The output will sound really weird if your settings clip.
Your output can occasional clip without you knowing/hearing it. But for us perfectionists this will theoretically give a better quality output.

ATTENTION: Play this sample at a low volume anytime, even if you hear nothing special! It can be very harmful to equipment and/or your ears.
It's strongly recommended to use some very cheap (PC) speakers if you want to test this,
otherwise you might really ruin your tweeters (it has happened several times already).


*****************
WARNING: Do not play arbitrary test files downloaded from the net. You may better open them with Audacity (drag-and-drop them into Audacity) and study the spectrum.


*****************
NOTE: Clipping also produces artefacts (harmonic distortions) somewhat similar to those produced by low quality resampling.

[igorzwx]

There is the so-called "Secret Rabbit Code of ALSA",
and there is a converter to it,
the purpose of which is to evaluate the quality of resampling.

It is a kind of test program. You convert (resample) a wave file and study the results.
You do not need to install ALSA, moreover, you do not need to install anything at all.
Simply extract it from the deb-package and run it as is.
I tested it on Ubuntu with OSS4 installed.

A Sample Rate Converter using libsndfile for file I/O and Secret
Rabbit Code (aka libsamplerate) for performing the conversion.
It works on any file format supported by libsndfile with any
number of channels (limited only by host memory).

Usage :
sndfile-resample -to <new sample rate> [-c <number>] <input file> <output file>

The optional -c argument allows the converter type to be chosen from
the following list :

0 : Best Sinc Interpolator
1 : Medium Sinc Interpolator (default)
2 : Fastest Sinc Interpolator
3 : ZOH Interpolator
4 : Linear Interpolator

QUESTION: Is there a similar program for testing OSS4 resampler?

-------------------------------------------------------------------------
EDIT:
Secret Rabbit Code = Sample Rate Converter = SRC

Secret Rabbit Code (aka libsamplerate)
Author : Erik de Castro Lopo
http://www.mega-nerd.com/SRC/
http://en.wikipedia.org/wiki/Libsndfile

In short: the resampler may look nice, but you do not know how it was implemented in ALSA.
The Russian guru told me that it seems to be a calculated deception.
It was a kind of Cargo Cult story indeed. He created his own resampler (a better one) and attempted to insert it in ALSA. Disillusionment was bound to follow. Such an unpleasant discovery. You see, he created an own tool to measure resampling quality, and so on, and everything looked very nice...

Actually, I am very intrigued to compare the algorithms of resampling.
I am not very interesting to dig into implementations.

I would be very grateful if somebody explain me where to get the OSS4 resampler in the form of a test program.

[cesium]

Well, the OSSv4 resampler can be embedded into a userland program (see cmd/osstest/osstest.c in OSSv4 source tree). It is possible to make a userland program to convert raw sound data and compare the result.

Also, I found this comparison, though it doesn't include ALSA and I don't think he tested OSS4 in its floating point SRC mode (which has slightly better quality than the integer fixed point one).

[igorzwx]

Cesium!

Many thanks for very interesting information!

Is it possible to include an own resampler into OSS4 as a kind of plugin?

[cesium]

Well, there's no SRC plugin API as such, so it's doable only if some programming is done. Either by replacing grc3 in vmix (the grc3 files are fortunately separated from the main vmix implementation) or by implementing a different driver to do mixing (which is more complicated, but OSSv4.0 had "softoss" which had been an older mixing module (I think it used different algorithm? Not sure), so it's doable).

I notice now that kernel/framework/audio/oss_grc3.c has a "#ifdef TESTCASE", so it can be compiled to a userland program getting raw 44100 input from stdin and sending 48000 output to stdout (this would probably require an OSS compile, followed by something like "cc -DTESTCASE -o grc3 framework/audio/oss_grc3.c -Isomething (not sure)" etc.

[igorzwx]

Many thanks!

Well, there's no SRC plugin API as such.

Why not let users to do the work?

It might be a practical solution for many problems. If, for example, a user is not satisfied by sound quality, he might be advised to make his own resampler. Absolute freedom, in other words.

[cesium]

Well, I'm not a dev, so can't answer you for them. One possible answer is that most people are/would be happy with current quality and that efforts are better used in other directions for now (e.g. USB and hdaudio drivers need improvement).

[igorzwx]

Well, I'm not a dev, so can't answer you for them. One possible answer is that most people are/would be happy with current quality and that efforts are better used in other directions for now (e.g. USB and hdaudio drivers need improvement).

Perhaps, you misunderstood me. Human beings tend to do what they want rather than what is useful. This is especially true for Russians. The guru tries to implement it in ALSA, because it has such plugin API. However, in this particular case, he has to remake the entire ALSA, perhaps. This seems to be doomed to failure. But, nevertheless...

[igorzwx]

Also, I found this comparison, though it doesn't include ALSA and I don't think he tested OSS4 in its floating point SRC mode (which has slightly better quality than the integer fixed point one).

O.K. I studied that comparison
http://people.freebsd.org/~ariff/z_comparison/

These are my comments (you may correct me, if I am mistaken):

1. First of all, this is an advertisement (that is, a kind of deception) rather than an exact description of a scientific experiment which can be reproduced.

2. Z is said to be "an evil Sample Rate Converter" for FreeBSD. It is a new converter which is said to be implemented in "the upcoming FreeBSD 8.0. "

3. FreeBSD has ALSA inside (if I am not mistaken). Thus, Z seems to be a new converter for ALSA

4. Speex and "Secret Rabbit Code" are sample rate converters implemented in ALSA.

5. Somebody made a kind of comparison of algorithms.

Since we already know that an algorithm may look very nice, but its implementation into ALSA might be awful, this "comparison" seems to be a kind of deception (that is, an advertisement). You see, 32bit with ALSA and all such things, and we are invited to believe, of course
http://people.freebsd.org/~ariff/z_comp ... FrontGRC3/

Perhaps, many users (if not the majority) complain about the current sound quality in FreeBSD. Such news may relax them.

In any case, this information is very interesting indeed.
Thank you very much once more.

[cesium]

A. FreeBSD doesn't use ALSA, but it's own sound system (the interface to it is OSSv3 API).

B. AFAICT, that comparison page was done by the main contributor to said soundsystem a while ago (That's why it doesn't mention FreeBSD 8 is out already).

C. You're right that the setup should be disclosed (for reproducability).