FreeBSD amd64 GENERIC kernel
Hans Petter Selasky
hps at selasky.org
Fri Dec 15 10:10:50 UTC 2017
On 12/14/17 14:23, blubee blubeeme wrote:
> On Thu, Dec 14, 2017 at 4:35 PM, Hans Petter Selasky <hps at selasky.org>
> wrote:
Hi,
>> Most OSS v4 IOCTLs are supported by the in-base sound stack at
>> /sys/dev/sound . Further there is a ALSA to OSS wrapper in audio/alsa-lib
>> and audio/alsa-plugins which Chromium can use.
>>
> OSS provides ALSA emulation:
You mean the audio/oss port provides ALSA emulation?
ALSA is described here:
https://www.alsa-project.org/main/index.php/Main_Page
From what I know ALSA is a user-space library for interacting with
audio devices. The backend can vary from operating system to operating
system.
> http://ossnext.trueinstruments.com/wiki/index.php/Tips_And_Tricks
> But I also don't mind writing OSS drivers from chromium, why emulate when
> you can go native?
If you want to make a native OSS driver backend for Chromium for both
recording and playback, then please go ahead.
>> Making audio/oss the default audio stack in FreeBSD will not make most
>> FreeBSD users happy.
> Why is this exactly? Most FreeBSD users don't even use the platform as
> their daily driver,
> it's just something they hack on in a VM from their shiny Macbook or
> whatever.
audio/oss is intended for a specific group of audio professionals using
FreeBSD on real machines. OSS in FreeBSD-base has far better support for
the regular audio devices which you find in laptops, computers,
raspberry PI, not to mention USB and VM's.
>
> I can't speak for anyone but myself but I'd like to make FreeBSD user
> friendly for regular people
> who just want to surf the web and check their emails, this is just a step
> in that direction.
Despite your good intentions you shouldn't blame the in-base FreeBSD OSS
stack that you cannot do what you want with Chromium, because the
Chromium developer officially only supports the ALSA audio backend.
If you want to do something good for FreeBSD, make sure documentation
about new CPU architectures and coming chips both PCI and USB are made
available before products are released and not several years after the
Linux developers hacked together a driver. Second, make sure the
different PCI and USB vendors test their products with FreeBSD aswell,
before they release them into the market.
>> This port is intended for studio professionals which buy $1000 PCI audio
>> devices for audio production. Now with the advent of HighSpeed USB and
>> SuperSpeed USB audio, there is no real need to invest in an expensive PCI
>> device unless you need to do realtime audio processing. Further a lot of
>> audio equipment also comes with an ethernet plug :-) Just FYI!
>
> I am one of those guys and trust me I've had my fair share of issues with
> Audio even on Linux.
> You can even see this lil exchange on Ardours forum:
> https://community.ardour.org/node/15438
What is written on page 24 in the document referred to in the link above
is not fully true:
https://linuxplumbersconf.org/2009/slides/Paul-Davis-lpc2009.pdf
The OSS API is not only for the kernel, it is a general purpose
character device IOCTL API for any audio application. With the advent of
CUSE and audio/virtual_oss this is especially true. If you're smart you
can take advantage of CUSE's mmap() functionality to share memory
between clients and server having zero copyin/copyout latency.
The regular audio producing applications need no more than what the OSS
IOCTL API can provide, namely setting the sample rate, sample format,
MONO or STEREO, looking at how many bytes are buffered and that's it.
Please also note that the OSS support in Linux may not be as advanced as
that in FreeBSD. From what I know Linux the OSS support couldn't change
the sample rate and format in-kernel, leaving this up to every
application, which might be an argument against OSS in Linux, but not in
FreeBSD:
To my knowledge there is now a dozen software audio engines around for
various Linux desktops and JACK is one of them.
https://lwn.net/Articles/308445/
Again, I don't see a problem using libalsa on FreeBSD with applications
coming from Linux. Even if this is a kind of emulation like you say,
emulation can also be so-called seamless, that the user won't notice any
difference. If there are bugs in the OSS ALSA backend, let's try to
identify them and improve the current situation.
>
> Anyways, everyone has this idea that OSS is dead or it's terrible but I'm
> looking for the best performance
> if you listen to this talk: https://www.youtube.com/watch?v=6oQF2TzCYtQ&t=3s
> You'll see that it's ALSA, Pulse & JACK that are dying/ dead.
Linux guys like to "kill" stuff obviously and that is their motivation I
guess :-)
>
> I did a lot of audio work on Android and trust me, they try to avoid ALSA
> like the plague.
Reminds me of Samsungs attempt at JACK support for Android :-)
> You might say, what about ALSA? Well OSS supports ALSA emulation:
> http://ossnext.trueinstruments.com/wiki/index.php/Tips_And_Tricks
> It just needs some work.
>
> Once the updated OSS is a part of the kernel then things can move forward.
audio/oss is not sourcecode. It is a binary blob. It won't be accepted
into the kernel.
> How much audio progressed in FreeBSD or Linux in the past 10 years?
Read the SVN history for "sys/dev/sound" in the FreeBSD source tree.
--HPS
More information about the freebsd-multimedia
mailing list