Why OSS sound quality is superior vs ALSA

[igorzwx]

igorzwx also wrote:
> Have you tried to remove PulseAudio?
Sure, it affects the latency, but it does not affect the signal.

Are you going to say that PulseAudio does not affect sound quality?

you have completely misunderstood everything.

Yes, your answers to my questions can be misunderstood, because you seem to avoid answering them.

To prevent misunderstanding, could you please reduce your answers to "yes" or "no"?

The questions are:

1. Do you hear that noise in the audio track of your video? (YES or NO)

2. Do you hear the difference between ALSA and OSS4? (YES or NO)

3. Do you hear the difference between HiRes audio and CD format? (YES or NO)

4. Do you hear the effect of PulseAudio on sound quality? (YES or NO)

5. Have you already tried the "Test for Deafness"? (YES or NO)
_http://ossnext.trueinstruments.com/forum/viewtopic.php?f=3&t=5831

These questions are so simple that it should not be difficult to provide simple answers, such as "yes" or "no".
If you cannot reduce your answers to "yes" or "no", it might be a symptom of "mental disorder".

EXAMPLE: Willy Brandt's "yes-no" interview (1972) _https://en.wikipedia.org/wiki/Willy_Brandt

willy brandt interview "ja-nein" 1972
_https://www.youtube.com/watch?v=Mdh_CrRjivU
Willy Brandt berühmte JA & NEIN Interview
_https://www.youtube.com/watch?v=cMgJFG90w7w

[sm5bsz]

1. Do you hear that noise in the audio track of your video? (YES or NO)

YES.

You expose your total lack of understanding - or maybe the total disrespect of other people. My video is recorded with a Canon S110 camera. That includes the sound. The recording was made in a noisy environment which should be obvious to anyone looking at the video. Before uploading to Youtube I have used Avidemux to pack both the video and the audio. The audio to mediocre quality, nothing more is needed.

You show disrespect for others. I have already told you the vido plays a low quality mp3 file from a camera used in a noisy environment. Did you not observe that??

2. Do you hear the difference between ALSA and OSS4? (YES or NO)

I DO NOT LISTEN.

I use high quality instrumentation. Your question is inadequate because the differences you and others can hear are caused by the applications you run with OSS and ALSA. I am using software that runs both ALSA and OSS in EXCLUSIVE MODE. When doing so I see no difference between ALSA and OSS for soundcards like Delta 44 which is correctly supported. The SB-LIVE-USB is another thing. I can not make it work at all with OSS and under ALSA it can only give 16 bit. When I performed the tests in year 2011 there were no proper drive routines for Linux for the SB-LIVE-EXTERNAL_USB. I understand you were too lazy to look here http://www.sm5bsz.com/linuxdsp/hware/sb-live-usb/sb-live-external.htm
Soundcards may have bad drive routines and the SB-LIVE-USB is an example.

3. Do you hear the difference between HiRes audio and CD format? (YES or NO)

I DO NOT LISTEN - but the difference is enormous. You can see for yourself at the above link. The CD format is generally useless because of the limited bandwidth. The dynamic range is also poor due to inadequate number of bits. You can see all of this VERY clearly here http://www.sm5bsz.com/linuxdsp/hware/sb-live-usb/sb-live-external.htm

4. Do you hear the effect of PulseAudio on sound quality? (YES or NO)

I avoid PulseAudio since I can not tolerate the delay. I do not know whether it affects performance.

5. Have you already tried the "Test for Deafness"? (YES or NO)
_http://ossnext.trueinstruments.com/forum/viewtopic.php?f=3&t=5831

NO

These questions are so simple that it should not be difficult to provide simple answers, such as "yes" or "no".
If you cannot reduce your answers to "yes" or "no", it might be a symptom of "mental disorder".

Dear igorzwx, We are on a public forum and should show other readers some respect. I take the freedom to write some more than YES or NO because the topic, "what is the difference in performance between ALSA and OSS" is relevant to many users. Your postings implicate that there is no EXCLUSIVE mode in ALSA and that is incorrect. I hope this is now clear to all other readers of this thread. When you can hear a difference it is because the application program you use is written to allow resamplers and/or format converters.

Question 5 is an insult. It is a posting you made. I DO NOT LISTEN. I use proper test instruments. I have discussed the input side on this thread, but the situation is the same on the output side. In your "Test for Deafness" you write:

WARNING: You may not hear any difference between HiRes and CD format with ALSA, simply because ALSA resamples everything with a low quality resampler. Since ALSA does not provide any sort of "exclusive mode", it should not be used for hearing tests.

You are spreading lies!! Why are you doing that? I have written in previous posting about the exclusive mode in ALSA.

You also write

You may not need to purchase a professinal soundcard, such as LynxTWO _http://manuals.opensound.com/usersguide/lynxtwo.html

Just a note: The LynxTWO is useless in a SDR context because of the very high phase noise on the sampling clock. It is easy to modify the LynxTWO for much lower noise http://www.sm5bsz.com/linuxdsp/rxiq/rx2500lynx.htm because the noise from the input amplifier dominates, but fixing the sampling clock without access to the schematic diagram is not worth the trouble.

Finally: Your questions are of the form "Have you stopped beating your wife? You must answer YES or NO" They are inappropriate because they have presuppositions https://en.wikipedia.org/wiki/Presupposition that are not mutually agreed. The answer can not be a simple YES or NO.

[igorzwx]

This topic was started by "ossuserr", because he does hear the difference between ALSA and OSS4, and he wants to know the true secret of OSS4.

It seems that a large majority of OSS4 users are using OSS4 exactly because they hear the difference.
Otherwise, they might be perfectly happy with ALSA.
They do not use PulseAudio for the same reason.

the topic, "what is the difference in performance between ALSA and OSS" is relevant to many users... When you can hear a difference it is because the application program you use is written to allow resamplers and/or format converters.

Petrov's ALSA plugin does allow to disable resamplers and format converters. It depends how you configure it.
"ossuserr" did try Petrov's ALSA plugin. It does improve sound quality, but OSS4 sounds better.

The problem is not only "sample rate/format conversions". It seems that ALSA provides a sort of buggy software layer between "the pure sound stream" and "the hardware", a kind of "software mixer", or "virtual mixer engines" which cannot be disabled.

OSS4 does allow to disable both "software mixer" (VMIX) and sample rate/format conversions.

Code: Select all

$ man ossplay
       -R     Disable  redirection  to  virtual  mixer  engines   and   sample
              rate/format  conversions.

VMIX should be disabled, because it may cause "unwanted sound distortions":

Code: Select all

$ man vmixctl
       By default most OSS drivers will attach virtual mixer  to  the  primary
       audio  device  of  the  sound card (or motherboard audio chip) when the
       device is attached.  However possible secondary audio devices (engines)
       will  not  have  vmix  attached  by default. In additional professional
       audio devices will be attached without vmix because  mixing  may  cause
       some unwanted distortion to the signal.

Both VMIX (virtual mixer) and "sample rate/format conversions" (COOKEDMODE) can also be disabled in /usr/lib/oss/conf/osscore.conf
However, "if this option [cooked_enable] is set to 0 then the format conversions will be disabled for all applications and devices unless the application explicitly enables them". /usr/lib/oss/conf/osscore.conf
That why you may better use ossplay, audacious, Petrov's pcm_play, or Petrov's DeadBeef plugin, which can explicitly disable both VMIX and COOKEDMODE.

In short: when "exclusive mode" is enabled, both "software mixer" (VMIX) and "sample rate/format conversions" (COOKEDMODE) are disabled.

If you do not hear the difference between ALSA and OSS4, you may believe that ALSA permits "exclusive mode".

If you want to discuss your "Linrad", or your "very advanced scientific experiments", you may better try other forums, such as "General Discussion"
_http://ossnext.trueinstruments.com/forum/viewforum.php?f=16

[sm5bsz]

It seems that a large majority of OSS4 users are using OSS4 exactly because they hear the difference.
Otherwise, they might be perfectly happy with ALSA.

This is clear. What I wanted to say is simply that the reason is to find in the applications and not in ALSA or OSS. As we all know, OSS is the original sound system for Linux. Quality applications using OSS were available long before ALSA appeared on the scene. Why would anyone take the trouble to port an application from OSS to ALSA? Obviously to get a larger user base - but that is not really a strong argument.

The problem is not only "sample rate/format conversions". It seems that ALSA provides a sort of buggy software layer between "the pure sound stream" and "the hardware", a kind of "software mixer", or "virtual mixer engines" which cannot be disabled.

Maybe the applications you refer to allow ALSA to insert some sort of buggy software layer that can not be disabled within the application you use. That is a problem with the application and not with ALSA itself. Personally I find OSS more logical and easy to use, but performance with ALSA and OSS is identical when no extra software layer is inserted between "the pure sound stream" and "the hardware".

If you do not hear the difference between ALSA and OSS4, you may believe that ALSA permits "exclusive mode".

I am sure you are right in that there is an audible difference between ALSA and OSS4 when one uses the software you mention. I do not distrust observations. The explanation you give: "it is impossible to disable some bad extra software layer in ALSA is not correct however." The problem is caused by application software that can use OSS4 properly, but that can not use ALSA properly. That is a perfectly valid reason to use OSS - but not to say ALSA is bad.

[igorzwx]

I am sure you are right in that there is an audible difference between ALSA and OSS4 when one uses the software you mention. I do not distrust observations. The explanation you give: "it is impossible to disable some bad extra software layer in ALSA is not correct however." The problem is caused by application software that can use OSS4 properly, but that can not use ALSA properly. That is a perfectly valid reason to use OSS - but not to say ALSA is bad.

If you do not trust Petrov's ALSA plugin, you may try to create your own ALSA plugin to enable the true "exclusive mode" for ALSA.

In a word, those "yes-no" questions were just a standard method to clarify the problem to resolve the discussion in a positive way.
Example: Willy Brandt's "yes-no" interview (1972)
_https://en.wikipedia.org/wiki/Willy_Brandt

willy brandt interview "ja-nein" 1972
_https://www.youtube.com/watch?v=Mdh_CrRjivU
Willy Brandt berühmte JA & NEIN Interview
_https://www.youtube.com/watch?v=cMgJFG90w7w

[sm5bsz]

If you do not trust Petrov's ALSA plugin, you may try to create your own ALSA plugin to enable the true "exclusive mode" for ALSA.

In my program, linrad, a user who runs with ALSA and with device 0 selected as the default device can do the following observations:

1) audacity runs fine if linrad is NOT running.
2) linrad runs fine if audacity is NOT running. (and no other software that is using sound.)
3) If audacity is playing to device 0, linrad would not find device 0 during setup because it can not be opened.
4) if audacity is playing to device 0, and linrad was set to use device 0 earlier, linrad would fail with the message "Can not open the device for loudspeaker output."
5) If linrad is running, audacity would fail with the message "Error while opening sound device. Please check the output device settings and the project sample rate.

(Both audacity and linrad were set to 48 kHz, 16 bit, stereo in the above tests.)

Device 0 is Intel ICH5, analog. When I open it in linrad during setup, the only rate it can do is 48 kHz. It can do 8 bit audio as well as 16 bit audio but not more. Audacity and linrad can NOT use the device simultaneously because there is no mixer.

I do not know anything about Petrov's ALSA plugin, I have no reason to distrust your claim that it does not disable the mixer. Your conclusion that the reason is that the mixer can not be disabled in ALSA is incorrect however. Anyone interested can see how ALSA devices are opened in exclusive mode in the lsetad.c module of the linrad package.

You suggest that the audible difference in quality caused by the ALSA mixer is that it is buggy. I find it more likely to be caused by some other program running in the background with system sound open. Various programs could emit interference that would add into the mixer. You migth try to open the system sound device in exclusive mode and if that fails you would know that there is some software you should close to free the mixer. (You could use linrad for this) Once the device can be opened in exclusive mode I would guess that the mixer no longer would affect sound quality. A bug in the mixer is of course possible and you could find out if you find it interesting.

[igorzwx]

I do not know anything about Petrov's ALSA plugin

You can download Petrov's ALSA plugin here:
_http://ossnext.trueinstruments.com/forum/viewtopic.php?f=3&t=5788#p21155

Petrov's pcm_play can be downloaded here:
_http://ossnext.trueinstruments.com/forum/viewtopic.php?f=3&t=5789
See also: _http://ossnext.trueinstruments.com/forum/viewtopic.php?f=3&t=5792

You see, ossplay permits "exclusive mode" (-R)
Source code: _http://manuals.opensound.com/developer/ossplay.c.html

Code: Select all

$ ./strac* -e trace=ioctl,open ossplay *.wav -R
open("/etc/ld.so.cache", O_RDONLY)      = 3
open("/lib/libdl.so.2", O_RDONLY)       = 3
open("/lib/libc.so.6", O_RDONLY)        = 3
open("/dev/dsp", O_WRONLY|O_EXCL)       = 3
ioctl(3, 0x4004501e, 0xbfb5bc3c)        = 0
open("Tabla.wav", O_RDONLY) = 4
open("/dev/dsp", O_WRONLY|O_EXCL)       = 3
ioctl(3, 0x4004501e, 0xbfb5b17c)        = 0
ioctl(3, 0x40405902, 0xbfb5bcb4)        = 0
ioctl(3, SNDCTL_DSP_GETODELAY or SNDCTL_DSP_PROFILE, NORMAL => NORMAL) = 0
ioctl(3, SNDCTL_DSP_SETFMT or SOUND_PCM_READ_BITS, S16_LE => S16_LE) = 0
ioctl(3, SNDCTL_DSP_CHANNELS or SOUND_PCM_READ_CHANNELS, 2 => 2) = 0
ioctl(3, SNDCTL_DSP_SPEED or SOUND_PCM_READ_RATE, 44100 => 44100) = 0
^C

Code: Select all

$ ./strac* -e trace=ioctl,open pcm_play *.wav -s oss -f 48000 -b 16 -e
open("/etc/ld.so.cache", O_RDONLY)      = 3
open("/usr/lib/libasound.so.2", O_RDONLY) = 3
open("/usr/lib/libstdc++.so.6", O_RDONLY) = 3
open("/lib/libm.so.6", O_RDONLY)        = 3
open("/usr/lib/libgcc_s.so.1", O_RDONLY) = 3
open("/lib/libc.so.6", O_RDONLY)        = 3
open("/lib/libpthread.so.0", O_RDONLY)  = 3
open("/lib/libdl.so.2", O_RDONLY)       = 3
open("/lib/librt.so.1", O_RDONLY)       = 3
=================================================================
Module Info:

Short name: WAVE Player
Long name : Player for WAVE PCM file
Copyright : Copyright (c) 2009-10 PetrovSE
Version   : 1.0.3.4
Build     : Oct  9 2010, 19:23:46
=================================================================

open("Tabla.wav", O_RDONLY) = 3
Opening file "Tabla.wav" ...Ok.
 Samples rate    = 44100 Hz
 Channels        = 2
 Bits per sample = 16 (fixed)

Sample rate converter is activated.

Wave system [oss]: Open Sound System
open("/dev/dsp", O_WRONLY|O_EXCL)       = 4
ioctl(4, 0x4004501e, 0xbfa5e24c)        = 0
ioctl(4, SNDCTL_DSP_SETFRAGMENT, maxfrags: 8, fragsize : 4096 => maxfrags: 8, fragsize : 4096) = 0
ioctl(4, SNDCTL_DSP_SETFMT or SOUND_PCM_READ_BITS, S16_LE => S16_LE) = 0
ioctl(4, SNDCTL_DSP_CHANNELS or SOUND_PCM_READ_CHANNELS, 2 => 2) = 0
ioctl(4, SNDCTL_DSP_SPEED or SOUND_PCM_READ_RATE, 48000 => 48000) = 0
ioctl(4, SNDCTL_DSP_GETOSPACE => bytes : 32768, fragments : 8, fragsize : 4096, fragstotal : 8) = 0
ioctl(4, SNDCTL_DSP_RESET)              = 0
Wave device []: "/dev/dsp" !

H/W parameters:
 Samples rate    = 48000 Hz
 Channels        = 2
 Bits per sample = 16 (fixed)

[#--------------------------------------------------] ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(0, SNDCTL_TMR_START or TCSETS, {B38400 opost isig -icanon -echo ...}) = 0
[------#--------------------------------------------] [>>]  0:06 (149 ms)     
Done.
ioctl(0, SNDCTL_TMR_START or TCSETS, {B38400 opost isig icanon echo ...}) = 0

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.

Since ossplay permits "exclusive mode" (-R), it can be used for testing sound quality with OSS4.

Could you patch aplay to enable "exclusive mode"?

[sm5bsz]

Could you patch aplay to enable "exclusive mode"?

Firstly I verified that aplay is not using exclusive mode. I can run it to play one file while audacity is playing another.

I did not write the ALSA stuff in Linrad myself, but the code is similar to the code in aplay. In aplay.c, line 208:

printf(_("**** List of %s Hardware Devices ****\n")

a procedure starts that is similar to the procedure in Linrad at line 192:

while (1) // loop trough all cards.

In Linrad this is where hw_pcm_name and plughw_pcm name is determined.

On line 2236:

err=snd_pcm_open(&rx_ad_handle, rx_sndin_plughw_pcm_name, SND_PCM_STREAM_CAPTURE, 0);

the device is opened in exclusive mode. After that, several calls to different snd_pcm_hw_params_xxx routines are used to set the desired sound card parameters. (Many sound cards can use several sampling rates and formats natively.)

I can not compile aplay.c because aconfig.h is missing. It depends aconfig.h.in and presumably I would have to complie the complete ALSA package from source to get it.

Someone else could do this if there really is an interest. I think it would be fairly easy for someone who already has the build environment for ALSA running. Maybe a request to the ALSA development team could make them include an option to run aplay in exclusive mode.

[igorzwx]

I can not compile aplay.c because aconfig.h is missing. It depends aconfig.h.in and presumably I would have to complie the complete ALSA package from source to get it.

alsa-utils contains various generic ALSA command line tools, such as amixer, aplay, alsaconf, etc.
_http://www.alsa-project.org/main/index.php/Download

It can be downloaded here: _http://www.alsa-project.org/main/index.php/Download

Code: Select all

$ apt-cache search alsa-utils
alsa-utils - Utilities for configuring and using ALSA

On Ubuntu/Debian, alsa-utils package can be modified and patched with quilt, and recompiled with devscripts.
Example: _http://ossnext.trueinstruments.com/forum/viewtopic.php?f=3&t=5811&start=15#p21491

Using quilt, you can modify the source code with a text editor, and quilt could automatically create the patch.
You can apply your patches with quilt and un-apply them.
_https://wiki.debian.org/UsingQuilt
_http://cs-people.bu.edu/doucette/xia/guides/debian-patch.txt

[sm5bsz]

On Ubuntu/Debian, alsa-utils package can be modified and patched with quilt, and recompiled with devscripts.

Very good, but it is not a job for me. Personally I have no use for aplay or any other alsa-utils (with the exception of alsamixer that can be used to set volume controls.)

Presumably there are many others who could do this task. It can be done and it is not particularly difficult. To me it would mean work with tools I never used before...

Now it is time to finish this thread for me. We know why oss utilities are better than alsa-utils. It is not because of ALSA itself, it is the utility that does not use ALSA the way we want...

[igorzwx]

Very good, but it is not a job for me... Presumably there are many others who could do this task.

Yes. Let them try.

In a word, our brothers in Vanuatu are still trying to put their theories about the true secret of Cargo into practice.
Although, such theories may look very logical, reasonable, and credible, they do not seem to work, because the promised Cargo constantly fails to arrive. "They are missing something essential", as Feynman put it.

It might be stating the obvious, but Cargo cult theories are, in essence, pseudo theories. That is why they fail to work.

I am not going to believe your theory about the "exclusive mode" of ALSA. Your pseudo "exclusive mode" may allow to block a sound device and prevent other apps from using it, but it does not mean that it can disable the crappy software mixer of ALSA. Since ALSA has such an "advanced architecture", its "exclusive mode" should be as "advanced" as ALSA itself.

It might be obvious that ALSA is also "missing something essential". It is, in essence, a kind of "pseudo sound system". It can only produce "pseudo sound", regardless of how it is configured.

The noise in this recording has nothing to do with the soundcard performance...
If you listen you can hear that the noise is the noise generated by fans in computers and other equipment.

The simplest solution to the problem of background noise seems to be Sennheiser mics with pick-up pattern "Noise Cancelling". For example:

Noise canceling clarity – the microphone filters out ambient noise, keeping your voice clear and easy to understand
Pick-up pattern Noise Cancelling
_http://en-de.sennheiser.com/pc-stereo-headset-gaming-internet-telephony-voip-131
_https://www.amazon.de/Sennheiser-PC-131-Headset-schwarz/dp/B000NH4EI4/ref=sr_1_5?ie=UTF8&qid=1425304547&sr=8-5&keywords=sennheiser+headset

They may work wonders with your Intel ICH5 codec, OSS4, and Audacity.
To measure the level of noise, you can simply record "silence" (that is, your background noise) with Audacity, then plot a spectrogram for it (see settings in my screenshot). You can also zoom into your recordings, find a sort of "silence", and study its spectrogram.

Microphone Basics (Help Wiki): Pickup Patterns
_http://wikis.evergreen.edu/computing/index.php/Microphone_Basics#Pickup_Patterns