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.