oss4 not compilable on gentoo

[ossuserr]

Why do you ignore my info? Even if OSS supports lynx2 which is an old card... linux kernel STILL INTEGER nowadays and AdAPTEd to ALSA. Linux kenrel is the CRAP itself. That's why any driver for linux tends to be a crap too. But you may have noticed that libalsa and jackd support non-kernel floatpoint same way as present-day OSS supports only NONKERNEL floatpoint.

[igorzwx]

Why do you ignore my info? Even if OSS supports lynx2 which is an old card... linux kernel STILL INTEGER nowadays and AdAPTEd to ALSA. Linux kenrel is the CRAP itself. That's why any driver for linux tends to be a crap too. But you may have noticed that libalsa and jackd support non-kernel floatpoint same way as present-day OSS supports only NONKERNEL floatpoint.

Because I do not need "software mixing" and "digital crap" produced by this kind of mixing.

[ossuserr]

Why inkernel mixing was a good idea it's because software communicates with CPU and other hardware via kernel. so kernel itself is a kind of compatibility layer which is currently ALSA-oriented. So the idea of pro sound was buried about 13 years ago when they removed float-point support from linux kernel.
So if you want to get any benefits from OSS first patch the kernel to make it OSS-oriented... Have you ever thought that you can be semi-deaf too?

I personelly think that today it's better to use windows due to its inkernel floatpoint support. Perhaps Oss can be compiled for windows?

[ossuserr]

You are funny with this "digital crap" and "hardware noncrap". Who told you that hardware cannot be crap? :d

[ossuserr]

It seems that it may be possible to switch on inkernel floatpoint operations by employing freebsd kernel on gentoo. https://wiki.gentoo.org/wiki/Gentoo_FreeBSD
But the question is if OSSv4 supports that kernel floatoperations since it must be adapted to alsa-oriented kernels... Probably you must use some very old OSS version...

[ossuserr]

Some clarifications have started to appear as to why not all insturments/channels/output devices/linuxsampler boxes are shown in patchage. Fantasia which is front-end to linuxsampler gives the following warning during loading preset file:
Getting audio output drivers: AudioOutputDeviceAlsa:can't find any card

Perhaps it means that fantasia can be reconfigured to using only jackd which may provide loading of all output devices.

And thoughts about OSS for debian. Debian uses dkms package for OSS installation. What's that DKMS. It's a kind of the kernel modifier tool without manual recompiling. So we may suppose that it hacks the kernel to support float-point operations and it means that on debian there can true benefits of OSS use. While on gento no such dkms is used. Moreover the driver does not compile with USE flag pax_kernel ON. What does that flag mean? It's evident it has connection with the kernel and it can be that ithis very flag operates like dkms thing in debian. And perhaps without that flag the compiled OSS is no better than alsa since kernel remains unmodified and has no floatpoint support. Why enabling this flag stops the compilation is unclear. I may support that dkms-like things are property of systemD variant of linuxes while i am using openrc variant.
Moreover i can claim that p16v subdevice of audigy2 zs with ALSA sounds more cleaner than emu10k1 with OSS and OSS does not support p16v subdevice on my card. Honest comparison could be if that device were supported by OSS. So when someone tells you that OSS is better when you disable all resamling via exclusive mode it's not true since you can also disable all resampling in ALSA by addressing directly to hw:x devices via the programs that support this. Moreover with Alsa i can address p16v directly, with OSS not. And of course p16v is more higher quality than emu10k1 on OSS whatever manipulations to improve sound you do on OSS.
In my opinion using OSS does not give any benefits today as to sound quality at least with regard to my soundcard. On the contrary it makes almost all music producing software not working because it requires jackd2 not supported by OSS. All this means that hardware is priority as to soundquality, for playback quality namely its dac. At the same time direct access to devices is possible both on OSS and ALSA.

Another interesting peculiarity noticed. If exl_policy is set to 2 in osscore.conf with OSS i may use my soundcard simultanously by jackd and by any player if vmix is ON. With alsa with the card reserved by jackd it's not possible to playback in players via alsa, but only via players configured to use jackd. That is one of OSS features i like.

So i my opinion and opinion of many other people quoted above OSS is not superior in quality. I may only agree that OSS resampler can be superior than libsamplerate which is a 100% crap. And if you load samples of different sampling rate jackd tries to resample them to a single samplerate set in jackd. Without setting samplerate jackd won't even start. And the question is which resampler jackd uses? On gentoo jackd can be compiled without libsamplerate support but still it does resampling using some unknown, perharps internal, resampler of uknown quality. They claim jackd does 32-bit operations. And actually in qjackctl there is an option to force 16 bit mode. I personnely have to force that 16 bit mode because my soundcard's emu10k1 supports only 16-bit. Of course it degrades quality. But suppose your card supports 32bit. In this case jackd converts all streams into 32 bit using its resampler of unknown quality and plays back also in 32bit. The fact that audiocard's 16bit devices cannot be used in 32bit mode by jack may mean that jackd may use soundcard's resampler and there is no internal resampler within jackd. It may be true since jackd is opensource and jackd developers constantly claimed to me that jackd makes no resampling and that can be true if it uses soundcards' resamplers. This also explains why jackd works without libsamplerate. Not difficult to assume that libsamplerate is required only if your card may not do resampling|some samplerates resampling|has poor quality resampler even worse than the card's hardware resampler. Jackd seems demystified now.
But how could i improve soundquality specifically on my card? As far as i found out p16v can accept 32-bit streams for high quality playback but p16v itself does not do any convertions to 32-bit. So 1) jackd can't use p16v as its device for making convertions, i.e. will give xruns if you configure jackd to use p16v aka hw:0,4 device 2) p16v could be employed for output if jackd is compiled with libsamplerate library support. In this case libsamplerate will make all sampling convertions within jackd to 32-bit and 32-bit stream can be fed to p16v for output. But libsamplerate is a crap. But still it's worth trying to employ p16v with libsamplerate. Of course jackd needs a higher quality internal resampler. Moreover some software resamplers are much better than hardware resamplers, for example Petrov's one. If Petrov can share his code and make it opensource we may try to push jackd developers to make its support for jackd.
So to get acceptable quality from jackd we must own a 32-bit card with the best resampler. Has anyone done comparison of cards' resamplers? I doubt but we can read about resamplers types and specifications which is big work. we may suppose that more expensive cards have better resamplers. So not only dac plays a role in providing high quality but also internal resamplers. People recommend delta1010 and emu1212 cards. And of course jackd is not a crap if you have a 32bit card. If you card may do 32 bit float operation maybe it would be even better. I don't remember if jackd supports floatpoint. But actually jackd MUST be modified to be able to be compiled with other resamplers than libsamplerate. Why those devs do not do it can be because they are paid by corporations not to improve that jackd to make people buy expensive audiocards because those corporations also want benefits.

[ossuserr]

I have just remembered someone told me that libsamplerate is only 16-bit. So it won't be possible to employ p16v on jackd in 32-bit jackd mode. I suppose we in asound.conf we can create a virtual snoop 32bit device, emply petrov's 32bit resampler into that snoop device to make all convertions of all streams to 32bit before they are supplied to jackd. It may be that jackd can recognize and use those virual devices same way as hardware devices of the soundcard and in this case i can active 32bit more on jackd.
With oss this idea is not even possible i suppose. The idea is to make resampling convertions not within jackd but before jackd which can allow to use high-quality software resamplers.

[igorzwx]

It seems that Ardor can really cause a kind of "mental disorder".

THERE IS NO IN-KERNEL FLOATPOINT MIXING NOWAdays BY OSS. OSS only supports floatpoint data but not floatpoint kernel mixing since LINUX KERNEL doesn't support floatpoint.
_http://www.opensound.com/forum/viewtopic.php?f=3&t=5807&start=45#p21286

If it is true, VMIX should fail to work on Linux, because VMIX is compiled to use floating arithmetic on Linux (by default).
Notice, that it is VMIX that performs "floating point mixing" in Linux kernel.

If you do not believe that VMIX is compiled to use floating arithmetic, you may try to recompile OSS4.

Notable configure switches (optional):
--config-vmix=NO|FLOAT|FIXEDPOINT: Don't compile vmix (NO)/Use only integer arithmetic for vmix (FIXEDPOINT)/Use floating arithmatic (FLOAT).
Compiling on Linux defaults to FLOAT, all else defaults to FIXEDPOINT.
_http://www.opensound.com/wiki/index.php/Building_OSSv4_from_source#Notable_configure_switches_.28optional.29

In short:
1. VMIX is a "software mixer" which performs "floating point mixing" in Linux kernel.
2. VMIX is disabled by default for professional soundcards, such as LynxTWO (which has a powerful hardware mixer), because VMIX produces sound distortions _http://manuals.opensound.com/usersguide/vmixctl.html

LynxTWO family of professional audio devices
_http://manuals.opensound.com/usersguide/lynxtwo.html
_http://manuals.opensound.com/devlists/lynxtwo.html

To ensure "high quality playback" with ordinary soundcards, you may want to use the "exclusive mode" of OSS4, which disables VMIX and all resamples of OSS4.

I am reading Robert Love's "Linux Kernel Development", and I came across the following passage:
...Using a floating point inside the [Linux] kernel requires manually saving and restoring the floating point registers, among other possible chores.
_http://www.opensound.com/forum/viewtopic.php?f=3&t=5807&start=45#p21282

Does it it mean that it is possible to use a floating point inside the Linux kernel?
Perhaps, you should not read such books, because it can only produce misunderstanding and confusion.

According to Anthropology, the most exotic Cargo cults were caused by "reading books", such as the Bible.
Although, of course, the main problem was misunderstanding, rather than books.
For example, the Vailala Madness was caused be a sermon preached by a white missionary.

The Vailala Madness acquired its name from observations of the behaviour of people who participated in it, which included glossolalia, shaking and psychosomatic symptoms [foaming at the mouth, lunatic raving, etc.]. _https://en.wikipedia.org/wiki/Vailala_Madness

[ossuserr]

I am not knowledeable on the kernel subject but you seem to be not knowledgeable either since all you arguments are "don't read this book" or "someone causes mental disorders". Quite not technical...

Of course vmix can use float-point but it's compiled as a module right? Let's have a look at what a kernel is. Kernel consists of two parts: the kernel image and external modules. So what has happened about OSS and the kernel? In the past, as i understand, oss was compiled not as external modules but within the kernel image and menuconfig had options to enable oss support or even the kernal pack itself could contain OSS code. Nowdays all OSS strings in kernel pack are depricated. If you don't believe download any modern kernel, unpack and cd to the folder and issue make menuconfig, press / and type oss to find oss strings. You will only find some depricated non-working strings. then make search for alsa and you will find a lot of working strings ... Nowdays oss can't be compiled as part of the kernel image, but only as modules. It means that no work is done to make any support for oss in modern kernels. So external vmix module provides floatpoint operations, same way as libalsa provides such operations for alsa. The kernel image itself is no longer used to do such operations and they are not recommended but possible. Anyway i don't see any benefit of oss over alsa as to sound quality. But alsa + jackd2 are needed for programs to compose music. Oss sounds a bit different but no any advantages for music production.
I think i will get a 32bit card and will use jackd2 + alsa. If all my streams' rates are supported by the card no resampling is done on linux but on soundcard. Otherise i will try to employ some resampler like Petrov's.

[igorzwx]

I am not knowledeable on the kernel subject but you seem to be not knowledgeable either since all you arguments are "don't read this book" or "someone causes mental disorders". Quite not technical...

Of course vmix can use float-point but it's compiled as a module right? Let's have a look at what a kernel is. Kernel consists of two parts: the kernel image and external modules. So what has happened about OSS and the kernel? In the past, as i understand, oss was compiled not as external modules but within the kernel image and menuconfig had options to enable oss support or even the kernal pack itself could contain OSS code. Nowdays all OSS strings in kernel pack are depricated. If you don't believe download any modern kernel, unpack and cd to the folder and issue make menuconfig, press / and type oss to find oss strings. You will only find some depricated non-working strings. then make search for alsa and you will find a lot of working strings ... Nowdays oss can't be compiled as part of the kernel image, but only as modules. It means that no work is done to make any support for oss in modern kernels. So external vmix module provides floatpoint operations, same way as libalsa provides such operations for alsa. The kernel image itself is no longer used to do such operations and they are not recommended but possible. Anyway i don't see any benefit of oss over alsa as to sound quality. But alsa + jackd2 are needed for programs to compose music. Oss sounds a bit different but no any advantages for music production.
I think i will get a 32bit card and will use jackd2 + alsa. If all my streams' rates are supported by the card no resampling is done on linux but on soundcard. Otherise i will try to employ some resampler like Petrov's.

That book states (as you quoted it) that it is possible to use floating point inside the Linux kernel.

What was deprecated in the Linux kernel is the old OSS3, that is, OSSv3.
That old OSS3 does not make any floating mixing inside the Linux kernel.
It does not have VMIX.

It seems that the only way to stop your ravings is to delete your posts.

[ossuserr]

Yes and help to the poor Rothschields.
I am a semi-deaf alsa fan now. Everything works and I am glad

[ossuserr]

The most valuable info I figured out while searching data for this thread is that you probably need a 32bit card to allow use of 32bit mode of jackd. My card is 16bit only (emu10k1) and i have to force 16bit mode. jackd uses hardware resampler of the card for mixing. So actually that hardware mixing of ancient lynx2 is hardly needed, as far as i understand. lynx2 is 32 bit as far as i remember. You can use it with jackd with the same quality since the same hw resampler will be used to join the streams. Or you can use any other 32bit card. All of them are of professional category and must sound well.
Also according to jackd developers, jackd does not use alsa or ffado. It's kind of driver independent. It only connects to hw devices directly via that driver.

All the talks about mysticism and audiphile quality based on that mysticism i consider brainwashing. What really matters is the quality of the hardware resampler (since software resampling can be done only via bad libsamplerate in jackd) and DAC quality + monitors|headphones quality unless you do not record anything (my case).

[igorzwx]

bad libsamplerate in jackd

It seems that Audacity devs are doing something about resamplers:

The SoX Resampler library (libsoxr) has replaced libresample in Audacity releases, offering both higher quality and greater speed.
_http://wiki.audacityteam.org/wiki/Release_Notes_2.0.3#Resampling

Audacity uses a library called libresample, which is an implementation of the resampling algorithm from Julius Orion Smith's Resample project. Audacity contains code to use Erik de Castro Lopo's libsamplerate as an alternative, but we can't distribute that with Audacity because of licensing issues.
For more information on our choice of resampling algorithms:
_http://comments.gmane.org/gmane.comp.audio.audacity.devel/4320
_http://comments.gmane.org/gmane.comp.audio.audacity.devel/4307
_http://wiki.audacityteam.org/wiki/HowAudacityWorks#Resampling

audacity-devel - SoX resampling - Nabble
At _http://wiki.audacityteam.org/wiki/Pending_Feature_Requests
there's mention of maybe using SoX resampling in Audacity.
I'm the author of the SoX resampler and have recently been doing some work to turn it into a stand-alone library (libsoxr): it's LGPL and includes a libsamplerate compatibility wrapper (but much than faster than libsamplerate). If you're interested, please let me know. I can't hack on audacity sources I'm afraid, but I can make mods to libsoxr if any are needed.
_http://audacity.238276.n2.nabble.com/SoX-resampling-td7556244.html

Perhaps, you may join their discussions.

[ossuserr]

i think there should be some chief guy who desides what can come to repos|portages and what cannot. For unknown reasons that crappy libsamplerate is still used on powerful modern multicore cpus...
It's really strange and silence everywhere... No one wants to discuss deeply jackd or resamplers. It hints of the idea that difference between pro and amateur hw|software lies in the resamplers|maths applied... How to make a profit? Make alike cards but put different maths inside and sell cards with good maths 10 times more expensive...
What is the result of it? Crappy sound because people can't afford expensive things and another result is worsening of taste, spoiling hearing, general foolishness and degradation.

And now some more demystifications about jackd. Jackd is said to make no resamplings but ... just read below:


-As far as i understand jackd uses hw resampler of the audicard if jackd is compiled without libsamplerate support, if it's compiled with libsamplerate supports it uses libsamplerate to resample if the card does not support resampling right?
Guy answers:
-Jack gets its clock from the soundcard. there is no resampling whatsoever. libsamplerate in jack is only used for netjack and alsa_in/out.
-how no resampling? for examble channel one in linuxsampler has sondfont 44.1 , in channel 2 - 48000, the sampling rate set in qjackctl is set to 48000., who resamples stream from ch 1 to 48000? card?
-LS needs to to the resampling

ok, so LS or any other jackd client does the resampling! But which resamplers do those clients use? the default alsa one i suppose! or some internal resampler of the client if its available in the client! It's not hard to guess that both default alsa resampler and a jack client's resampler can be of low quality. This is the weak point of jackd.

Guy continues:
Jackd is always 32bit float (internally). only when the signal leaves jack (to the soundcard) it converts the bit-depth..

Ok, which resampler does jackd use to convert bitdeapth before feeding the stream to a soundcard? The guy left that question unanswered... As you may see so far we already have at least 2 (or more!) resamplers in chain: resampler(s) of jackd clients and some secret resampler of jackd which resamples before feeding the stream to the soundcard.

Guy continues:
...only when the signal leaves jack (to the soundcard) it converts the bit-depth.. Jack tries the "best" settings first. But some soundcards are broken. e.g the soundcard says it can do 24 bit while in fact it can't. e.g the soundcard says it can do 24 bit while in fact it can't. that's what the "force 16bit" case is for

What are those best settings? Best settings of what? Of card's hw resampler? Or of jack's secret resampler? Who can clirify this?
Do you need to have at least 24-bit card to employ 32-bit mode of jackd? This question remained unanswered to me.

[ossuserr]

At last i got expanation from another guy concerning jackd:
- well you know that jackd uses 32bit float.how then it connects to 24bit card? it makes resampling?
Guy: jackd uses float yes, but that is because most audio software works in flot, which is easier
No, not resampling, it simply converts one number representation to the other
-does linuxsampler also works in 32 float?
Guy - float is only 32 bit if you use the entire range (-NUM to +NUM) for very large values of NUM, but audio signals only take values between -1 and +1
Yes linuxsampler works in float and all jackd clients.

So jackd cannot spoil sound. Buying a better 24 or 32 bit card that will improve sound due to better DACs. emu10k1 is a crap.