I'm trying to get virtual_oss set up as a loopback device so that I can record system audio, using the command: virtual_oss -S -C 2 -c 2 -r 48000 -b 16 -s 1024 -f /dev/dsp3 -l ldsp

but recording from /dev/ldsp then gives nothing but silence

maybe I'm not understanding what -f does. I thought it meant that the loopback device would route the sound being played back through /dev/dsp3

is it actually just forwarding the audio from the loopback to the main pcm device, while providing that for recording on the loopback?

-f /dev/dsp3 seems equivalent to -P /dev/dsp3 -R /dev/dsp3, so what exactly is happening with dsp3's recording stream?

ant-x: you can pass (a copy of) an open fd to another process using sendmsg()

over a Unix domain socket

and yes, httpd would be the client, blocklistd is the server

And there should be an interface pre-determined between the client and server, right?

re: httpd as a client -- understood that much from <obsessivecomputingdisorder.com/posts/blacklistd-guide> .

if you mean a protocol, yes, all IPC (or RPC) requires both sides agree on a protocol, or nothing could be communicated

Yes.

if I'm creating a virtual_oss loopback and not specifying playback-only, does that just make the loopback audio a separate recording source on the loopback device?

how do I configure a virtual_oss device using mixer?

Which is why blocklistd support has to be built into the client.

another issue is that pulseaudio doesn't see the virtual_oss device at all, and just interfaces with the hardware /dev/dsp nodes

so I can only record audio from applications using OSS directly, well unless I want to record from pulseaudio as a separate stream to mix it in

at least this only applies to firefox for me. I don't have any other applications that require pulseaudio (yes, I know about switching the cubeb backend, but it causes 60fps videos to tank to close to 30fps)

I still haven't managed to figure out what the -R flag does for a loopback device, but I guess it doesn't matter, I'm not going to have to access my mic through the virtual_oss device anyway, I can just directly specify the device node

I wish virtual_oss' documentation mentioned how multiple backing devices can be specified for each virtual device. I was able to set up a standalone loopback device, for recording only what was played into it, and then I create a main /dev/dsp device that sends playback to both the loopback and the actual sound card, and uses the sound card for recording

to work around the pulseaudio issue though, since it seems like the default firefox package is already built with support, I'm considering switching to sndiod and using virtual_oss' sndio client functionality to route everything else

that's an extra layer of indirection though. instead of virtual_oss -> sound card, it's virtual_oss -> sndiod -> sound card

I always see warnings against mixing ports and packages, but what is the best way to do it, if I wanted to recompile stuff like SDL and mpv with sndio support, without sacrificing binary packages altogether?

do I need to make my own repository of selected packages using something like poudriere, then add that to pkg with a higher priority than the FreeBSD-ports repo?

I kinda wish the official repo would just enable the SNDIO option across the board. seems like a small enough dependency that people who won't use it won't notice or care that it's present, and then it spares actual users from having to build their own packages

the problem with mixing ports and packages is that the ABI of stuff can change, especially if you change options or use the quarterly pkg repo, but the main branch of the ports tree. So the repo you build would need everything that depends on SDL. To make building everything you want with just some changed options not as painful, poudriere can seed its build with the packages from the official

repos, but versions diffrences between the ports tree the builder build for the repo and the ports tree you are building at the moment can still result in building stuff you don't change options for or depending on those

as for changing default option, open problem reports for that, for individual ports I'm pretty sure that gets accepted, for making it a tree wide default, I'm less sure as the only options that are made default by the ports framework are DOCS NLS EXAMPLES IPV6

Hello, all. I am on FreeBSD 15.0-RELEASE. Is it time to convert it to pkgbase, or do I have plenty of time yet before it is too late to do easily?

I just had the exact same question as ant-x lol

ant-x: you can use freebsd-update for the entire support lifecycle of 15.0, it will only be dropped with 16.0. if you want to convert to pkgbase now, you can use pkgbasify: github.com/FreeBSDFoundation/pkgbasify - but there's no pressing need to do so

^ proofes the existence of a physical noosphere and the material nature of thought,

Yes :) And thanks ivy

i mean 15.x, not 15.0

so like four years

But 16.0 will come out earlier I guess?

ivy, thanks. And once 16 comes out, there'll be official instructions on updating to pkgbase, or it will do it automagically?

Will it use pkgbasify to convert or some other method?

wildeboskat: yes, 16.0 will come out, then 15.x will get several more releases before being EOL. and yes, the supported upgrade path will be pkgbasify

Thanks!

I only just updated to 15.0

pkgbasify is considered expermiental and potentially dangerous. I think it was written for the purpose of extended early testing of pkgbase.

Ahh thank you

ant-x: it won't be automated, but we might put pkgbasify in the base system, i'm not sure there's a concrete plan yet

Then I will leave it for now

So when these packages move to base, what will happen with the manual merging of conf files that freebsd-update does now?

ivy, re: won't be automated? But if 16 drop the old update system, there'll no other choise but to migrate.

wildeboskat: pkg does an automated 3-way merge, if it fails, it creates a *.pkgnew file that you have to merge manually. this is not a great workflow and is one of two major problems (imo) preventing pkgbase from being the default option

Ah I see thanks!

ant-x: right, you have to migrate, but you will do it manually. or you could switch to upgrading from source if you like

Yeah it's also the most painful part of freebsd-update IMO

OK, I see.

for example when 15.0 came with a freebsd.conf without the FreeBSD repo included I was not sure whether to remove it or not

well, the freebsd-update merge workflow is what i'd like to replicate in pkgbase - users do need to merge config files somehow (and i always preferred etcupdate to how dpkg does it, but ymmv)

re: merging files: I think it best to use /usr/local/ect/etc.d directories with your custom configuration files as much as possible to avoid merge conflicts.

That won't completely solve the problem because sometimes something will need to be removed that you have added in a .d directory

I tend to not use the .d's because the update system gives me a heads-up that something needs to change and it makes me look into why

Also I am admittedly lazy

And super disorganised

^ me too. I might learn from people more experienced in laziness and disorganisation.

:D

So, you don't use <include> in your newsyslog.conf ?

when one wants to run freebsd-CURRENT, the idiomatic way to upgrade it is to have a source tree locally with latest commit and just compile it, right? I find it a little unclear how the package manager interacts in a system running current

I don't think I ever touched newsyslog.conf, I didn't know it existed

That's a paradox: the separation beween system and user configuration via .d directoris may require better discipline to maintain.

It doesn't seem to exist on my system

seti_: you can build packages from source and use those to upgrade, i do that on all my development systems. if you don't want to do that, simply continue upgrading from source as usual

wildeboskat, ah? But it's /the/ mechanism for rotating log files.

the only thing being removed is freebsd-update, upgrading from source (make installworld) will continue to work

Oh yeah I do have it sorry ant-x

But never touched it

A good OS facility is like one's health: when it's well, your never notice it exists.

ivy: I see, but on a current system i can also just use the package manager as normal?

if i want to install the usual stuff like firefox

seti_: you can install and upgrade it using pkgbase without compiling anything, yes. although i probably wouldn't recommend that since part of running current is you may need to test patches to fix bugs... but if you want to do that, you can

oh, if you mean ports packages, nothing has changed there. pkgbase only affects the base system

Well it did seem to have changed the repo name

yeah sorry i meant ports, I assumed the base system should only be upgraded from compiling the source tree

so one way pkgbase makes that easier is if you have a bunch of systems running current, you can build once and install the new base packages everywhere, without needing to mess with nfs

Sweet! I got only one so far to worry about

I wish to file an issue to bugs.freebsd.org proposing to mention the mailing lists and this IRC channel in /etc/motd.template . Are such proposals withing the scope the bug tracker? Shall I attach a git patch? Have you any objections?

ant-x: that's fine, category is probably "misc"

OK, will do.

ivy, I filed it under Base System / conf, because the MoTD is technically a config file: <bugs.freebsd.org/bugzilla/show_bug.cgi?id=295526> .

If anyone has a RPi 5 and wants to help test/use drivers for fan control and GigE and soon WiFi, github.com/aphor/FreeBSD15-RPi5-modules