media-sound/oss-driver-4.2.2019 and kernel 5.6.x

[ghost]

Fails to compile media-sound/oss-driver, produces a compilation error, as a result of which OSS actually does not work. build.txt

[ferion11]

I guess so, you are using the kernel 5.6.2. A lot of 3rd party kernel modules will break with kernel 5.6 (oss, nvidia, alsa 3rd modules, ... you name it). Many basic things like the simple "time_t" is removed from kernel 5.6 (because of the Y2038). I have fix only the "sys-fs/exfat-nofuse" and "sys-fs/exfat-linux". But the "media-sound/oss-driver" will need one patch to work with kernel 5.6.X.

[ghost]

That is me have to downgrade the kernel?

[ferion11]

Well, you can use kernel 5.5.X for a while. You can find one patch to 5.6 and use it, or wait to someone else make one. If this ebuild was 100%, I would be making this patch myself, but it's still missing one script to unload/load modules to a clean and easy way to change alsa/oss (by the way, you can just remove alsa from the kernel and use this ebuild now, if you want). But, at this time, you have to choose.

[ghost]

I did a kernel downgrade, now the drivers compile, but another problem arose, /dev/dsp and /dev/mixer are not created, from which the oss script gives an error: /dev/mixer: No such file or directory

• Failed to start OSS [ !! ]
• ERROR: oss failed to start As an attempt to solve the problem, I did modprobe oss_hdaudio and looked in lsmod so that the drivers loaded successfully, but it didn’t help

[ferion11]

Only one driver (in kernel or module) can use your card at the time. You have to choose Alsa or OSS, and remove the other. In this case you have to remove alsa from your kernel. You can have both modules loaded, but one will not work. Then just make sure that you don't have the alsa using your card:

zcat /proc/config.gz | grep ALSA
lsmod | grep snd

Then load the oss modules (it should be auto loaded by your "udev" service), and look at dmesg for possible issues.

[ghost]

I disabled ALSA still at the kernel compilation stage. I checked dmesg, nothing suspicious, only messages about the successful loading of osscore and oss_hdaudio. [ 323.037331] osscore: loading out-of-tree module taints kernel. [ 323.093721] oss_hdaudio 0000:00:1b.0: enabling device (0000 -> 0002) [ 323.093732] oss_hdaudio 0000:00:1b.0: PCI->APIC IRQ transform: INT A -> IRQ 22

[ferion11]

Tested it now here, and worked very well, you just have to make sure run:

# ossdetect -d
# ossdetect
# ossdevlinks

EDIT: Test it with osstest. You will need reconfigure your apps too.

[ghost]

ossdetect -d and ossdevlinks helped, thanks. True, the ALSA emulation layer does not seem to work, despite the presence of the libsalsa.so library, applications using ALSA are still silent.

[ferion11]

Well, sure you will have to configure many apps, but to your alsa emulation work you will have to make your alsa conf (eg.: "~/.asoundrc") have something like this:

pcm.!default
{
    type oss
    device /dev/dsp
}
mixer.!default
{
    type oss
    device /dev/dsp
}

[ghost]

Unfortunately, this script did not help. And what do you mean by “configure many apps”?

[ferion11]

Like:

• cmus need output_plugin=oss
• Pragha need Audio sink changed to "oss4"
• smplayer need Output driver changed to "oss"

and many others. NOTE: many apps don't work with the alsa emulation too

[ghost]

But there are problems with this, if Palemoon can be made to work with OSS through a patch, then I don’t know what to do with VLC, I did not find a patch for it, and OSS support has been removed from the upstream long ago.

[ferion11]

VLC just need one change of configuration too. After all, from https://wiki.videolan.org/OSS_and_ALSA/ we have:

VLC media player supports both as separate modules: oss and alsa.

[ferion11]

Many apps only need one change of configuration, but some need patch, recompile... It depends on the application.

[ghost]

Thanks for the help. True, I would like to continue the conversation for some hints, but I do not want to offtopic here, where should I write to you?

[ferion11]

Don't worry, it's just my local overlay (it easier to sync), you can talk here :)

[ferion11]

The vlc ebuld on the portage have --disable-oss, then you need one vlc ebuild with --enable-oss instead.

[ghost]

Good. Then give advice on how to configure VLC to compile with the OSS module? For in USE flags there is nothing related to OSS support.

[ferion11]

Good. Then give advice on how to configure VLC to compile with the OSS module? For in USE flags there is nothing related to OSS support.

Yep, you will need another ebuild with --enable-oss. The gentoo devs disabled it.

[ferion11]

It just need one line changed: https://github.com/gentoo/gentoo/blob/746770869b222dc7c4b2923c9282a779dd95c0d8/media-video/vlc/vlc-3.0.8.ebuild#L412

[ferion11]

On some apps, you have the option of use media-libs/portaudio or media-libs/openal. Both have oss support (it can be a good workaround in some cases).

[ghost]

I made a copy of ebuild vlc and placed it in the local repository, added the oss flag in IUSE and replaced --disable-oss with $(use_enable oss), it does not compile in general, it throws errors. build.txt

[ferion11]

Well, you will have to change something here:

checking for main in -lossaudio... no

It should be -lOSSlib (from /usr/lib64/pkgconfig/OSSlib.pc)

checking whether a statically linked program can dlopen itself...  * /var/tmp/portage/sys-apps/sandbox-2.13/work/sandbox-2.13/libsandbox/trace.c:_do_ptrace():74: failure (Operation not permitted):
 * ISE:_do_ptrace: ptrace(PTRACE_TRACEME, ..., 0x0000000000000000, 0x0000000000000000): Operation not permitted
no

There is some error here, but isn't related.

[ferion11]

By the way, now that you have one github account, you can use the app-text/wgetpaste without the file size limitation. Just go to https://github.com/settings/tokens and create one token with just "gist" selected (save the token hash) and any name, then configure your /etc/wgetpaste.conf to something like that (change the toke hash with your saved one):

# set default nick
DEFAULT_NICK=unknown515

# gists token
HEADER_gists="Authorization: token 55ce7f5a75f257ca1f7135ca69e7g578dhja7d75"

# change the default service
DEFAULT_SERVICE="gists"

# change default language for the ca and the osl services
DEFAULT_LANGUAGE_ca="Bash"
DEFAULT_LANGUAGE_osl="Diff"
DEFAULT_LANGUAGE_dists="Plain Text"

# change default expiration period for the ca service
DEFAULT_EXPIRATION_ca="1 week"

And now you can use the wgetpaste (I have tested with one 10MB log and worked very well). It's very usefull.

[ghost]

My logs are not so big, I do not see the point in this. _do_ptrace() fails, because I have kernel.yama.ptrace_scope=2 set for additional user-level security, but even if turn it off, the build still fails, it’s clear that need to patch the source code, which I do not know how.

[ferion11]

Yep, wait a little, i will download the vlc source here.

[ferion11]

ok! On the vlc ebuild, inside the src_prepare() add this line:

sed -i "s/lossaudio/lOSSlib/g" configure.ac || die "can't patch the OSSv4"

And try again.

[ghost]

Did not help.

[ferion11]

And the build log this time is the same?

[ghost]

Yes, and he writes the same. checking for main in -lossaudio... no

[ferion11]

Yes, and he writes the same. checking for main in -lossaudio... no

That's strange, the only line on vlc code that have "lossaudio" string is this one: https://github.com/videolan/vlc/search?q=lossaudio&unscoped_q=lossaudio And that line on the ebuild should or change it or die with that message.

[ferion11]

If it doesn't work, you may have to consider the change of some applications (for example, maybe the use of smplayer instead of vlc). Although with some work, I believe that it's possible to use OSSv4 in most applications. But not without some work, and unfortunately, with some issues too.

[ferion11]

Can I see your vlc ebuild?

[ghost]

Regarding the replacement, I already found an option for replacement, so if the VLC still can't to get to work with OSS, I can easily remove it. vlc-3.0.8.txt

[ferion11]

ok! please change the line (sed -i "s/lossaudio/lOSSlib/g" configure.ac || die "can't patch the OSSv4") position to the beginner of the src_prepare(). For some reason it's doing src_configure() task inside it (bad design) like eautoreconf

[ghost]

Did not help.

[ferion11]

Did not help.

Well, then for this, I will have to try the installation here. I don't like to install vlc, but i will try to at least compile it, fix the ebuild, and remove it.

[ferion11]

I have fixed the -lOSSlib issue, but it still don't use it (don't call the pkgconfig to get the cflag and libs), then it will need more work. For now: vlc_mod_ebuild.tar.gz

[ghost]

Oh, thanks for the help! It remains to patch Pale Moon, I hope that there will be no problems with it.

[ferion11]

Well, VLC upstream don't seams to like the OSS. Someday i will take a look at the alsa emulator for this ebuild too, there is some alternatives and configurations. But it's better to use apps that support OSS without it. And OSSv5 is in development too. The ebuild will get more useful updates too (like kernel 5.6 support). It's one(two?!) unfinished ebuild that aim to be clean, but for now it just work. And i'm still using Pure Alsa with kernel 5.5.X, because of one bug on amdgpu (it's one of the more unstable kernel versions that i have seen).

[ghost]

Generally. Unfortunately, that patch is not applicable for Pale Moon. In any case, thanks for the help, I think on this should be finished, because it seems to that you tired from my stupid questions.

[ferion11]

Generally. Unfortunately, that patch is not applicable for Pale Moon. In any case, thanks for the help, I think on this should be finished, because it seems to that you tired from my stupid questions.

It ins't about been tired of questions, it's more like is hard to keep and change one ebuild that i'm not using right now. The OSSv4 is good, but the original installer is very bad (like: it compile the kernel modules on the initialization of the service at boot time, mind-blowing). I'm think of ways to let it be more crazy-free possible. The VLC use a lot of CPU. The original mplayer is far more light (the media-video/smplayer is one very good GUI for it). I don't use "media-video/mpv" (with smplayer) because it use more CPU than the original media-video/mplayer, even when i'm using the GPU acceleration, the same for VLC. I like firefox because of "tab mix plus" ("tab mix link" now i guess), but after the drop of Alsa, it never have been the same again (you will find a lot of out of sync sounds without the PulseAudio), so I'm using Brave (chromium based) that have one very good way to handle Ads. So, I try not to make major adaptations to the ebuild that i'm not using, as it's difficult to maintain it, without having one installation of it running on my system.

[ghost]

Can I continue the discussion in private messages of the Gentoo Forum? I just would like to continue the conversation about this, but in a different place.

[ferion11]

ok! feel free to do it :)

[ferion11]

INFO: Because of the bug https://bbs.archlinux.org/viewtopic.php?id=254670, other bugs too and Kernel 5.5.19 been End of Life... I'm going to use Radeon driver instead of AMDGPU for now, then i will update to kernel 5.6.x and see this bug again.

[ferion11]

INFO update: Now i'm using kernel 5.6.7.

• The time_t problem got ok after, add to usr/src/oss4-4.2-build2019/core/wrap.h on line 28:

  #ifndef _TIME_T
  typedef __kernel_old_time_t time_t;
  #endif

  But there is still the file_operations conversion to proc_ops that the new proc_create requere. So i have try the simple conversion, but found more error, then more work is needed here...

[ferion11]

INFO update: using

Conversion rule is:

    llseek      => proc_lseek
    unlocked_ioctl  => proc_ioctl

    xxx     => proc_xxx

    delete ".owner = THIS_MODULE" line

[ferion11]

• The register_chrdev on /usr/src/linux-5.6.7-gentoo/include/linux/fs.h is still using file_operations (not the proc_ops), so now i'm between two types that should be the same.

[ferion11]

I will have to wait a little more to make one final patch (i don't want to make one for each version of the kernel 5.6.x).

[ferion11]

Looks like that proc_ops is just for /proc, so i need some conversion here. I have opened one kernel bug to see what's going on with this change: https://bugzilla.kernel.org/show_bug.cgi?id=207445 I can see from here: https://lore.kernel.org/linux-fsdevel/20191225172228.GA13378@avx2/ that maybe some copy conversion (just to one of these two function) will work. Have to study the code a little to find one better way of doing it using patch.