HiRes 24Bit 352.8kHz WAV DXD - it works with OSS4

OSS specific Linux discussion (x86/amd64)

Moderators: cesium, dev, kodachi, hannu

Re: HiRes 24Bit 352.8kHz WAV DXD - it works with OSS4

Postby igorzwx » Thu Sep 29, 2011 12:30 pm

Cervisia wrote:
Are you going to say that the ALSA resampler is not disabled?
You told me to not change ~/.asoundrc, and to use just "aplay -v". :?


Yes. I told that. The reason is obvious. The Hypothesis 1 suggests that the ALSA resampler was not disabled during your "listening tests".

Do you know how to disable the ALSA resampler completely?

In a word, the output on terminal, which you posted here, allows to presume that your "listening tests" were made with 32bit 192kHz waves, which are not available for download on the 2L website.

Cervisia wrote:Anyway, for my listening tests, I didn't use dmix:
Code: Select all
$ aplay -D hw:D2 -v 2L38_01_192kHz.wav 2>&1 | grep -e '^[^ I]' -e '^  rate'
Playing WAVE '2L38_01_192kHz.wav' : Signed 32 bit Little Endian, Rate 192000 Hz, Stereo
Hardware PCM card 2 'Xonar D2' device 0 subdevice 0
  rate         : 192000
viewtopic.php?f=3&t=4402#p17714


You see, "the devil is in the details" http://en.wikipedia.org/wiki/The_Devil_ ... he_details
Especially, if it is about sound quality. If you are not careful about details, it is not surprising that you do not hear the difference. If the ALSA resampler was not disabled, how are you going to prove to yourself that it was not at work?

Let us summarize:
1. The Hypothesis 1 has not been disproved yet. On the contrary, it became more credible.
2. If a hypothesis cannot be disproved, it should be accepted as valid. Right?

Let us fix the fact: you are not careful about details.
Your first message in this thread proves this point.
This allows to presume that other details (e.g. hardware details) were also neglected.

Are you going to preach here your "ALSA beliefs"? Or you are going to share valid technical information?
igorzwx
Supporter
 
Posts: 998
Joined: Sun Jun 28, 2009 9:31 pm

Re: HiRes 24Bit 352.8kHz WAV DXD - it works with OSS4

Postby Cervisia » Fri Sep 30, 2011 6:55 am

Do you know how to disable the ALSA resampler completely?

  • Specify a "hw" device name; or
  • define a hw device as default in ~/.asoundrc or /etc/asound.conf; or
  • configure dmix to use the same sample rate as the source file (doesn't work if there are multiple rates); or
  • recompile alsa-lib with disabled rate plugin.

In a word, the output on terminal, which you posted here, allows to presume that your "listening tests" were made with 32bit 192kHz waves, which are not available for download on the 2L website.
I already mentioned that I converted it to 32 bits to make it work with "hw".
Cervisia
New Member
 
Posts: 7
Joined: Tue Sep 27, 2011 11:42 am

Re: HiRes 24Bit 352.8kHz WAV DXD - it works with OSS4

Postby igorzwx » Fri Sep 30, 2011 2:53 pm

Cervisia wrote:
Do you know how to disable the ALSA resampler completely?

  • Specify a "hw" device name; or
  • define a hw device as default in ~/.asoundrc or /etc/asound.conf; or
  • configure dmix to use the same sample rate as the source file (doesn't work if there are multiple rates); or
  • recompile alsa-lib with disabled rate plugin.

In a word, the output on terminal, which you posted here, allows to presume that your "listening tests" were made with 32bit 192kHz waves, which are not available for download on the 2L website.
I already mentioned that I converted it to 32 bits to make it work with "hw".


Are you going to say that this is an example of "valid technical information"?

If your method cannot be verified by clear-cut empirical tests, there is no reason to believe that it works.
How are you going to prove to yourself that the ALSA resampler is really disabled?
It seems that you do not need clear-cut empirical tests, because you have the gift of faith, and, therefore, you are able to believe. It is already obvious that you avoid clear-cut empirical tests for the same reason. Of course, it might be much easy for you to believe that your method works, if you do not know how to verify it. To make your "listening tests" more credible for you, you may try to convert the original waves into something else with the linear converter of ALSA (or other sort of crap).

If the Hypothesis 1 cannot be disproved by clear-cut empirical tests, it should be accepted as valid.
That is why you are trying to avoid such tests.

If you know how to recompile ALSA to fix the problem, you may follow the example of Google, and fork ALSA.
You see, Google forked the Linux kernel, and "Android's success is spectacular" http://lwn.net/Articles/446297/

It is already obvious that you do not know how to disable the ALSA resampler completely, although you claim that "it's the same as in OSS" viewtopic.php?f=3&t=4402#p17716
You are not likely to know the secret method, because the "secret esoteric knowledge" is a privilege for the elect. There are several reasons for this. It is supposed to prevent forks. There are also "commercial reasons". Red Hat Incorporation is a "commercial entity" http://en.wikipedia.org/wiki/Red_Hat If you need to solve a problem, or you need a driver, it may cost money. Red Hat, Inc. is a kind of "joint-stock company" http://en.wikipedia.org/wiki/Joint-stock_company They should show profitability to shareholders.
Every firm is most concerned with its profitability. One of the most frequently used tools of financial ratio analysis is profitability ratios which are used to determine the company's bottom line. Profitability measures are important to company managers and owners alike. If a small business has outside investors who have put their own money into the company, the primary owner certainly has to show profitability to those equity investors. http://bizfinance.about.com/od/financia ... Ratios.htm

This means that Linux drivers, e.g. ALSA drivers, might be very expensive. The story of German Foreign Office proves this point http://www.h-online.com/open/features/B ... 94263.html
It seems that Linux is so expensive that Google cannot afford it. It might be much cheaper to fork Linux than to deal with Linux developers employed by Red Hat, Inc. http://lwn.net/Articles/446297/
Google's Android code deleted from Linux kernel
'Go fork yourself!'

By Cade Metz in San Francisco
Posted in Operating Systems, 3rd February 2010 21:23 GMT

After removing Google's Android driver code from the Linux kernel, Novell Fellow and Linux developer Greg Kroah-Hartman has argued that the mobile OS is incompatible with the project's main tree.
...in a pair of posts to LWN.net, Mountain View open source guru Chris DiBona says that Android isn't in the main tree because the main tree doesn't want it.
"I think if the Android kernel were important enough to the mainline, then this wouldn't be a problem. The reality is that the mainline doesn't want the code, so a fork is a normal response to this," DiBona writes.
"This whole thing stinks of people not liking Forking. Forking is important and not a bad thing at all. From my perspective, forking is why the Linux kernel is as good as it is." http://www.theregister.co.uk/2010/02/03 ... ux_kernel/

It looks like Novell/Micro$oft also attempted to milk Google http://en.wikipedia.org/wiki/Novell#Agr ... _Microsoft
Novell Incorporated: Convergence of Windows and GNU/Linux Since 2006
http://techrights.org/2008/10/14/conver ... s-and-gnu/

If the Linux kernel development is somehow sponsored by Novell/Micro$oft, it should not be surprising that "Google's Android driver code" was removed from the Linux kernel for the "self-evident" reason that it is "incompatible" with Novell-Micro$oft's Linux projects. If the Linux kernel has been somehow privatized by Novell/Micro$oft, it might be obvious that Google is not likely to be allowed to use it as "free software". Such sort of "free and open sorce software" might be expensive to use and expensive to fork, especially, if it is ill-documented.

Do you think that OSS4 code is compatible with Ubuntu-Novell-Micro$oft's Linux projects, such as Gnome/PulseAudio?
If Gnome is somehow sponsored by Micro$oft (see: http://en.wikipedia.org/wiki/Miguel_de_Icaza ), it should have a kind of PulseAudio inside. Right? PulseAudio is said to be good, because it is the most "advanced" sort of ALSA. Could OSS4 be compatible with Red Hat's ALSA/PulseAudio projects?

Since OSS4 is well-documented, it is not likely to be compatible with a certain "business model". For example, the Russian scientists can easily find the knowledge they need in the OSS4 documentation, and create their own resamplers which work with OSS4. It is much more difficult to solve such problems with ALSA.

Are you going to explain how it is possible to fool yourself into the belief that the ALSA resampler is disabled by a "magic ALSA config"? Which rituals should be performed to make it possible? Should we try the ritual of jipari (in its collective form)? Should we follow the example of the jerks? http://www.pbministries.org/History/Joh ... rt3_04.htm

If all your knowledge is of the same sort, you may better post it to a theological forum.

Although, of course, I have to agree that we have to learn to believe in any case. Perhaps, we have to try the ritual of jipari, the rites of the the jerks, and anything else which might be effective for the purpose. Otherwise, it might be difficult to believe that Linux is really "free software". According to Anthropological studies, kava-kava, betel nut, and other drugs may facilitate "religious experience". The problem is how to believe. It is a real problem, because it has already been reported by certain "infidels" and "unbelievers": http://4front-tech.com/hannublog/?p=11

It seems that you are going to continue to preach here your "ALSA beliefs", although such beliefs are not likely to be consumable for OSS4 users. Are you intelligent enough to understand such things?

You may try to post your "religious knowledge" to Arch Linux forum. It might be useful for Ubuntu refugees and other masochists.
Arch Linux Forum Index» Multimedia and Games https://bbs.archlinux.org/viewforum.php?id=32

Problem with Pulseaudio by sonnyp
12 335 Today 20:16:59 by GogglesGuy
Removing and reinstalling audio after sound is gone due to update by goetzkluge
2 38 Today 19:02:48 by bernarcher
How to remove pulseaudio? by bertzi
21 395 Today 16:32:41 by goetzkluge
ALSA problem with PulseAudio by airbus001
4 185 2011-10-01 05:53:25 by airbus001


______________________________________________________________________
EDIT: There are huge distortions in the range of 14kHz and 20kHz in the file 2L_Mozart_24bit_96kHz_Weiss_SARACON_SRC.flac downloaded from the 2L website http://www.lindberg.no/hires/test/2L38_01_96kHz.flac (the username HD and the password 2L ).
These huge distortions can be detected with SoX sonograms, and they have already been detected by the Russian audiophiles. This means that you may need to visit doctors before it is too late.
http://www.sennheiser.com/sennheiser/home_en.nsf/root/sound_hearing_living
Reduced hearing capacity – understanding less and less, almost without noticing it
People are creatures of habit. We can quickly adapt to reductions in our hearing capacity. We barely notice how we keep having to ask people to repeat things, how we increase the volume on the television set, or how we are no longer able to filter out the voice of the person we are talking to when there are many other conversations going on around us. This is because the deterioration of our hearing is a subtle process. Those who recognize this in time and act accordingly have the best chance of counteracting this process and being able to continue hearing.

Did you know? Even a brief, violent sound (such as an exploding firecracker) can cause permanent hearing impairment.


To summarize: If huge distortions are obvious on sonograms around 30kHz, there likely to be big distortions below 20kHz. To detect such distortions, you may need to increase resolution of sonograms.
igorzwx
Supporter
 
Posts: 998
Joined: Sun Jun 28, 2009 9:31 pm

Previous

Return to Linux

Who is online

Users browsing this forum: Google [Bot] and 1 guest

cron