OSSv4 and FreeBSD?

Why doesn't FreeBSD adapt to OSSv4 as sound system? It broaden the sound card compability a lot.
thankss
FreeBSD is using OSS. OSSv4 was a proprietary close source extension before getting open sourced with the right BSD license 10 years ago. There was some merit in getting drivers in. Jacob Meuser (OpenBSD developer) and I had the discussion about this on OpenBSD mailing circa 2009 lists before Jacob disappeared from mailing lists (I hope he is OK as he had a prior history of disappearing for few years). We agreed at the time that that was a merit of porting some driverss from OSSv4 just as porting elements of OpenSolaris OSS system which surprisingly unlike ZFS also had a right BSD license.

https://marc.info/?l=openbsd-misc&m=124320935811324&w=2

However Jacob disappeared and OSSv4 10 years later is not such a big deal. You can talk to Alexandre Ratchov (OpenBSD sndio developer) and see if it is worth your time. Alexandre is accomplished musician and music producer who is using OpenBSD for backend including some rock concerts attended by 100K people. He would be the person to educate you. IIRC at the time of OSSv4 Solaris had the best sound implementation of any UNIX/like system.
 
Because OSS v4 is already available in port system, and anyone can use it with little efforts

audio/oss

I am afraid to not fully understand your question. But if your question is "how to make OSS v4 work ....."

In order to use it you need to build a custom kernel because OSS port is not compatible with FreeBSD embedded sound system that must be unloaded from the kernel, what is impossible with the Generic kernel because the modules are compiled into it.

This is what I have done by creating a custom kernel config. In the "sound support" section of the config YOU MUST DEACTIVATE all the devices. If you have never built a custom kernel please refer to the online FreeBSD manual.

These modules will be further still available, but only through dynamic loadable modules (with kldload command), and therefore will be unloadable if necessary.

So according to the hardware, I write a script (or you can use the 'kld' line in the rc.conf or loader.conf) to either load FreeBSD sound system :

kldload sound.ko [ the FreeBSD "OSS like" Framework ]
kldoad the_specific_sound_driver.ko [ the additional driver designed to work with the FreeBSD sound framework]

or start OSS service, just launching the rcd script (no additional driver to load)

Having done some tests on several hardware configurations, no OSS v4 is not the suitable solution in every situation.
In some situations the FreeBSD embedded sound system works better and, this is very important to notice, is far more stable. OSS from port system may cause some kernel crashes in some situations, it will depend on sound hardware.

This is probably why FreeBSD does not "embrace" OSS v4 as a default, because OSS is a general system not specifically tailored for BSD. On the contrary the FreeBSD implementation which is an "OSS like" sound system, is optimized for BSD and so very stable.
 
Last edited:
Why doesn't FreeBSD adapt to OSSv4 as sound system? It broaden the sound card compability a lot.
thankss

Potentially it does, but for example while my 'Asus Xonar DX soundcard' works under Debian and Arch with OSSv4 , it is not supported under FreeBSD (Thread asus-xonar-dx-no-sound-in-freebsd.62541).

So according to the hardware, I write a script (or you can use the 'kld' line in the rc.conf or loader.conf) to either load FreeBSD sound system :

kldload sound.ko [ the FreeBSD "OSS like" Framework ]
kldoad the_specific_sound_driver.ko [ the additional driver designed to work with the FreeBSD sound framework]

or start OSS service, just launching the rcd script (no additional driver to load)

Had to know this while I was using this as an example...
 
Does Sndio fully replace OSS for hardware access, or does it mostly supplement MIDI?
What are comparisons of OSSv4 vs Sndio for running audio hardware? Aside that some OSSv4 drivers are still proprietary.

I see how Sndio and OSSv4 can coexist on the API level. Is it practical for them to coexist on the back-end level?
 
Does Sndio fully replace OSS for hardware access, or does it mostly supplement MIDI?
What are comparisons of OSSv4 vs Sndio for running audio hardware? Aside that some OSSv4 drivers are still proprietary.
You question makes no sense at all. That is like asking what is a compassion between hay and a horse :rolleyes: OSSv4 is collection of drivers as well as API which exposes audio devices. sndio is OpenBSD audio server (amplifier, mixing sounds from different sources, MIDI, provides interfaces for applications like Firefox). sndio can use OSS or theoretically OSSv4 as audio source.

The following questions make sense. What is the difference between FreeBSD implementation of OSS and OSSv4 implementation? Is there any advantage in porting OSSv4 to FreeBSD and replacing existing FreeBSD's OSS implementation? If I have to guess the answer in behalf of FreeBSD audio hackers would be no. There is no advantage in porting entire OSSv4 and replacing current FreeBSD's implementation of OSS but it could be some benefit in porting drivers for some cheaper crappy proprietary audio cards which do exist in OSSv4 due to the reverse engineering to FreeBSD. However FreeBSD desktop user base is minuscule so short of OP porting the driver he needs from OSSv4 nobody really cares.
 
What is the difference between FreeBSD implementation of OSS and OSSv4 implementation?
In my experience, OSSv4 is much more worse,
I've never tried to use it on FreeBSD, but I tried to use it with GNU/Linux,
because I don't like alsa and pulseaudio.
For example, you need to restart OSSv4 after every suspend,
because it doesn't survive the suspend,
also you need to restart every video/audio,
because to restart OSSv4, first you need to stop all applications, that use sound (web-browsers, etc),
so you need to kill all apps that use sound, after every suspend.
So OSS on FreeBSD is much better option to use.
 
In my experience, OSSv4 is much worser,
Check grammar.
I've never tried to use it on FreeBSD, but I tried to use it with GNU/Linux,
because I don't like alsa and pulseaudio.
For example, you need to restart OSSv4 after every suspend,
because it doesn't survive the suspend,
also then you need to restart every video/audio,
because it will be muted after OSSv4 restart,
as well as applications, that use sound.
So OSS on FreeBSD is much better option to use.
It worked fine on FreeBSD last time I used it as desktop OS in the spring of 2007. At that time I did have newer consumer grade audio card for which a native FreeBSD OSS driver didn't exist. It was also available for OpenBSD (last time around 3.8-3.9 release IIRC which means around 11-12 years ago) and NetBSD. NetBSD 8.0 which is going to be released soonish will finally have a native audio mixer and little bit better OSS but when the dinosaurs were roaming the Earth your best bet to have a sound on NetBSD machine was OSSv4.
 
About suspend and OSSv4, from Arch wiki:
Suspend and Hibernation

OSS does not automatically support suspend, it must be manually stopped prior to suspending or hibernating and restarted afterwards.

OSS provides soundon and soundoff to enable and disable OSS, although they only stop OSS if all processes that use sound are terminated first.

The following script is a rather basic method of automatically unloading OSS prior to suspending and reloading afterwards.
/usr/lib/systemd/system-sleep/50osssound.sh/...

So better use native FreeBSD OSS, because it is much more usable, at least if suspend is working on your machine.
 
About suspend and OSSv4, from Arch wiki:
I don't think you will find many people who care about suspend and hibernation in FreeBSD camp. Those operations are irrelevant for day to day server use. Actually I could get fired if one of my FreeBSD servers goes into hibernating mode :eek:. If you need a UNIX on your laptop just get a Mac like most FreeBSD developers ;) and chill out. OS X is second to none as a media platform anyway.
 
If you need a UNIX on your laptop just get a Mac like most FreeBSD developers ;) and chill out.
I don't use Windows or macOS, because I dislike such products from moneymaking companies for masses.
When I choose some kind of software, I don't want to make few guys a little bit more rich,
while, if I can, I want to help to improve/support/promote that open source product, which I'm using,
because if it will be better, it will be better for every person who use that product (or will use),
including me, and not only for Apple employers, when they will receive a salary ;)
Such proprietary software should exist, but only idiots should use it, IMO, the majority of the Earth
population are idiots, in fact, so don't worry, such companies, like MS and Apple, will always have their customer.

I don't think you will find many people who care about suspend and hibernation in FreeBSD camp. Those operations are irrelevant for day to day server use.
I always comment something from my personal perspective,
also I do not think that such tasks, like OSSv4 installation,
is a common task on a servers, IMO it is more desktop related.
 
You question makes no sense at all.

OSSv4 is collection of drivers as well as API which exposes audio devices. sndio is OpenBSD audio server (amplifier, mixing sounds from different sources, MIDI, provides interfaces for applications like Firefox). sndio can use OSS or theoretically OSSv4 as audio source.

The following questions make sense. What is the difference between FreeBSD implementation of OSS and OSSv4 implementation? Is there any advantage in porting OSSv4 to FreeBSD and replacing existing FreeBSD's OSS implementation? If I have to guess the answer in behalf of FreeBSD audio hackers would be no. There is no advantage in porting entire OSSv4 and replacing current FreeBSD's implementation of OSS but it could be some benefit in porting drivers for some cheaper crappy proprietary audio cards which do exist in OSSv4 due to the reverse engineering to FreeBSD. However FreeBSD desktop user base is minuscule so short of OP porting the driver he needs from OSSv4 nobody really cares.
I was trying to get the comparison between OSSv4 and sndio. Sndio has an API, audio server and hardware access (that's what I've been told), that it can be used in combination with other drivers, APIs and servers. OSS has access to hardware backends, and has an API. Hasn't OSS been referred to as a sound server or sound architecture? The OSSv4 in ports is supposed to be able to test different physical outputs at once, which suggests, it's also controls the hardware layer, even if through another layer.

The server of sndio can be enabled on FreeBSD too, replacing OSS, not just at the API level. They've said using sndio at the server level that the volume was low, but it worked. On the API level both sndio and OSS can access the sound server or backend level. That sndio daemon can be enabled from /usr/local/etc/rc.d/, which is different from a port's API requirement or option for sndio.
 
Potentially it does, but for example while my 'Asus Xonar DX soundcard' works under Debian and Arch with OSSv4 , it is not supported under FreeBSD (Thread asus-xonar-dx-no-sound-in-freebsd.62541).

There is a driver available on github:
https://github.com/polachok/xonar-freebsd
https://github.com/shamazmazum/xonar-dragonfly

I've successfully compiled it with 12.0-CURRENT (TrueOS branch) without any modifications, so you might want to give it a try on 11.1. Chances are it will just compile and work right out of the box.
I still have an open/WIP PR on github against the TrueOS/freebsd branch, for which I need to find time to do some final testing. I don't have the hardware myself, a friend does and asked me for help with drivers. As I had a lot of OpenRC cleanup to do for the TrueOS client installations at our company, this got a bit more delayed than anticipated...
 

I have little experience with compiling and almost none in FreeBSD.

C:
static const struct {
    uint16_t vendor;
    uint16_t devid;
    char *desc;
} xonar_hw[] = {
    /* we actually support only this one, it shouldn't be too hard to add others */
    { ASUS_VENDOR_ID, SUBID_XONAR_STX, "Asus Xonar Essence STX (AV100)"     },
    { ASUS_VENDOR_ID, SUBID_XONAR_ST,  "Asus Xonar Essence ST (AV100)"  },
#if 0
    { ASUS_VENDOR_ID, SUBID_XONAR_D1,  "Asus Xonar D1 (AV100)"      },
    { ASUS_VENDOR_ID, SUBID_XONAR_DX,  "Asus Xonar DX (AV100)"      },
    { ASUS_VENDOR_ID, SUBID_XONAR_D2,  "Asus Xonar D2 (AV200)"      },
    { ASUS_VENDOR_ID, SUBID_XONAR_D2X, "Asus Xonar D2X (AV200)"         },
    { ASUS_VENDOR_ID, SUBID_XONAR_DS,  "Asus Xonar DS (AV66)"       },
#endif
};

C:
/* ST/STX only. Do we have pcm1796 in other cards? */
static int pcm1796_write (struct xonar_info *sc, uint8_t reg, uint8_t data)
{
    return cmi8788_write_i2c (sc, XONAR_STX_FRONTDAC, reg, data);
}

Reading the source code it says that only the STx variants are supported and also the source code mentions pcm1796, which is a different DAC than the Cirrus Logic CS4398 which is used for front(stereo) output in the DX card.

Also I'm learning that USB 1.1 vs 2.0 (audio class) is something to consider when looking at an external DAC supported by a BSD.

I agree with the observations of ILUXA, e.g. fighting with vmixctl.

We where off-topic anyway...
 
Because OSS v4 is already available in port system, and anyone can use it with little efforts audio/oss I am afraid to not fully understand your question. But if your question is "how to make OSS v4 work ....." In order to use it you need to build a custom kernel because OSS port is not compatible with FreeBSD embedded sound system that must be unloaded from the kernel, what is impossible with the Generic kernel because the modules are compiled into it. This is what I have done by creating a custom kernel config. In the "sound support" section of the config YOU MUST DEACTIVATE all the devices. If you have never built a custom kernel please refer to the online FreeBSD manual. These modules will be further still available, but only through dynamic loadable modules (with kldload command), and therefore will be unloadable if necessary. So according to the hardware, I write a script (or you can use the 'kld' line in the rc.conf or loader.conf) to either load FreeBSD sound system : kldload sound.ko [ the FreeBSD "OSS like" Framework ] kldoad the_specific_sound_driver.ko [ the additional driver designed to work with the FreeBSD sound framework] or start OSS service, just launching the rcd script (no additional driver to load) Having done some tests on several hardware configurations, no OSS v4 is not the suitable solution in every situation. In some situations the FreeBSD embedded sound system works better and, this is very important to notice, is far more stable. OSS from port system may cause some kernel crashes in some situations, it will depend on sound hardware. This is probably why FreeBSD does not "embrace" OSS v4 as a default, because OSS is a general system not specifically tailored for BSD. On the contrary the FreeBSD implementation which is an "OSS like" sound system, is optimized for BSD and so very stable.

I am a new freebsd user. How to install and configure OSSv4 in Freebsd12?
In a clean installation Freebsd, is it just make install clean , from ports?
 
I am a new freebsd user. How to install and configure OSSv4 in Freebsd12?
In a clean installation Freebsd, is it just make install clean , from ports?
Did you read the thread from the start? If all your favourite applications work fine with FreeBSD's native OSS, why do you want OSS4 from ports?
  • Please do yourself a favour & do not build(7) build on the host, but instead stick to packages from the official repository (pkg(8)). Building from ports(7) is justified if you need/want to change some option knobs for that specific port. And then better build jailed, with ports-mgmt/poudriere or ports-mgmt/synth.
EDITED to not refer to the build(7) manpage, because that could imply I mean one should build kernel & base/world jailed. I do not.
 
Last edited:
Also please note that that a newbie will easily run into trouble because of the version mismatch from quarterly (for packages) vs. latest (ports tree) ports(7) branches in addition to the problems that can (and will) arise from building ports un-jailed. In this particular case, audio/oss depends on several Gnome/Gtk libs, surprisingly in the domains of text-rendering & graphics (???). So when you build audio/oss yourself, you can no longer install any Gtk desktop from packages (in the default configuration).
 
Back
Top