# OSS vs ALSA



## fernandel (Dec 12, 2013)

I remember a long time ago when many of us Linux users changed alsa for oss. But now it looks like alsa has much better support for the sound cards. As FreeBSD is becoming more and more user friendly and has better support for desktop computers, where is sound important too, are FreeBSD developers thinking of switching from oss  to alsa?


----------



## fonz (Dec 12, 2013)

If I'm not mistaken both OSS and ALSA are in the ports tree and are therefore third-party software that doesn't have a lot to do with FreeBSD itself.


----------



## kpa (Dec 12, 2013)

There is very little interest in ALSA among the FreeBSD developers as far as I know and remember reading from the mailing lists. It's down to the fact that on hardware that is supported by the FreeBSD base system the FreeBSD sound system (that isn't quite OSS but uses the OSS API) is vastly superior to ALSA.


----------



## DutchDaemon (Dec 12, 2013)

ALSA is released under the GPL license, and can therefore never be part of the FreeBSD base system. OSS was licensed more liberally.


----------



## ShelLuser (Dec 12, 2013)

First of all I think you may find this an interesting read. Other than that you might also want to check the sound(4) manualpage.

To elaborate a little more (I'm in a writing mood :e): the thing is that FreeBSD itself is basically a relative small base system. It provides some user land utilities (think about cp, man and even stuff such as ssh and sendmail) but it doesn't really care for much else.

And although Linux has opted to provide OSS and Alsa support right into the kernel, FreeBSD doesn't really do that either. That is; it does provide a sound system (see /usr/src/sys/dev/sound) but this doesn't seem to have much to do with neither OSS nor ALSA.


----------



## phoenix (Dec 12, 2013)

fernandel said:
			
		

> I remember a long time ago when many of us Linux users changed alsa for oss. But now it looks like alsa has much better support for the sound cards. As FreeBSD is becoming more and more user friendly and has better support for desktop computers, where is sound important too, are FreeBSD developers thinking of switching from oss  to alsa?



Considering OSS on FreeBSD gives you almost all the features of ALSA+PulseAudio on Linux, why would we want to downgrade to ALSA?

Considering how many Linux developers are afraid of using/fixing ALSA directly, and instead fix issues with ALSA higher up the stack (hence the existence of PulseAudio), why would we want to downgrade to ALSA?


----------



## fernandel (Dec 12, 2013)

I asked because OSS sound drivers don't work correctly with my Cirrus Logic 4206 but I tested it on Linux with ALSA and there are no problems. As  I did read on a/the mailing list there are problems with sound drivers on FreeBSD. And someone told me that the sound drivers on FreeBSD are the same as from OSS but older. I never tried to use ALSA on FreeBSD and I don't know if there is anything about this in the handbook.


----------



## neel (Dec 22, 2013)

ALSA isn't supported by FreeBSD. The ALSA-related ports are related to ALSA emulation utilities for OSS. You could also try audio/pulseaudio but PulseAudio in the ports is stuck at 0.9.23 when the latest version is 4.0. I'd like to know the model name of your computer. I think you have an Apple computer because Apple uses Cirrus Logic chips in many of their computers manufactured recently and doing a Google search of your chipset model came up with many Mac-related websites.

One thing you could also try is putting this in rc.conf:

```
snd_driver_load="YES"
```


----------



## zspider (Jan 6, 2014)

phoenix said:
			
		

> fernandel said:
> 
> 
> 
> ...



Especially since FreeBSD's OSS implementation is considered to be better than average. It's better to keep OSS.


----------



## throAU (Jan 10, 2014)

fernandel said:
			
		

> I asked because OSS sound drivers don't work correctly with my Cirrus Logic 4206 but I tested it on Linux with ALSA and there are no problems. As  I did read on a/the mailing list there are problems with sound drivers on FreeBSD. And someone told me that the sound drivers on FreeBSD are the same as from OSS but older. I never tried to use ALSA on FreeBSD and I don't know if there is anything about this in the handbook.



Buy $15 FreeBSD supported sound card, forget about problem


----------



## fernandel (Jan 10, 2014)

throAU said:
			
		

> fernandel said:
> 
> 
> 
> ...



I have FreeBSD installed on iMac 11,1 and I am not sure if $15 will be enough.


----------



## throAU (Jan 14, 2014)

Haven't spent much time with USB audio devices, but something that works with this would do the trick:

http://www.freebsd.org/cgi/man.cgi?quer ... +8-current


----------



## dominique (Jan 15, 2014)

phoenix said:
			
		

> Considering OSS on FreeBSD gives you almost all the features of ALSA+PulseAudio on Linux, why would we want to downgrade to ALSA?


My first FreeBSD installatiom is from today. I didn't get the time to look at the soud. Compared to ALSA+JACK, how do OSS on FeeBSD?

The main features of JACK are a constant sound latency (pulse is not abble of that and never will) and synchron operations of all the clients.



			
				phoenix said:
			
		

> Considering how many Linux developers are afraid of using/fixing ALSA directly, and instead fix issues with ALSA higher up the stack (hence the existence of PulseAudio), why would we want to downgrade to ALSA?



That's not true. Many of the developer's on the LAD are the same than the one on jack-devel, and they care about ALSA+JACK, which is a professional solution. The problem with the sound you are talking about is explained here: RealtimeKit and the audio problem. All the story with pluseaudio begun with Lennart Poettering. It is 2 existing possibilies to get realtime sheduling on linux, one is the rt patch, the seond one is with RT_GROUP_SCHED and the cpu cgroup. The advantage of that second solution is you can get realtime scheduling with a vanilla kernel. He is also the guy behind *kit and systemd.

What is very funny is with a few line into my ~/.asoundrc file, it is possible to interface ALSA and JACK, that with no mesurable added latency,  and each ALSA application is visible in the graph of `qjackctl`. So, ALSA and JACK is a much better solution than pulse and ALSA.

Systemd, when installed, will comppletely take over the control of the cgroups, and instead of implementing mean to make policies, which will give a great freedom to the users, it is implementing the policy, which cause already a bigger problem than the one systemd is intended to solve, and only about half of the job they want to do with it is done... No coment  :beer  For now, my USE flag on gentoo are "-systemd -consolekit -policykit -udisks -udisks2 -pulseaudio", but I don't know how long that will be possible. Maybe I am too pessimistic. It is not urgent, but I am looking for an alternative, so  I try FreeBSD.

Another big issue on Linux is wayland that come. That will break a lot of applications, because the compatibility layer will never be complete. X and all its extentions are just too complex. The goal of Wayland is to get more integration. I think they missed an important point about integration. The best possible integration I know, is like with AROS, to integrate every thing into the graphic server, from the window manager to the toolkit. The result is that the Gimp in its hosted AROS version start at least 5 times faster than the native gentoo version. They can say what they want about the multicore processors and a modern GUI, but 1 core is more than enough to run a well writen GUI that doesn't interfere with the system.

And all these issues are related, because this is the same peoples pushing to rewrite the kernel cgroups, stuffs like pulseaudio, *kit and systemd, and wayland. For me, that will be a perfect OS for old generation mobile phone, because a trend is slowly emerging on the mobile market, this is multi-core processors with dedicated cores. 1 low power and low frequency core for the stand-by, one dedicated for the hardware, one general purpose for the GUI, and 1 DSP for all the calculations. I really hope that trend will reach the desktop market as well. That because DSP algorythms are well known and have proved to be much more efficient than any well optimised code on a general purpose cpu.

EDIT: typos


----------

