How to enable "production quality with extra precision"?

[igorzwx]

There is a parameter "src_quality=3" in this config-file: /usr/lib/oss/conf/osscore.conf

# The src_quality setting defines the precision of the software based sample
# rate conversion algorithm used by OSS. This setting doesn't affect possible
# hardware level conversions done by the devices themselves. Using higher
# quality setting gives better quality while lower settings consume less
# CPU time.
#
# Possible values are:
# 0 - D lowest quality (normally equals to 1=low quality)
# 1 - L low quality (spline interpolation)
# 2 - M medium quality (lagrange interpolation)
# 3 - H high quality (DEFAULT)
# 4 - HX high quality (high quality with extra precision)
# 5 - P production quality
# 6 - PX production quality (prod quality with extra precision)
#
#src_quality=3

You can uncomment "src_quality=3" and select a better quality (and reboot), but nothing will change.

With old version of OSS4 (oss-linux-4.1-1052_i386.deb), I had a choice in the mixer:

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

You could hear the difference, and, if you do not believe your ears, you could prove it with mathematical exactitude through the help of test files. And there was not any significant CPU load!

Now, with new version of OSS4 (oss-linux-4.2-2001_i386.deb), I have choice between "more distortions" and "less distortions":

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

You can try this:

$ ossmix vmix0-src 0000
Value of mixer control vmix0-src set to Fast
$ ossmix vmix0-src 0001
Value of mixer control vmix0-src set to Low
$ ossmix vmix0-src 0002
Value of mixer control vmix0-src set to Medium
$ ossmix vmix0-src 0003
Value of mixer control vmix0-src set to High
$ ossmix vmix0-src 0004
Value of mixer control vmix0-src set to High+
$ ossmix vmix0-src 0005
Value of mixer control vmix0-src set to Production
$ ossmix vmix0-src 0006
Value of mixer control vmix0-src set to OFF

Or this:

$ ossmix vmix0-src 0
Value of mixer control vmix0-src set to Fast
$ ossmix vmix0-src 1
Value of mixer control vmix0-src set to Low
$ ossmix vmix0-src 2
Value of mixer control vmix0-src set to Medium
$ ossmix vmix0-src 3
Value of mixer control vmix0-src set to High
$ ossmix vmix0-src 4
Value of mixer control vmix0-src set to High+
$ ossmix vmix0-src 5
Value of mixer control vmix0-src set to Production
$ ossmix vmix0-src 6
Value of mixer control vmix0-src set to OFF

But this does not help, because now 0=4=5
You can see it with ossmix or ossxmix, and you can hear distortions.

The question is: Is it possible to get good quality sound with OSS4?
Or those precise "sample rate conversion algorithms" were removed from OSS4?

[plmegalo]

Have you tried with 96000 sample rate output ?

Just to say, I look for an explanation or documentation about this, but noone seems to notice or give any answer about the vanish of these options ... strange !
If anyone can tell here, it should be great.
What was a solution for me : got the sources of 4.1, compile them and roll !
I will do nothing but tell you to do exactly the same thing.
If you got a Intel Hd Audio card, I can even send you a special version with only these drivers. And if you're on a Debian 64Bit even the .deb.

Regards

[igorzwx]

Hi plmegalo!

Many thanks for your reply.

First of all, "6 - PX production quality (prod quality with extra precision)" was not enabled in 4.1, as I remember.

I made test recording with 48000 sample rate on pre-historical soundcards
viewtopic.php?f=3&t=3375&start=45#p13978
The Russian friends made test recordings with 96000 sample rate, and I studied the results.

The quality of recordings is about the same. The only difference is that with ancient soundcards you get overtones (odd and even) of 33Hz, while with modern ones you get overtones (odd and even) of 93Hz.
Such things:

93
188 /93 = 2.021505376
281 /93 = 3.021505376
375 /93 = 4.032258065
469 /93 = 5.043010753
563 /93 = 6.053763441
656 /93 = 7.053763441
750 /93 = 8.064516129
844 /93 = 9.075268817
938 /93 = 10.086021505
1031 /93 = 11.086021505

Downgrading of OSS4 might not be an ideal solution for Intel HDA.
For example, microphone may not work with this card:

00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01)

Let us hope that Cesium will reveal this esoteric secret sooner or later.

Best regards,
Igor

--------------------------
EDIT: The Russians have already simulated resampling with MATLAB. They told me that what is now used in OSS4 is a kind of imitation of resampling. A low quality filter for high frequencies, that is why you get overtones.

http://en.wikipedia.org/wiki/Nyquist%E2 ... ng_theorem
The Nyquist–Shannon sampling theorem is a fundamental result in the field of information theory, in particular telecommunications and signal processing. Sampling is the process of converting a signal (for example, a function of continuous time or space) into a numeric sequence (a function of discrete time or space). Shannon's version of the theorem states:[1]

[plmegalo]

Well, you (and russians) are the men !
Great professional tests... I'm not kidding.
And perfectly right for the microphone and 4.1 for certain soundcards. Selfishly, I got no problem with this because I prefer to use external material treatment for microphone and connect it to Line in which always gives a better result than direct microphone plug on the (any?) soundcard.
My purpose was also to testify you were right on this strange vanish of "production" option but I've missed your purpose about PX. The production option is good enough for what i do with it... and seems to be better anyway than just high one in 4.2 if I refer also to your tests.
Hope we'll have some answers here and hope also that they won't be related to license or commercial problems or so...

[Temüjin]

IIRC, someone (Hannu?) said that most of the vmix-src options did not make a difference and he cut them down to Fast, High, Off. Maybe that was on the OSS development list or it's documented in a Mercurial commit. I can't remember at the moment..

[igorzwx]

Well, you (and russians) are the men !
Great professional tests... I'm not kidding.
And perfectly right for the microphone and 4.1 for certain soundcards. Selfishly, I got no problem with this because I prefer to use external material treatment for microphone and connect it to Line in which always gives a better result than direct microphone plug on the (any?) soundcard.
My purpose was also to testify you were right on this strange vanish of "production" option but I've missed your purpose about PX. The production option is good enough for what i do with it... and seems to be better anyway than just high one in 4.2 if I refer also to your tests.
Hope we'll have some answers here and hope also that they won't be related to license or commercial problems or so...

To make things clear, I am quite happy with OSS4, and many Russians too.
Nobody made yet any professional tests.
Some tests were made on the level of common sense, and some mathematical simulations were improvised by a specialist on applied math.
He gave us a lecture on MATLAB, resampling and the so-called "Kotelnikov-Nyquist algorithm".

The problem is that the Russian Ubuntu Linux community is very different from English-speaking Linux communities. The problem has anthropological nature rather than technical one. An average Russian user graduated a University or a technical high school. Some of them seem to be professors of applied math (or something like this). They know that there is an exact algorithm of resampling. It was invented many years ago, in 1920, or so. In Russia, it is called "Kotelnikov algorithm", in the US, it is named "Nyquist algorithm". It is not likely that this algorithm has already been privatized and licensed. This algorithm, of course, can be implemented in OSS4 without any significant technical difficulties. Why not?

[igorzwx]

IIRC, someone (Hannu?) said that most of the vmix-src options did not make a difference and he cut them down to Fast, High, Off. Maybe that was on the OSS development list or it's documented in a Mercurial commit. I can't remember at the moment..

They do make a difference, but, as the Russian expert told me, 90% of population can hardly notice it.
This is the exact quotation (you can translate it with Google):

Никакой особой формулы нет, есть некое подобие алгоритма:
1. разлогаем сигнал в ряд Фурье, получаем спектр
2. отрезаем от спектра высокие частоты
3. складываем ряд, но уже меньшей длины
То что получается можно с натяжкой назвать результатом даунсэмплинга.

Нужно понимать, что данный подход математически не верен, т.к.
единственно правильным алгоритмом является алгоритм
Котельникова-Шенона-Найквиста.
Однако этот способ значительно быстрее канонического, а главное, что
90% населения на слух их не отличит.

-------------------------------------------------------
EDIT:
http://en.wikipedia.org/wiki/Sample_rate_conversion
Sample rate conversion is the process of converting a (usually digital) signal from one sampling rate to another.

Two basic approaches are:
1. Convert to analog, then re-sample at the new rate.
2. Digital signal processing – compute the values of the new samples from the old samples.

Modern systems almost all use the latter since this method introduces less noise and distortion. Though the calculations needed can be quite complex, they are entirely practical given today’s modern processing power.

[igorzwx]

It is not difficult to simulate resampling and the artefacts produced by resampling with Audacity.

Audacity has two methods of resampling: "bad" and "very bad".
Both are actually very bad in relation to certain popular "open source" applications.
Both Audacity's resampling methods produce artefacts.

(resample sound srate)
EXAMPLE: (resample s 48000)
Similar to force-srate, except high-quality interpolation is used to prefilter and reconstruct the signal at the new sample rate. Also, the result is scaled by 0.95 to reduce problems with clipping.

(force-srate srate sound)
EXAMPLE: (force-srate 48000 s)
Returns a sound which is up- or down-sampled to srate. Interpolation is linear, and no prefiltering is applied in the down-sample case, so aliasing may occur.

The worst one, "force-srate", seems to be the most suitable for our experiments.

First, we have to create a test file.

Step 1: Open Audacity and set "Project Rate (Hz)" to 44100

Step 2: Audacity Menu -> Generate -> Silence (5 seconds are enough)

Step 3: Audacity Menu -> Effects -> Nyquist prompt

type the command:

(mult (sum (hzosc 10) (hzosc 19500)) 0.45)

or copy-and-paste it to Nyquist prompt (paste with Ctrl+V).

This produces a simple mix of 10Hz and 19500Hz (sine waves)

Export the result as wave.

-------------------------------------------------------------------------
Now, we can resample it.

Step 4: Mark the entire wave: Ctrl+A

Step 5: Audacity Menu -> Effects -> Nyquist prompt

type the command:

(force-srate 48000 s)

or copy-and-paste it to Nyquist prompt (paste with Ctrl+V).

Execute the command and the wave will be resampled.
You may play it and enjoy the sound of artefacts.

Export the result as wave.

-------------------------------------------------------------------------
Now, we can study the spectrum.

Step 6: Mark the entire wave: Ctrl+A

Step 7: Audacity Menu -> Analyze -> Plot Spectrum

Step 8: Change the "resolution" as follows:

Size: 16384
Axis: Log frequency

Now, you can count overtones.

The result of measurement: odd and even overtones of 276 Hz

276
827 /276 = 2.996376812 = 3
1102 /276 = 3.992753623 = 4
1379 /276 = 4.996376812 = 5
1654 /276 = 5.992753623 = 6
1929 /276 = 6.989130435 = 7
2205 /276 = 7.989130435 = 8
2481 /276 = 8.989130435 = 9
2766 /276 = 10.02173913 = 10

[cesium]

You can enable these again by rebuilding OSS with the following modification:
Edit configure, and change the value of "GRC_MAX_QUALITY". 7 is the maximum value. Then rebuild OSS as usual.

[igorzwx]

You can enable these again by rebuilding OSS with the following modification:
Edit configure, and change the value of "GRC_MAX_QUALITY". 7 is the maximum value. Then rebuild OSS as usual.

Thank you very much!!!

I will try it as soon as I can.

In a word, the story of resampling is becoming more and more intriguing.
There is an interesting paper about resampling and soundcards (Soundblasters).
http://axion.physics.ubc.ca/soundcard/resample.html

You should certainly try resampling with SoX. It does not produce any artefacts, at least with the test file and 44100-to-48000 resampling.

Install SoX and the things you may need:

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

Try these commands:

sox 10Hz+20kHz_44100.wav -r 48000 10Hz+20kHz_44100_to_48000_rate.wav rate

sox 10Hz+20kHz_44100.wav -r 48000 10Hz+20kHz_44100_to_48000_resample.wav resample

sox 10Hz+20kHz_44100.wav -r 48000 10Hz+20kHz_44100_to_48000_polyphase.wav polyphase

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

You may get such messages:

sox sox: effect `resample' is deprecated; see sox(1) for an alternative
sox sox: effect `polyphase' is deprecated; see sox(1) for an alternative

All these messages can be safely ignored. Their purpose is to trick you into reading the manual.

It might be interesting to make tests with 24bit waves

sox input.wav -b 24 output.aiff rate -v -I -b 90 48k

It is said to be "very high quality resampling; overrides: intermediate phase, band-width 90%; to 48k sample rate; store output to 24-bit AIFF file"

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

[igorzwx]

You can enable these again by rebuilding OSS with the following modification:
Edit configure, and change the value of "GRC_MAX_QUALITY". 7 is the maximum value. Then rebuild OSS as usual.

I re-compiled OSS4 from Mercurial with option "GRC_MAX_QUALITY=7" as you advised.

NOTHING CHANGED

I tried to change settings in /usr/lib/oss/conf/osscore.conf and so on.
The same behaviour as before and sound quality is the same.

In short, the result is failure.

[cesium]

Apparently there's a bug in the build system... Anyhow, after running configure script, edit kernel/framework/include/local_config.h and change CONFIG_OSS_GRC_MAX_QUALITY define to 7 (i.e. "#define CONFIG_OSS_GRC_MAX_QUALITY 7").

[igorzwx]

Apparently there's a bug in the build system... Anyhow, after running configure script, edit kernel/framework/include/local_config.h and change CONFIG_OSS_GRC_MAX_QUALITY define to 7 (i.e. "#define CONFIG_OSS_GRC_MAX_QUALITY 7").

Cesium! Many thanks! I will try it now.

#define CONFIG_OSS_GRC_MAX_QUALITY 3"

It looks like everything is commented out there with "#".
Or the sign "#" has another meaning?

[cesium]

It's a C include file. The "#" represents a preprocessor directive. I think setting it to 7 instead of 3 will work.

[igorzwx]

Thanks!