OSS Driver Patch for Jackd2 on Ubuntu?

OSS specific Linux discussion (x86/amd64)

Moderators: hannu, dev, cesium

tarik2cyprian
Member
Posts: 28
Joined: Thu Jan 24, 2013 7:04 pm

OSS Driver Patch for Jackd2 on Ubuntu?

Postby tarik2cyprian » Thu Aug 08, 2013 1:59 pm

Does anybody have a patch for using OSS with Jackd2 on Ubuntu Linux Operating System. What happed was Ubuntu Developers took out the OSS driver in Jackd2
which is explained here https://bugs.launchpad.net/ubuntu/+source/jackd2/+bug/708581.

If anybody could provide me with the patch I will be greatly apprieciate it.

Regards

tarik2cyprian

igorzwx
Known Member
Posts: 1258
Joined: Sun Jun 28, 2009 9:31 pm

Re: OSS Driver Patch for Jackd2 on Ubuntu?

Postby igorzwx » Thu Aug 08, 2013 2:52 pm

tarik2cyprian wrote:Does anybody have a patch for using OSS with Jackd2 on Ubuntu Linux Operating System. What happed was Ubuntu Developers took out the OSS driver in Jackd2
which is explained here https://bugs.launchpad.net/ubuntu/+source/jackd2/+bug/708581.

If anybody could provide me with the patch I will be greatly apprieciate it.

Regards

tarik2cyprian


Have you tried jackd1 ?

Code: Select all

$ apt-cache search jackd1
jackd1 - JACK Audio Connection Kit (server and example clients)
jackd1-firewire - JACK Audio Connection Kit (FFADO backend)


Ubuntu 11.04 Jack_oss driver and LynxTWO
https://community.ardour.org/node/4370
Configuring_Applications_for_OSSv4: JACK
http://www.4front-tech.com/wiki/index.p ... OSSv4#JACK
Q: What's the difference between Jack1 and Jack2?
http://trac.jackaudio.org/wiki/Q_differenc_jack1_jack2

cesium
Developer
Posts: 902
Joined: Sun Aug 12, 2007 12:51 am

Re: OSS Driver Patch for Jackd2 on Ubuntu?

Postby cesium » Thu Aug 08, 2013 7:32 pm

tarik2cyprian wrote:Does anybody have a patch for using OSS with Jackd2 on Ubuntu Linux Operating System. What happed was Ubuntu Developers took out the OSS driver in Jackd2
which is explained here https://bugs.launchpad.net/ubuntu/+source/jackd2/+bug/708581.

If anybody could provide me with the patch I will be greatly apprieciate it.

Regards

tarik2cyprian


Well, what you need is to build from source. One way to do that is to get the source ('apt-get source jackd2'), the dependencies ('apt-get build-dep jackd2'), and then play with the debian build scripts (in the extracted source directory under 'debian/') to get it to build (the scripts are invoked by 'dpkg-buildpackage'). That said, long ago I had a look in jackd2, and saw the OSS4 support was enabled only for Solaris and had to patch the build system to get it under linux (it compiled, but I didn't get to test it much)? Maybe they changed that in the meantime...

tarik2cyprian
Member
Posts: 28
Joined: Thu Jan 24, 2013 7:04 pm

Re: OSS Driver Patch for Jackd2 on Ubuntu?

Postby tarik2cyprian » Mon Aug 12, 2013 9:17 am

Thanks igorzwx for the info. Yes I am using jackd1 as of right now and it works great accept for playing and recording 192000hz 24bit audio.

But I was just curious about using jackd2 to see if I can take advantage of multicore processing to
give me better results in elimiting xruns when playing and recording my 192000hz 24bit audio files.

I get xruns with jackd1 in my lowlatency kernal in Ubuntu Studios 13.04 64bit when playing and recording 192000hz 24bit audio;
I even set jackd to have higher priority at 89 and still get xruns. So I am hoping jackd2 will eliminate my problems with xruns.

And in reponse to cesium thank you as well for that info and I will follow your instructions to recompile.

Thank you both once again

tarik2cyprian

tarik2cyprian
Member
Posts: 28
Joined: Thu Jan 24, 2013 7:04 pm

Re: OSS Driver Patch for Jackd2 on Ubuntu?

Postby tarik2cyprian » Mon Aug 12, 2013 9:40 am

Ok cesium I think I found the path you are talking about under /home/username/jackd2-1.9.9.5+20130127git15950eb1/debian/

I have not done the dpkg-buildpackage yet.

Now there are a buch of files inside this directory under debian. Which file do I mess with to build the jack.oss.so driver?

igorzwx
Known Member
Posts: 1258
Joined: Sun Jun 28, 2009 9:31 pm

Re: OSS Driver Patch for Jackd2 on Ubuntu?

Postby igorzwx » Mon Aug 12, 2013 12:28 pm

tarik2cyprian wrote:Ok cesium I think I found the path you are talking about under /home/username/jackd2-1.9.9.5+20130127git15950eb1/debian/
I have not done the dpkg-buildpackage yet.
Now there are a buch of files inside this directory under debian. Which file do I mess with to build the jack.oss.so driver?


Ubuntu users are not supposed to know how to recompile Ubuntu packages with "debian build scripts". Otherwise, the may remove libpuse and other "open-source malware".

The "secret esoteric knowledge" is here: http://www.4front-tech.com/forum/viewto ... =15#p13781

Clever attack exploits fully-patched Linux kernel
The exploit works only when a security extension knows as SELinux, or Security-Enhanced Linux, is enabled. Conversely, it also works when audio software known as PulseAudio is installed.
http://www.theregister.co.uk/2009/07/17 ... l_exploit/
see also: https://en.wikipedia.org/wiki/Security-Enhanced_Linux


Why do you disturb Cesium with "naive questions"?
He does not even have time to delete very old spam, such as "grow penis" and the like. Example:_http://www.opensound.com/forum/viewtopic.php?f=3&t=3546#p14507

There is a reason to believe that this forum was hacked by spammers some months ago. They seem to continue to exploit it.
The accounts of users do not seem to be secure.

tarik2cyprian
Member
Posts: 28
Joined: Thu Jan 24, 2013 7:04 pm

Re: OSS Driver Patch for Jackd2 on Ubuntu?

Postby tarik2cyprian » Mon Aug 12, 2013 11:11 pm

Sorry igorzwz for the trouble I have caused. I was unaware about this and will not post any live links to this forum again.

Sorry once again

tarik2cyprian

tarik2cyprian
Member
Posts: 28
Joined: Thu Jan 24, 2013 7:04 pm

Re: OSS Driver Patch for Jackd2 on Ubuntu?

Postby tarik2cyprian » Wed May 20, 2015 11:51 pm

On 2015-03-21 there was a release for a oss driver for the newer versions of jackd2 for Ubuntu at the url below

hxxps://bugs.launchpad.net/ubuntu/+sour ... bug/708581

Does any one know where to find this new jackd2 package for download? So far I have yet to find it.

I currently only have jackd2 running oss for an older version of jack 1.9.7 but would like to upgrade to the current
version of jackd2 using this new release of the jack_oss.so (OSS driver) .

If anyone can help me find it reply to this thread or send me a PM.

Thanks Again

ossuserr
Known Member
Posts: 272
Joined: Thu Jan 08, 2015 12:01 am
Sound Card: audigy 2 zs platinum, esi juli
OS: gentu riced to bo0st
Location: Earth

Re: OSS Driver Patch for Jackd2 on Ubuntu?

Postby ossuserr » Sun Jun 28, 2015 1:10 pm

I also want OSS to work with jackd2. But it also lacks midi input and without midi input OSS is useless to me.

ossuserr
Known Member
Posts: 272
Joined: Thu Jan 08, 2015 12:01 am
Sound Card: audigy 2 zs platinum, esi juli
OS: gentu riced to bo0st
Location: Earth

Re: OSS Driver Patch for Jackd2 on Ubuntu?

Postby ossuserr » Wed Jul 01, 2015 12:22 am

Is there really need in that jackd? I don't know how it's constructed but i think the same mixing capability can be implemented on the level of a sound driver. Each program sends finally its signal to the driver directly or via some layer like wdm, openal, directx, etc. So the driver may have a layer before it which can take all streams and mix them into one and present a graphical representation of those streams like patchage. I think there is no need even for a software to have some special inputs and outputs like they do for jackd. Driver can handle all this. I noticed that ossxmix shows pcm1, pcm2,... etc streams which leads to this idea. If oss had midi support it could route midi messages into programs provided that programs were compiled with a kind of oss-midi feature.

ossuserr
Known Member
Posts: 272
Joined: Thu Jan 08, 2015 12:01 am
Sound Card: audigy 2 zs platinum, esi juli
OS: gentu riced to bo0st
Location: Earth

Re: OSS Driver Patch for Jackd2 on Ubuntu?

Postby ossuserr » Wed Jul 01, 2015 10:14 am

Lets start with some background.
Back in the old days, if you had a PC, there was only one card called "the sound card", which of course was the Sound Blaster 16. If you were playing any of the popular games back then, many of them only supported the SB16 for sound. Other companies who wanted to start releasing sound cards had to include Sound Blaster emulation if they wanted to get any kind of real sales. Sometimes this emulation was buggy, but you wouldn't know that until after you bought it. For this reason, people who wanted sound took no short cuts and only bought SB16s.

Thus back when Linux was first starting out, which was on the PC for the 3x86, there was only one sound card which demanded immediate support. Understandably, Sound Blaster support was completed and done very well rather early on for Linux. Since the API was good, as well as that most Linux programs which provided sound targeted this API, people who wanted to provide drivers for their sound card made their sound drivers use the same API. At this point, the API for the Sound Blaster became known as the Linux sound API, and all the various sound card drivers got merged into one neat little package, this later became the Open Sound System or OSS for short.

Since OSS was UNIX oriented and rather good, the other UNIX OSs starting up at that time such as FreeBSD and NetBSD wanted sound support too, and OSS was ported to them as well. Today OSS runs on virtually every UNIX OS except Mac OS X, but Linux, *BSD, Solaris, are covered, as well as even AIX and HP-UX and more.

Now from a developer standpoint, if you wanted to create a simple application with sound output, and you wanted it to work on the various UNIXs available today, the choice was simple, you write the code for OSS, and it's all nice and portable.

However, there was one major drawback perceived with OSS, and that was mixing. Say you want to listen to music while listening to the news. Not exactly that hard to setup if the music is soft and the news is loud. However when OSS was originally designed, it let the sound card handle 'mixing' which would allow multiple sound outputs be mixed together. But more modern sound cards decided to follow the path of modems and became mostly software. Once this happened, all features of a sound card had to be written up in software to work properly, and mixing wasn't always a focus, nor is it always a simple matter. Therefore many newer sound cards would lack mixing under OSS.

Therefore two new sound systems came into existence, aRts and ESD which were used mostly by KDE and Enlightenment/GNOME respectively. They used new APIs which did mixing before sending sound to OSS. They intended that new programs would use these APIs. Now I looked at both aRts and ESD, aRts seems pretty easy to use, even easier than OSS, and I wrote up a sound player in less than 5 minutes with aRts. ESD on the other hand looks like it might have more features than aRts to use, but also looks much more complex than aRts. With programs written to use one of these two, you could run multiple applications which use one of these sound systems at the same time and get sound out of both of them.

The problem with aRts or ESD though is that there are two of them, so while many KDE or GTK apps will use one or the other, you can't run both of them at the same time, as you can only have one of them work with OSS at one time because of the 'mixing' problem. It's even more problematic that you still have native OSS applications that don't go through another system. To solve many of these problems, library wrappers were invented.

First we have the Simple DirectMedia Layer (SDL) which wraps around OSS, aRts, ESD, and even sound systems on Windows and Mac OS X. Sounds good for portability, since it works everywhere, and you can have it use whichever sound engine on UNIXs so everything can play nice together. Unfortunately though, SDL uses sound only via a callback interface. While this is fine for many applications, it can get annoying sometimes, and in some applications which generate audio on the fly, not only can it be complicated to do properly, it might even be impossible to maintain proper sound sync.

Another nice competitor which I like is libao which wraps around OSS, aRts, ESD, and several other UNIX specific sound engines. The API for libao is also really easy to use, quite similar to that of aRts, and I managed to whip up sound applications with libao in no time at all. Unfortunately libao hasn't been updated in some time, and certain wrappers it has seem to be a bit buggy. libao also only supports blocking audio, which makes it complicated to write certain applications where the audio is generated while it's playing, forcing the program to use threads, hope one doesn't fall asleep while the other is working, and use semaphores and mutexes.

Because the general idea of libao was good, the MPlayer team took libao, fixed several limitations, updated it, fixed bugs, added many more sound wrappers, even two for Windows and one for Mac OS X, and dubbed their creation libao2. With MPlayer, you can change which sound wrapper to use with the param -ao and specify which system to use, or set permanently via the config file. I even took some libao2 DirectSound code, used it in a Windows application, and a Microsoft developer who I know looked at it and told me the code looked really good, which goes to show the quality of the underlying wrappers. Unfortunately though libao2 is bound to MPlayer, it has all kinds of MPlayer library calls within it meaning a major dissecting operation is needed to use it in another application. Perhaps some MPlayer or library developers can get together and separate the two, add on any needed features, and then we application developers can finally have a portable sound library to use, while potentially also allowing MPlayer to get better sound output on more obscure drivers because a developer who doesn't use MPlayer but another sound program might fix it.

Now while application developers are all worrying about their precious libraries, the developers of the portable UNIX sound system - OSS, decided to go closed source and offer extra features (which regular users don't need) to paying customers. This of course created an uproar, and some Linux developers decided to create a new solution.

Now instead of just rewriting OSS at the core, or using a wrapper (which understandably doesn't fix the underlying mixer problem), or updating the existing open source OSS at its base, some developers for some absurd reason decided they needed a whole new system and API to go with it. This is known as the Advanced Linux Sound Architecture or ALSA for short. This new API is huge, mostly undocumented, incredibly complicated and completely different than OSS. Which means various sound card drivers have to be rewritten for ALSA, and all applications have to be rewritten (or have more sound system support like SDL and libao) in order to use ALSA.

Other advantages of ALSA is that they included a software mixer (which doesn't always work). But as should be apparent, applications aren't magically overnight going to start switching over to ALSA. And as ALSA isn't portable, people who want to support BSD and Solaris will of course be using OSS. Meaning to support ALSA would mean needing to support OSS and ALSA. Since OSS exists on Linux, why even bother? Realizing this, the ALSA developers programmed OSS emulation into ALSA, so sane developers can just program for OSS. But the big embarrassment here for ALSA is that using ALSA via its OSS emulation is usually better than using ALSA directly. I've heard from many users of SDL or libao powered programs that telling those wrappers to use OSS (which ends up being used via ALSA's OSS emulation) works better with less gaps (or other problems) in the audio than using ALSA directly by those wrappers.

But for some really stupid reason, ALSA's OSS emulation doesn't support mixing. Which in the end really defeats the purpose of ALSA in the first place. I also have two sound cards which work both under OSS and ALSA and find OSS to just work better. Even more shocking is that I found in cards that have hardware mixers installed, they don't seem to be used by ALSA's OSS emulation, leaving such users without mixing in OSS apps. However, for some reason, I'm seeing a lot of propaganda lately that I have to make all my new applications use ALSA and not OSS because OSS is deprecated. I really doubt that because Advanced Linux Sound Architecture now exists that suddenly FreeBSD has deprecated OSS. How can something portable be deprecated just because one really near sighted OS can't figure out how to deal with life? Using non portable APIs is what is deprecated. I've smartly been forwarding all such ALSA propaganda to /dev/null, but it does bother me that my laptop's internal sound card only has support by ALSA in Linux. And with all the propaganda, I am worried what if ALSA makes more headway? It's already annoying that some Linux distros for example ship SDL without the OSS bindings installed, and it could get worse.

Now a friend of mind recently decided to switch to Linux because he noticed how much better it is than Windows in ways that are important to him. Since he has a newish laptop, the only drivers he could find for it are ALSA. Now for some reason, sound is really scratchy for him, and he has very limited volume controls, making him want to go back to Windows where sound works properly.

Earlier this week, another friend of mine informed me that the closed OSS has been constantly worked on since the last open sourced OSS was put into Linux years ago, can be downloaded and installed from from their website for free, and is superior to ALSA as well. It even offers ALSA emulation. This sounded interesting to me, and I headed over to the OSS website to install OSS on my friend's laptop to see if it would fix his sound problems. And lo and behold, sound is now crystal clear for him, he has much more finely tuned controls of volume, and can raise it higher than ALSA was able to. I put some research into the closed sourced OSS, and I see it has software mixing, and even software resampling which works very well. I proceeded to install it on my laptop, and now got much better sound support there as well. Only thing is that the ALSA emulation isn't working for me too well, but as I only currently have one app which is ALSA exclusive, I don't mind much, but it is annoying knowing that the previous version of this app supported OSS.

All this shows me is that ALSA is truly garbage, and a very bad idea from the ground up. If you want good sound support under Linux, the best, and sometime the only feasible option is to install the closed source OSS. With this, you always get mixing (even using the hardware mixer which ALSA doesn't always do), support for a dozen UNIX OSs, and finely tuned controls. They also made some API improvements to make it easier for application developers to do more advanced things with their audio. It's also nice to see spdif support, and even be able to send AC3 and other audio formats directly to OSS without needing to decode it first.

The real problem here being that it's closed source which makes many people for some reason step away from it. But being that the best video drivers for Linux are the closed source nVidia ones, excellent closed source sound drivers being the best doesn't surprise me. Being that I want the best possible use of my computer, and don't care for any dumb ideals, I'll take closed source drivers if they work well and don't do anything they shouldn't be doing. But this makes many distro packagers shy away from bundling or supporting the close source drivers in any way. Now while in the case of nVidia or ATI drivers, developers write apps for OpenGL or X11 which the closed source drivers support well, and it's the same API being developed for either way, we don't have to worry much if the distros don't support them. But in the case of OSS, if the distros package a completely different incompatible interface, and provide SDL and friends with everything but OSS support, we can't use the closed source drivers even if we wanted to, taking away our freedom, forcing us to put up with garbage, and defeating good portability.

We need to make a stance and stop this ALSA propaganda in its tracks, and produce many good applications with no ALSA support whatsoever and telling the propaganda spewers to go wake up. We must get the distros to keep supporting OSS. If they want a new sound system, it should be using the same API as the old one and be what every other UNIX OS uses for native sound.

Now I wish OSS would be opened sourced again, and perhaps we should be talking to 4Front about that, or recreating a full open source up to date equivalent of the closed source one, but there is no reason that we should be diverting all our efforts into a broken, incompatible, unusable, knock off.

Read here for more information about the latest closed source version of OSS and why we should be using it .

To recap, if you have sound issues, try installing the official OSS, start getting recognition going that OSS is what we're supposed to be using and that ALSA is garbage. Make sure to tell your distros that ALSA is garbage, and they should not be removing OSS support, and we should have the freedom to use a closed source driver if we want to. Tell application developers that you demand OSS support. Tell users of your application that want ALSA that ALSA is garbage, and point them to the closed source OSS if they have troubles with the open sourced one. We should also see about talking to 4Front about reopening source or updating the old open source implementation (or rewrite if need be). We should also see about making libao2 more of a library. If we took these steps, I think the state of sound in Linux, and other UNIX OSs by extension would be better off. If we took these necessary steps, UNIX sound apps wouldn't look like the laughing stock of the sound application community.

I agree. ALSA is a complete pile of junk that was chosen because of politics and not invented here syndrome. Those previous idiots who think JACK is something amazing need to get a clue too. ASIO in windows and coreaudio in osx do what JACK tries to do easier and without crashing all the time. Some people doubt that ALSA is a requirement for "serious" audio work in linux.

ossuserr
Known Member
Posts: 272
Joined: Thu Jan 08, 2015 12:01 am
Sound Card: audigy 2 zs platinum, esi juli
OS: gentu riced to bo0st
Location: Earth

Re: OSS Driver Patch for Jackd2 on Ubuntu?

Postby ossuserr » Wed Jul 01, 2015 10:32 am

Now all those communications between sound programs could be done via ip protocol and multiple computers could be used and final stream could be fed to some high quality external DAC even in wireless way. But instead of some universal way to connect all audio software to each other from any operating systems, we have those asios, jaquesds, coreaudio, multiple wrappers, wines emulators and other crap...

igorzwx
Known Member
Posts: 1258
Joined: Sun Jun 28, 2009 9:31 pm

Re: OSS Driver Patch for Jackd2 on Ubuntu?

Postby igorzwx » Wed Jul 01, 2015 12:55 pm

ossuserr wrote:Now I wish OSS would be opened sourced again, and perhaps we should be talking to 4Front about that, or recreating a full open source up to date equivalent of the closed source one


OSS is "open source" since 2007.

In July 2007, 4Front Technologies released sources for OSS under CDDL for OpenSolaris and GPL for Linux.
In January 2008, 4Front Technologies released OSS for FreeBSD (and other BSD systems) under the BSD License.
_https://en.wikipedia.org/wiki/Open_Sound_System


The source code of OSS4 is available for download here:

Get the source code using GIT:

Code: Select all

git clone git://opensound.git.sourceforge.net/gitroot/opensound/opensound

_http://www.opensound.com/


ossuserr wrote:Read here for more information about the latest closed source version of OSS and why we should be using it.


If you do not have any LynxTwo soundcard, you may not need a driver for it.
_http://manuals.opensound.com/usersguide/lynxtwo.html
_http://manuals.opensound.com/devlists/lynxtwo.html

ossuserr
Known Member
Posts: 272
Joined: Thu Jan 08, 2015 12:01 am
Sound Card: audigy 2 zs platinum, esi juli
OS: gentu riced to bo0st
Location: Earth

Re: OSS Driver Patch for Jackd2 on Ubuntu?

Postby ossuserr » Fri Jan 01, 2016 2:07 pm

In this topic http://ubuntuforums.org/showthread.php?t=2173645
the guy reports that it's possible to patch version 1.9.7 but not higher to include oss driver into the code of jackd2 and after he somehow can use the built thing with later verions: "But the good news is I used the built oss driver from this patch and applied it to the higher versions of jackd2 and it runs great when I start up jack server."
This is the patch:

Code: Select all

diff -Naur jackd2-1.9.7~dfsg/linux/wscript jj/linux/wscript
--- jackd2-1.9.7~dfsg/linux/wscript   2011-03-30 17:04:29.000000000 +0200
+++ jj/linux/wscript   2011-05-17 14:06:05.708972806 +0300
@@ -2,6 +2,8 @@
 # encoding: utf-8
 
 def configure(conf):
+    conf.env['BUILD_DRIVER_OSS'] = True
+
     conf.check_cfg(package='alsa', atleast_version='1.0.18', args='--cflags --libs')
     conf.env['BUILD_DRIVER_ALSA'] = conf.is_defined('HAVE_ALSA')
 
@@ -57,6 +59,8 @@
                        'alsa/ice1712.c'
                        ]
 
+    oss_driver_src = ['oss/JackOSSDriver.cpp', '../common/memops.c']
+
     ffado_driver_src = ['firewire/JackFFADODriver.cpp',
                         'firewire/JackFFADOMidiInput.cpp',
                         'firewire/JackFFADOMidiOutput.cpp',
@@ -67,6 +71,9 @@
     if bld.env['BUILD_DRIVER_ALSA'] == True:
         create_jack_driver_obj(bld, 'alsa', alsa_driver_src, "ALSA")
 
+    if bld.env['BUILD_DRIVER_OSS'] == True:
+        create_jack_driver_obj(bld, 'oss', oss_driver_src, "OSS")
+
     if bld.env['BUILD_DRIVER_FREEBOB'] == True:
         create_jack_driver_obj(bld, 'freebob', 'freebob/JackFreebobDriver.cpp', "LIBFREEBOB")
 
diff -Naur jackd2-1.9.7~dfsg/solaris/oss/JackBoomerDriver.cpp jj/solaris/oss/JackBoomerDriver.cpp
--- jackd2-1.9.7~dfsg/solaris/oss/JackBoomerDriver.cpp   2011-03-30 17:04:32.000000000 +0200
+++ jj/solaris/oss/JackBoomerDriver.cpp   2011-05-17 14:06:05.708972806 +0300
@@ -30,7 +30,7 @@
 #include "memops.h"
 
 #include <sys/ioctl.h>
-#include <sys/soundcard.h>
+#include "/usr/lib/oss/include/sys/soundcard.h"
 #include <fcntl.h>
 #include <iostream>
 #include <assert.h>
diff -Naur jackd2-1.9.7~dfsg/solaris/oss/JackOSSAdapter.cpp jj/solaris/oss/JackOSSAdapter.cpp
--- jackd2-1.9.7~dfsg/solaris/oss/JackOSSAdapter.cpp   2011-03-30 17:04:32.000000000 +0200
+++ jj/solaris/oss/JackOSSAdapter.cpp   2011-05-17 14:06:05.708972806 +0300
@@ -23,7 +23,7 @@
 #include "memops.h"
 
 #include <sys/ioctl.h>
-#include <sys/soundcard.h>
+#include "/usr/lib/oss/include/sys/soundcard.h"
 #include <fcntl.h>
 #include <iostream>
 #include <assert.h>
diff -Naur jackd2-1.9.7~dfsg/solaris/oss/JackOSSDriver.cpp jj/solaris/oss/JackOSSDriver.cpp
--- jackd2-1.9.7~dfsg/solaris/oss/JackOSSDriver.cpp   2011-03-30 17:04:32.000000000 +0200
+++ jj/solaris/oss/JackOSSDriver.cpp   2011-05-17 14:06:05.708972806 +0300
@@ -30,7 +30,7 @@
 #include "memops.h"
 
 #include <sys/ioctl.h>
-#include <sys/soundcard.h>
+#include "/usr/lib/oss/include/sys/soundcard.h"
 #include <fcntl.h>
 #include <iostream>
 #include <assert.h>



To apply the patch, u usually after unpacking the sorce code folder cd into that folder and give the command: patch -p1 < file.patch
To create the patch, just create a new text file named file.patch and paste the above code into it.

ossuserr
Known Member
Posts: 272
Joined: Thu Jan 08, 2015 12:01 am
Sound Card: audigy 2 zs platinum, esi juli
OS: gentu riced to bo0st
Location: Earth

Re: OSS Driver Patch for Jackd2 on Ubuntu?

Postby ossuserr » Fri Jan 01, 2016 2:15 pm

does anyone have links to source code of 1.9.7?


Return to “Linux”

Who is online

Users browsing this forum: No registered users and 4 guests