Following the kfusd patch, here is a small patch to make oss2jack work fine against jack2.
It works against jack1 already because jack1's version of jack_set_samplerate_callback() actually executes the callback function, while jack2 does not do it right away. So I followed Stephane Letz's advice and call jack_get_sample_rate() in oss2jack in jack_init() instead.
Please be aware that you may get a reject by applying due to screwed spacing. I had some funny issues with this lately (and I use emacs for source code ... weird).
------ PATCH start ------------------
--- oss2jack-0.25.orig/src/oss2jack/oss2jack.c 2009-05-18 19:57:17.757704457 +0200
+++ oss2jack-0.25/src/oss2jack/oss2jack.c 2009-05-18 20:05:04.397724051 +0200
@@ -633,7 +633,7 @@
jack_set_error_function(jack_error);
- info->client = jack_client_new("oss-dsp");
+ info->client = jack_client_open("oss-dsp", JackNullOption, NULL);
if(info->client == NULL)
{
@@ -652,6 +652,9 @@
jack_set_sample_rate_callback(info->client, jack_srate, info);
jack_set_buffer_size_callback(info->client, jack_buffer_size, info);
+ /* initialize current sample rate for jack2 at startup */
+ (void)jack_srate(jack_get_sample_rate(info->client), info);
+
jack_on_shutdown(info->client, jack_shutdown, info);
info->last_frame_size = 64;
------- PATCH end ------------------------------
Cheers!
J.
> --- On Fri, 5/15/09, Lennart Poettering <mzynq(a)0pointer.de>
> wrote:
>
> > From: Lennart Poettering <mzynq(a)0pointer.de>
> > Subject: Re: [LAD] [PATCH] kfusd against 2.6.29
> kernel
> > To: linux-audio-dev(a)lists.linuxaudio.org
> > Date: Friday, May 15, 2009, 8:29 AM
> > On Fri, 15.05.09 05:21, James Warden
> > (warjamy(a)yahoo.com)
> > wrote:
> >
> > > Hi,
> > >
> > > I created a patch for kfusd (fusd-kor kernel
> module)
> > because I
> > > needed oss2jack to work again against kernel
> 2.6.29.x
> > >
> > > I need to clean up the patch as it bulldozes the
> old
> > kernel API. If
> > > anyone is interested, I can post it here when I
> clean
> > it up (some
> > > time tonight or tomorrow). I already contacted
> the
> > author of fusd
> > > but I've got no reply so far.
> > >
> > > Note that I am no kernel guru, I got inspired by
> the
> > update to
> > > module source drm_mm.c and tested oss2jack in a
> > 2.6.29.2-rt10
> > > environment against jack1_svn (latest). I need to
> fix
> > something to
> > > make it work with jack2 (some problem linked to
> > libsamplerate -
> > > which is used in oss2jack - specifically in
> > src_process, the
> > > src_ratio field of the passed data is out of
> range).
> >
> > Please note that cuse (which does mostly the same as
> fusd)
> > is on its
> > way into the kernel:
> >
> > http://lwn.net/Articles/296388/
> >
> > Lennart
> >
> > --
> > Lennart Poettering     Â
> > Â Â Â Â Â Â Red Hat, Inc.
> > lennart [at] poettering [dot] net
> > http://0pointer.net/lennart/Â Â Â Â
> > Â Â Â GnuPG 0x1A015CC4
> > _______________________________________________
> > Linux-audio-dev mailing list
> > Linux-audio-dev(a)lists.linuxaudio.org
> > http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
> >
>
>
>
>
I completely forgot to post the kfusd patch. I understand cuse will supersede all this but some ppl out there may want to use kfusd in the mean time against kernel 2.6.29.x
I warn you, there may be cleaner way to do this but it works. Some changes might be due to some spacing or tabbing. Sorry about that. Note that I have no clue when the kernel API changed after 2.6.24. So I you try it against say 2.6.27 or 2.6.28, it may not work at all. Here it is:
Here it is:
------- PATCH start ----------------------------------
diff -Naur fusd-kor/include/kfusd.h fusd-kor-new/include/kfusd.h
--- fusd-kor/include/kfusd.h 2007-06-26 02:01:36.000000000 +0200
+++ fusd-kor-new/include/kfusd.h 2009-05-19 07:40:27.549694054 +0200
@@ -44,6 +44,7 @@
#define __KFUSD_H__
#include "fusd_msg.h"
+#include <linux/version.h>
/* magic numbers for structure checking; unique w.r.t
* /usr/src/linux/Documentation/magic-number.txt */
@@ -125,7 +126,11 @@
char *dev_name;
struct CLASS *clazz;
int owns_class;
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,29)
struct class_device *class_device;
+#else
+ struct device *class_device;
+#endif
void *private_data; /* User's private data */
struct cdev* handle;
diff -Naur fusd-kor/kfusd/kfusd.c fusd-kor-new/kfusd/kfusd.c
--- fusd-kor/kfusd/kfusd.c 2008-01-31 22:38:53.000000000 +0100
+++ fusd-kor-new/kfusd/kfusd.c 2009-05-19 07:40:36.412703934 +0200
@@ -85,7 +85,7 @@
#define STATIC
/* Define this if you want to emit debug messages (adds ~8K) */
-#define CONFIG_FUSD_DEBUG
+/* #define CONFIG_FUSD_DEBUG */
/* Default debug level for FUSD messages. Has no effect unless
* CONFIG_FUSD_DEBUG is defined. */
@@ -126,8 +126,17 @@
#else
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,29)
+
#define CLASS_DEVICE_CREATE(a, b, c, d, e) class_device_create(a, b, c, d, e)
+#else
+
+#define CLASS_DEVICE_CREATE(a, b, c, d, e) device_create(a, b, c, d, e)
+#define class_device_destroy(a, b) device_destroy(a, b)
+
+#endif
+
#endif
#endif
@@ -150,8 +159,13 @@
static struct CLASS *fusd_class;
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,29)
static struct class_device *fusd_control_class_device;
static struct class_device *fusd_status_class_device;
+#else
+static struct device *fusd_control_class_device;
+static struct device *fusd_status_class_device;
+#endif
extern struct CLASS *sound_class;
@@ -725,8 +739,10 @@
/* fill the rest of the structure */
fusd_msg->parm.fops_msg.pid = current->pid;
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,29)
fusd_msg->parm.fops_msg.uid = current->uid;
fusd_msg->parm.fops_msg.gid = current->gid;
+#endif
fusd_msg->parm.fops_msg.flags = fusd_file->file->f_flags;
fusd_msg->parm.fops_msg.offset = fusd_file->file->f_pos;
fusd_msg->parm.fops_msg.device_info = fusd_dev->private_data;
@@ -1533,6 +1549,7 @@
}
static void fusd_client_mm_open(struct vm_area_struct * vma);
static void fusd_client_mm_close(struct vm_area_struct * vma);
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,29)
static struct page* fusd_client_nopage(struct vm_area_struct* vma, unsigned long address, int* type);
static struct vm_operations_struct fusd_remap_vm_ops =
{
@@ -1540,6 +1557,16 @@
close: fusd_client_mm_close,
nopage: fusd_client_nopage,
};
+#else
+static int fusd_client_fault(struct vm_area_struct* vma, struct vm_fault *vmf, int* type);
+static struct vm_operations_struct fusd_remap_vm_ops =
+{
+ .fault = fusd_client_fault,
+ .open = fusd_client_mm_open,
+ .close = fusd_client_mm_close,
+};
+#endif
+
struct fusd_mmap_instance
{
@@ -1631,13 +1658,14 @@
return -EPIPE;
}
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,29)
static struct page* fusd_client_nopage(struct vm_area_struct* vma, unsigned long address,
int* type)
{
struct fusd_mmap_instance* mmap_instance = (struct fusd_mmap_instance*) vma->vm_private_data;
unsigned long offset;
- struct page *page = NOPAGE_SIGBUS;
int result;
+ struct page *page = NOPAGE_SIGBUS;
offset = (address - vma->vm_start) + (vma->vm_pgoff << PAGE_SHIFT);
// todo: worry about size
if(offset > mmap_instance->size)
@@ -1662,9 +1690,46 @@
}
out:
return page;
+}
+#else
+static int fusd_client_fault(struct vm_area_struct* vma, struct vm_fault *vmf,
+ int* type)
+{
+ struct fusd_mmap_instance* mmap_instance = (struct fusd_mmap_instance*) vma->vm_private_data;
+ unsigned long offset;
+ int result;
+ struct page *page = NULL;
+ offset = ((unsigned long)vmf->virtual_address - vma->vm_start) + (vma->vm_pgoff << PAGE_SHIFT);
+ // todo: worry about size
+ if(offset > mmap_instance->size)
+ goto out;
+
+ down_read(&mmap_instance->fusd_dev->task->mm->mmap_sem);
+ result = get_user_pages(mmap_instance->fusd_dev->task, mmap_instance->fusd_dev->task->mm, mmap_instance->addr + offset, 1, 1, 0, &page, NULL);
+ up_read(&mmap_instance->fusd_dev->task->mm->mmap_sem);
+
+
+ if(PageAnon(page))
+ {
+ RDEBUG(2, "Cannot mmap anonymous pages. Be sure to allocate your shared buffer with MAP_SHARED | MAP_ANONYMOUS");
+ return VM_FAULT_SIGBUS;
+ }
+
+ if(result > 0)
+ {
+ get_page(page);
+ vmf->page = page;
+ if (type)
+ *type = VM_FAULT_MINOR;
+ }
+out:
+ return 0;
}
+#endif
+
+
/*
----- PATCH end ----------------------------------
Cheers!
J.
> --- On Fri, 5/15/09, Lennart Poettering <mzynq(a)0pointer.de>
> wrote:
>
> > From: Lennart Poettering <mzynq(a)0pointer.de>
> > Subject: Re: [LAD] [PATCH] kfusd against 2.6.29
> kernel
> > To: linux-audio-dev(a)lists.linuxaudio.org
> > Date: Friday, May 15, 2009, 8:29 AM
> > On Fri, 15.05.09 05:21, James Warden
> > (warjamy(a)yahoo.com)
> > wrote:
> >
> > > Hi,
> > >
> > > I created a patch for kfusd (fusd-kor kernel
> module)
> > because I
> > > needed oss2jack to work again against kernel
> 2.6.29.x
> > >
> > > I need to clean up the patch as it bulldozes the
> old
> > kernel API. If
> > > anyone is interested, I can post it here when I
> clean
> > it up (some
> > > time tonight or tomorrow). I already contacted
> the
> > author of fusd
> > > but I've got no reply so far.
> > >
> > > Note that I am no kernel guru, I got inspired by
> the
> > update to
> > > module source drm_mm.c and tested oss2jack in a
> > 2.6.29.2-rt10
> > > environment against jack1_svn (latest). I need to
> fix
> > something to
> > > make it work with jack2 (some problem linked to
> > libsamplerate -
> > > which is used in oss2jack - specifically in
> > src_process, the
> > > src_ratio field of the passed data is out of
> range).
> >
> > Please note that cuse (which does mostly the same as
> fusd)
> > is on its
> > way into the kernel:
> >
> > http://lwn.net/Articles/296388/
> >
> > Lennart
> >
> > --
> > Lennart Poettering     Â
> > Â Â Â Â Â Â Red Hat, Inc.
> > lennart [at] poettering [dot] net
> > http://0pointer.net/lennart/Â Â Â Â
> > Â Â Â GnuPG 0x1A015CC4
> > _______________________________________________
> > Linux-audio-dev mailing list
> > Linux-audio-dev(a)lists.linuxaudio.org
> > http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
> >
>
>
>
>
Hi All,
After hours of discussion on #jack IRC, it seems that we are in a
completely blocked situation:
1) we currently have 2 "incarnations" of the jack server named "jackd"
and "jackdbus". "jackd" is the legacy "classic" version of the server
that interact with the ~/jackdrc setting file. This setting file may
be written by Qjackctl or Ardour. "jackdbus" is the new D-Bus aware
version of the server, it use a completely new setting management
system using a "conf.xml" file. Il may use a multi-setting system in
the future.
2) the *heart" of the problem Fons initially told about is in the way
applications "auto-start" the server. This launching strategy is part
of libjack and depends of the incarnation of the server (jackd of
jackdbus) that is supposed to be used. Right now this strategy is
chosen at *compile time*, so that in "classic" mode the "jackd" server
will be launched using a fork-exec strategy, or in D-Bus mode the
"jackdbus" server will be launched by issuing a D-Bus call.
3) Since the "auto-start" strategy is chosen at compile time and thus
is coded in libjack, users will typically encounter all sort of
problems as soon as the used applications interact with a "D-Bus based
strategy" libjack (that will launch "jackdbus" incarnation) and users
still use Qjackctl that interact with the "jackd" incarnation.
4) Different ideas have been proposed to merge the 2 "jackd" and
"jackdbus" incarnations in a unique extended "jackd" exe, but nothing
really clear emerged.
4) A possible proposed solution was to define 2 completely separated
packages for jack2 : the "classic" one would package the "jackd"
incarnation and allow Qjackctl and legacy control applications to be
used with it. The "D-Bus" one would package the "jackdbus"
incarnation, and provide D-Bus bas control applications (patchage,
ladi tools....). The problem of this strategy is that..., it is a kind
of complete failure regarding the way jack is supposed to be
distributed. It may even get worse if a new "jackosc" incarnation (a
one that would allow to control the server using OSC) appears a some
point in the future...
5) Another idea would be improve the "choice of auto-start strategy"
by providing a runtime choice for that: a way for the user to select
between the "classic", "D-Bus", "OSC", strategy once globally for a
given working session...
5) Another idea would be be to completely drops the "auto-start"
strategy...This way we don't have multiple strategy anymore, and solve
most of the problems... but loose a feature.
Comments?
Stephane
Hi all
I have a question about the useage from the jack_ringbuffer for midi
out_put. I'am unsure to use it or not ? Can someone tell me what is the
advance when I use it, in relation to write direct to the port_buffer ?
In witch case do you prefer the ringbuffer, in witch case do you prefer
the direct use of the port_buffer ?
Witch one is the one with lesser useage from CPU and mem ?
I try to figure that out, but I didn`t come to a clear result witch one
is the one to use.
regards
hermann
Dear,
The FFADO team is happy to announce the release of the second release
candidate for FFADO 2.0.
It has been 6 months since we released FFADO 2.0 Release Candidate 1,
and we have to admit that this is quite long. The usage statistics show
that about 300 people have been using RC1 in this period, and the good
news is that we did not get a lot of bug reports. Most of the reports
filed were related to crappy host controller hardware (most notably the
Ricoh controllers), which is something we unfortunately cannot fix. In
the mean time the remaining bug reports have been fixed, so here we are
again.
This release candidate contains a few reliability improvements and
bugfixes that should get some field testing before we can release the
official 2.0. I would therefore like to ask all users and packagers to
upgrade as soon as possible such that we can release sooner rather than
later. If we get to about 100 registered users without significant
significant bug reports I feel confident that we're good to go. So happy
testing!
To indicate that we're quite busy even though we don't put out a lot of
announcements let me give you a sneak preview of what is under
development for post-2.0 ...
First of all 2.1 will contain support for extra devices:
* The first device to take full advantage of our DICE platform
support will be the Focusrite Saffire PRO40. The platform based
audio and MIDI streaming is fully functional. The custom mixer
functionality is currently being alpha-tested.
* The DICE platform support also enables the basic use of the
TC Electronic Konnekt 8, 24D and Live. Support for these devices
is limited to streaming (no DSP effects). Currently it doesn't
look like the DSP is going to be supported any time soon.
* Support for the Behringer FCA-202 has been added.
* Support for the Stanton SCS.1 series is added. Support for both
the audio I/O as the HSS1394 control surface protocol has been
implemented, meaning that these devices are fully functional.
We keep on talking to several device vendors to increase our device
support, and we will most likely be announcing some new devices in the
near future.
The second major development is the move of the streaming infrastructure
to kernel space. Thanks to the Google Summer of Code and the Linux
Foundation, we have somebody working on this during the summer. A
kernel-space implementation will bring significant improvements with
respect to reliability and efficiency. Furthermore it will expose an
ALSA interface, meaning that the scope of FireWire audio is extended
significantly.
The following changes have been made:
* Various packaging improvements and cosmetic fixes.
* Improved the Edirol FA101 mixer
* While the streaming engine is running, prevent mixer changes that
result in aborted streaming
* Add status bar logging to the mixer window
* Install a service-file if possible
* Add command rate control for the Saffire devices to reduce the issues
with mixer actions messing up audio.
* Fix Terratec Phase88 mixer
* Implement mixer support for the MOTU UltraLite
* Improve mixer support for the MOTU 896HD
* Add a minimum for the packetsize parameter for very low
channel-count devices
* Fix handling of MIDI 2x and 3x mode
* Improve the jitter performance of the timestamping
* Reduce CPU usage
* Fix the bug that prevented jackd from exiting freewheeling mode
* Introduce transmit prebuffering to increase reliability with small
period sizes
* MOTU: Fix bug related to disabled (unused) audio channels
* Introduce support for driver parameters in the config file
* Ensure that the order specified in the specification string when
aggregating devices is honored.
* Ensure that libffado.so is properly versioned (SONAME) and installed
* Add a firmware version check for ECHO Fireworks based devices
* Add a firmware version check for Terratec Phase88 devices
* By default the library is compiled with debugging turned off
More information can be found here:
http://www.ffado.org/?q=node/1031
For the eager, a direct download link:
http://www.ffado.org/files/libffado-2.0-rc2.tar.gz
On behalf of the FFADO team,
Pieter Palmers
cool :)
Is it already in the kernel code baseline ?
J.
--- On Fri, 5/15/09, Lennart Poettering <mzynq(a)0pointer.de> wrote:
> From: Lennart Poettering <mzynq(a)0pointer.de>
> Subject: Re: [LAD] [PATCH] kfusd against 2.6.29 kernel
> To: linux-audio-dev(a)lists.linuxaudio.org
> Date: Friday, May 15, 2009, 8:29 AM
> On Fri, 15.05.09 05:21, James Warden
> (warjamy(a)yahoo.com)
> wrote:
>
> > Hi,
> >
> > I created a patch for kfusd (fusd-kor kernel module)
> because I
> > needed oss2jack to work again against kernel 2.6.29.x
> >
> > I need to clean up the patch as it bulldozes the old
> kernel API. If
> > anyone is interested, I can post it here when I clean
> it up (some
> > time tonight or tomorrow). I already contacted the
> author of fusd
> > but I've got no reply so far.
> >
> > Note that I am no kernel guru, I got inspired by the
> update to
> > module source drm_mm.c and tested oss2jack in a
> 2.6.29.2-rt10
> > environment against jack1_svn (latest). I need to fix
> something to
> > make it work with jack2 (some problem linked to
> libsamplerate -
> > which is used in oss2jack - specifically in
> src_process, the
> > src_ratio field of the passed data is out of range).
>
> Please note that cuse (which does mostly the same as fusd)
> is on its
> way into the kernel:
>
> http://lwn.net/Articles/296388/
>
> Lennart
>
> --
> Lennart Poettering     Â
> Â Â Â Â Â Â Red Hat, Inc.
> lennart [at] poettering [dot] net
> http://0pointer.net/lennart/Â Â Â Â
> Â Â Â GnuPG 0x1A015CC4
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev(a)lists.linuxaudio.org
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
>
Hi,
I created a patch for kfusd (fusd-kor kernel module) because I needed oss2jack to work again against kernel 2.6.29.x
I need to clean up the patch as it bulldozes the old kernel API. If anyone is interested, I can post it here when I clean it up (some time tonight or tomorrow). I already contacted the author of fusd but I've got no reply so far.
Note that I am no kernel guru, I got inspired by the update to module source drm_mm.c and tested oss2jack in a 2.6.29.2-rt10 environment against jack1_svn (latest). I need to fix something to make it work with jack2 (some problem linked to libsamplerate - which is used in oss2jack - specifically in src_process, the src_ratio field of the passed data is out of range).
Cheers!
J.