Open Sound System

A very strange problem with ICH6 (Arch + OSS4): I can change resampler, but I cannot disable resampling and get direct playback to audio device.



I can set "vmix0-enable" to "OFF" in the mixer GUI, or with command:


Everything looks O.K., but it is merely a deception! The same resampler continues to distort sound.
Direct playback seems to be impossible.

TEST:
1. enable "vmix0", set "Fast" resampler
2. run test (10Hz + 20kHz), and you hear noise
3. disable "vmix0"
4. run test (10Hz + 20kHz), and you hear the same noise
5. enable "vmix0", set "Production quality" resampler
6. run test (10Hz + 20kHz) - now you get "silence"
7. disable "vmix0"
8. run test (10Hz + 20kHz) - and you get the same "silence"

This simply means that the resampler is working!

Another test:


Has anybody tried to disable resampling with Intel HDA soundcards? Or it is impossible?

Hmm.. Try adding "vmix_disabled=1" to /usr/lib/oss/conf/osscore.conf and restart OSS. Does it work better? Also, turning off vmix won't work if there's a client already attached to the device - it won't stop until all clients are disconnected - so if anything was using the device, it was still on.

cesium wrote:Hmm.. Try adding "vmix_disabled=1" to /usr/lib/oss/conf/osscore.conf and restart OSS. Does it work better? Also, turning off vmix won't work if there's a client already attached to the device - it won't stop until all clients are disconnected - so if anything was using the device, it was still on.

I killed all "clients", mixers, everything, but it did not help.

It works, however, with ICH4, even if many "clients" are active.

Perhaps, disabling of vmix may help, in a sense. But then I should always reload OSS, or reboot the system, if I want to start another audio application. Right? Or I should install ESound to fix the problem caused by the disabling of vmix?

You can also try setting vmix0-src to OFF - this disables just the resampler. Multiple programs will be able to play, but they'll all have to use the same rate.

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.

Lastly, I dunno about the test - AFAICT, the resampler doesn't run if programs use the soundcard's native rate. Otherwise, it depends on vmix0-enable and vmix0-src values. What does 'ossinfo -A -v2' show for supported rates? You can also try setting "vmix_no_autoattach=1" and testing with "vmixctl attach" (with or without '-M' switch).

cesium wrote:You can also try setting vmix0-src to OFF - this disables just the resampler. Multiple programs will be able to play, but they'll all have to use the same rate.

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.

Lastly, I dunno about the test - AFAICT, the resampler doesn't run if programs use the soundcard's native rate. Otherwise, it depends on vmix0-enable and vmix0-src values. What does 'ossinfo -A -v2' show for supported rates? You can also try setting "vmix_no_autoattach=1" and testing with "vmixctl attach" (with or without '-M' switch).

Hi Cesium!

Many thanks for new ideas. I did overlook some obvious options, although, of course, they are not likely to serve the purpose.

The problem is that I need something more than simply disabling of resampling. I need, as it was clearly stated, not simply disabling of resampling, but also "direct playback to audio device". Do you think it is possible?

As you know, the option "-R" of ossplay means: "Disable redirection to virtual mixer engines and sample rate/format conversions. " If sound is redirected to a virtual mixer engine, this inevitably produces distortions, such as overtones of 50Hz.

The installation of PulseAudio does not seem to be a sensible solution, for it will produce a new problem of how to disable it. As I learned from my own experience, the only way to disable PulseAudio is to remove it.

The facts:
1. The option "-R" of ossplay does not work for this particular card.
2. The ossmix is deceptive, and you should not believe it, for it is a kind of "Potemkin village"
http://en.wikipedia.org/wiki/Potemkin_village

"/usr/lib/oss/conf/osscore.conf" might be just another "Potemkin village", and is it very probable that the driver is so designed that it is impossible to disable both resampling and redirection to virtual mixer engines.

The card is likely to have HW SRC, and it might be difficult to believe that Intel HDA soundcards are so backward that they do not support the simplest functions available for ancient soundcards. On the other hand, it is very probable that Linux drivers (OSS and ALSA) do not support HW SRC and sample rates 96kHz and 192kHz for Intel HDA soundcards. Sergey Petrov had already studied the source code of ALSA, and his "scientific findings" were not very optimistic.


However, Arch Linux Wiki states:
http://wiki.archlinux.org/index.php/OSS ... ample_Rate

96000hz - Sample rate of most high definition audio downloads. If your motherboard is an AC'97 motherboard, this is likely to be your highest bitrate.
192000hz - Sample rate of BluRay, and some (very few) high definition downloads... An example of a motherboard chipset that would support this includes Intel HDA audio.

If the driver does not support HW SRC, it might be reasonable to prevent disabling of both resampling and redirection to virtual mixer engines. Otherwise, ignorant users may get troubles, as you noticed.

It is now going to be a kind of "scientific research". It now requires a careful planning, otherwise, it is doomed to failure.

To plan a "scientific research", we need to formulate the hypotheses which we are going to verify.

The first thing to try might be "ossmix vmix0-src OFF". It is likely to be deceptive, but this can be tested with "10Hz + 20kHz".

What might be interesting, is to set sample rate in the mixer to 44100Hz and play something of CD format.



However, "vmix0-rate" might be also deceptive. Therefore, a special test should be designed.

Should we believe "ossinfo"? Does it state that the OSS driver for Intel HDA allows to play CD format directly to an audio device without further HW resampling? Or it states something else?

Then I may try to disable "vmix", as you suggest, in "/usr/lib/oss/conf/osscore.conf", or in some other way. But it is very probable that it may not work for this particular soundcard.

The question is: "Is there a kind of comprehensible documentation for the driver?"
Otherwise, if it is available, it might be stupid to make such a "scientific research".

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). Do you always use the same testfile? If so, can you PM me a (link to a) copy?

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

Secondly, it's not surprising most new cards lost HW mixing capability. The trick is to understand these days the client which buys the soundcard is (nearly always) not the enduser, but rather is the motherboard manufacturer. The latter want the cheapest chips/cards possible, and losing this ability "helps". In any event, OSs and drivers have learned to adapt to sw mixing, and this is adequate for most people. Compare how hw modems have disappeared and replaced by software winmodems.

Thirdly, you can try "man osscore" and "man oss_hdaudio" for a bit of extra documentation. http://manuals.opensound.com/ has a bit more. That said, can you believe it? Ultimately, the best doc is the source code itself...

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). Do you always use the same testfile? If so, can you PM me a (link to a) copy?

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

Secondly, it's not surprising most new cards lost HW mixing capability. The trick is to understand these days the client which buys the soundcard is (nearly always) not the enduser, but rather is the motherboard manufacturer. The latter want the cheapest chips/cards possible, and losing this ability "helps". In any event, OSs and drivers have learned to adapt to sw mixing, and this is adequate for most people. Compare how hw modems have disappeared and replaced by software winmodems.

Thirdly, you can try "man osscore" and "man oss_hdaudio" for a bit of extra documentation. http://manuals.opensound.com/ has a bit more. That said, can you believe it? Ultimately, the best doc is the source code itself...

You are absolutely right! All possible sources of distortions should be classified and investigated carefully.

The test file is the same as before, but it should be used with precautions.

WARNING: Such test files should only be played at a low volume level, even if you hear nothing special! It can be very harmful to equipment and/or your ears. It's strongly recommended to use very cheap (PC) speakers, otherwise you might really ruin your tweeters.

TEST FILE No. 1

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

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.


TEST FILE No. 2

Step 1: Open Audacity and set "Project Rate (Hz)" to 48000 (and 16bit)

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

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

type the command:

(mult (sum (hzosc 17000) (hzosc 19000)) 0.45)

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

This produces a simple mix of 17kHz and 19kHz (sine waves)

Export the result as wave.

----------------------------------
If I understood you correctly, you claim that Intel HDA is simply a cheap piece of metal, which comes together with a kind of codec, the purpose of which is to imitate a soundcard. It means that if you get a direct access to that cheap piece of metal, it would not play music, for it is not a soundcard. If your theory is true, any attempt to disable "vmix" is doomed to failure, because "vmix" is your soundcard. In this case, ossmix should be a kind of imitation, a sort of Potemkin village, and other configs too.

If "Intel HDA audio" is not a real soundcard, but simply a kind of "software emulation", we should, perhaps, design our "scientific research" in another way. We have to find an optimal solution, which is a minimum (or maximum) of a certain function, a kind of "utility function". We have to maximize "profit" and minimize "losses".

In other words, to improve sound quality, we have to minimize "sound processing" performed by the "software emulation" of a soundcard. If, for example, the minimum "sound processing" is achieved at 48kHz and 32bit, this format should be used.

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



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.

cesium wrote:since the card likely has no HW SRC, you need a software one.

The card is likely to have HW SRC. This may explain the results of this test:



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.

What happens if you change vmix rate? e.g. "sudo vmixctl rate /dev/dsp 44100"? Does the result of the test flip, or something else happens?

cesium wrote:What happens if you change vmix rate? e.g. "sudo vmixctl rate /dev/dsp 44100"? Does the result of the test flip, or something else happens?

I do not have this notebook here. I tested that in different ways with test files. It is very probable that the card has internal HW resampler and 44100Hz are always resampled to 48000Hz.

Edit: What makes me suspicious is different behaviour of certain programs on two computers with the same software installed.
knotify4 does not do any harm on the old box with old VIA card, but on Dell notebook with ICH6 it prevents the disabling of vmix.
Petrov's player works perfectly on the old box, but it cannot get the direct access to audio device of ICH6.
It seems that ossplay -R can now get the direct access to something, but what that "something" is remains unclear.

cesium wrote:What happens if you change vmix rate? e.g. "sudo vmixctl rate /dev/dsp 44100"? Does the result of the test flip, or something else happens?

I changed sample rate as you told: sudo vmixctl rate /dev/dsp 44100
played various files, music and test files.
Sound quality seems to be comparable to that of "Production quality".

It does not seem to be a kind of direct playback without resampling.
It seems that sound is somehow resampled to 48kHz.

If you have other ideas, I can try them now.

I mean, what happens if you do that test? If the result stays the same, than it might be the card which resamples to 48K somewhere.. If not, maybe vmix's SRC wasn't turned off or something.

cesium wrote:I mean, what happens if you do that test? If the result stays the same, than it might be the card which resamples to 48K somewhere.. If not, maybe vmix's SRC wasn't turned off or something.

Cesium!

I have test files (44100Hz and 48kHz).
I know exactly how they sound with each particular resampler.
I have already tried all possible configurations.

When the sample rate is set to 44100Hz (as you told), the internal HW recampler of the soundcard (which does not exist) converts audio file (of 44100Hz) to 48kHz.

Is there a kind of "invisible resampler" inside ossplay?

It may explain everything...
http://opensound.hg.sourceforge.net/hgw ... y_decode.c

ret = setup_device (dsp, format, channels, speed);
if (ret == E_FORMAT_UNSUPPORTED)
{
int i, tmp;

for (i = 0; format_a[i].name != NULL; i++)
if (format_a[i].fmt == format)
{
tmp = format_a[i].may_conv;
if ((tmp == 0) || (tmp == format)) continue;
print_msg (WARNM, "Converting to format %s\n",
sample_format_name (tmp));
ret = setup_device (dsp, tmp, channels, speed);
decoders = setup_normalize (&format, &obsize, decoders);
goto dcont;
}
goto exit;
}


********************************************
man ossplay

It isn't an SRC - it doesn't convert sample rate. It has some simple format conversions - it can convert some A-Law or mu-law or some ADPCMs etc. stuff to normal 16bit PCM.