[Bug 579300] Re: Please disable CONFIG_SOUND_OSS* and CONFIG_SND_*OSS*

[Christophe Van Reusel]

Dear Mister Daniel T Chen

I can answer same way;

> In this case, bugs need to be filed against the relevant source
>packages, and we need to assist upstream developers in fixing them.
>Wouldn't you want the bugs fixed regardless where they lie? Honestly,
>it sounds like XawTV and V4L are making poor assumptions about the
>older OSS API (much like ALSA makes poor assumptions about the
>underlying hardware - assumptions only exposed through the
> introduction of PulseAudio). 

Those packages do not seems to be under developpenment anymore. For
some, mostly just older hardware devices persons unfortunately needs to
keep on using them as long those devices are usable. You seem to forget
that they are just mostly analog devices. In the future yes they will go
away . But it will take another +- 5 years. So it absolutely does not
harm to leave oss emu as long we need them.

> What compatibility layer, if any, are you using? Are you routing
>routing everything ALSA through OSS4's alsa-lib emulation? Are you
>routing everything ALSA through PulseAudio configured to use ALSA
>through OSS4's alsa-lib emulation?

Yes this is well a good point and question. So far as it concerns me The answer off course is now. It's evident that i always keep up with the most recent developpment as fare it does work how its ment to work. a good example is Vmware for workstation has long time used /dev/dsp but now they are also up and using alsa. It's evident that I use in this case Alsa an will not use the oss for vmware anymore. But Here You point is good Some persons need to be wake up that there is a better way for some things and off course must try as far it's possible and really working to go further with the developpement.
The oss from pulse self is unfortunately pure crap. And even very contraproductif. the good way is to direct interact with alsa self not trough the unfinished pulse. As long you need oss it should be trough the basic alsa oss emu.

>There is at least one solution, which is to provide the affected
>programs with native PulseAudio backends. Sooner than later OSS is
>going to be dropped from upstream Linux utterly, and then Ubuntu won't
>be carrying it at all. Many distributions, e.g., Fedora, have already
>disabled OSS emulation support from ALSA (being it loading or entirely
>like Ubuntu has). Ubuntu needs to help consolidate, not help
>fragment, the audio landscape. As long as this emulation support
>remains enabled, we will remain in a quagmire of applications
>experiencing contention for the audio device, which increases the
>friction for adoption of Free Software.

>Yes, this is all easier said than done. But this is the way forward.

I still have to try that out but it's very complicated . i'm also very
occupied on other linux developemnts concerning dreambox and
unfortunately still can't split myself in then. Far much easier to just
recompile my own kernel with oss included since this at the end will
work for all applications and not only for tvtime. Also this will not
solve compatability from my sound chipset realtek 889a on gigabyte
extreme mb. and pulse audio (for alsa self it's ok by just modifying the
alsa_base.conf located into /etc/modprobe.d . Using oss emu does not
fragment the audio landscape at all. Anyway there will be a time oss
will be gone completely. So developpement from oss for pulse is a waist
of time. The good programs will work direct on alsa and not trough
pulse. Good audio devices do have build in chipsets who are performing
the operations like streaming digital to analog conversions and so one.
It's a waist of very needed and valuable time and processor capacity
needed for other stuff on your pc. having to use sox and so to be able
to here your sound from such devices like in pulse. The modern free
software is under developpement and is the longer based on direct
interacting with ALSA off course we need alsamixer for that but there is
a very easy one called gnome-alsamixer for that. -:)) . Evidently pulse
does conflict sometimes with it just cause pulse here again does not
recongnize the correct settings for HDA audio card and does not provide
any possible correction for that. the values obtained from bios are not
enough for pulse to determine the correct card. So to keep compatability
with all cards there is only one solution This is to provide a feature
to overide detected card by pulse like in alsa base self models = xxxx.
You Just can use the hell of the job alsa maintainers have with it if
you would ask it them nicely. I'm very aware that unlike mac for example
who are working with only there limited hardware it's not easy to keep
up with all different kinds of cards especially cause bios does not give
enough info about it some stack's are on different adresses depending of
the mb or pc  developper for the very same chipset and codecs.

>...except that it *does* produce conflicts. If a program uses OSS
>emulation, it *prevents* all other programs from accessing the sound
>device concurrently. How can we expect a smooth user experience if
>this is allowed to occur? (Yes, the same exists for ALSA plughw: and
>plug:{everything else}.) 

Well sorry but this problem we all now already for long. And yes every developper is off course occupied to make all new stuf directly interact with alsa to avoid that. A good example  for it is like Vmware for wokstation version above 7.0 like mentionned before (actually its' till now the only company who produces very good commercial software for linux ) and I did buy this. It's 10 times more word then the price so good it work's but its' not cheap i must admit. But also wine folowed. and other will do as well.
OSS does not produce a real conflict. As user of linux persons, anyway do have to look up for some stuff and soon will find out what this little problem is .  Honestly would You have this problem ???? i gues not. So enabling oss will not causing further developpemnt problems.


>I'm sorry you feel that way. I've contributed over ten years to
>helping clean up this audio mess, and certainly it doesn't feel good
>to read that people's applications are "broken"; certainly it doesn't
>feel good to read your (and others') rant(s). The larger goal is to
>improve the audio landscape in Linux, and because there remains work
>to be done, I'll help do it. Will you?


I'm sorry ass well that you feel yourself hurt. This is not my goal and  not for the many other complainers (i gues ). I'm very gracefull for some wunderfull things you did. Also very aware that it's a hell of a job and very very very time consuming. On top of it all for free like hobby. Especially cleaning up the mess. 

Appart from the cleaning up the mess I do not now which developpemnt you
made . I can give here the positif points about pulse.

Like sound server very very good (much better then the old one) 
Does play very good for pcm stuff especially rhytmbox and other audio players and multimedia players like totem (the current totem in ubuntu is even just wonderfull and big improvement against previous versions.
The absolutely wonderfull audio amplifying till 140 % which is particullary usefull when using headset. some basic mp3 are recorded with to low amplitude and this solve the problem. Obviously this is only usable for digital audio converted to analog this is just normal.(some users does unfortunately not understand the difference tjaa .. You can not change the world at your own but at the end it will come automatically anyway)
And there are many other good points from which i'm not aware cause i'm not using them.

Unfortunately the very very negatif. Very Very poor support for hda
audio cards (the majority is not or wronly supported) the major cause of
that is the limited bios info obtained at boot. The only solution for
that is provide a good interaction with the alsa_base.conf setings card
model. Most users having problems will soon or later drop on the needed
info with alsa-models.txt

The ossdsp trough pulse is in fact a waist of time. With the time (but i
gues +- 5 years) All applications and devices will be changed and
adapted. oss will not be needed at all by that time anymore.

So all your arguments for removing the oss emu do not stand anymore. It will on the contrary save you a lot off critisisme having it enabled again. It's really not for nothing that the basic linux kernel org team does keep oss and emu's into the core. It's just needed to provide an real multimedia large scale compatible operating system like as the mather of facts is ubuntu's goal. 
So your driven by a real good ambition to go forward and improve and to let things improve whe need such persons in the world.
But just forget the rule that on every action there is a reaction. Doeing things with the best intentions sometimes (rather many) ends up with a total out of control disaster. In fact your running here were walking is better not that we have to go backwards but no need to run forwards. Now a little step backwards actually it's not a step backwards but just correcting a to fast impulsevely token decision would be the only right thing to do. JUST PUT ALSA OSS AND EMU BACK INTO THE BASIC KERNEL.

A typ also review the spended time in oss V.xxx it's seems now just to
ceate that audio jungle your trying to avoid.

Hoping that your trying to enlarge your view to keep ubuntu really
multimedia compatible. this for maverick is not the case anymore. unless
we compile or own kernel.  i reverted about 3 years ago from debian
which I used alredy +- 3 years just for the better multimedia support in
ubuntu and some other stuff since ubuntu uses a much more recent basic
kernel then debian. But now nothing seems to be left of that ???

greetings christophe.

-- 
Please disable CONFIG_SOUND_OSS* and CONFIG_SND_*OSS*
https://bugs.launchpad.net/bugs/579300
You received this bug notification because you are a member of Kernel
Bugs, which is subscribed to linux in ubuntu.