Felipe Sateler <fsateler(a)gmail.com> writes:
> Stéphane Letz wrote:
>
>> My feeling is that is we choose the runtime auto-start strategy, then
>> we should not mix anything concerting setting management
>
> This sounds weird to me. There should be only one canonical configuration
> file for jack, independent of how it was started.
What canonical means? Something achieved through massacre? Or something
achieved through evolution?
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
Le 18 mai 09 à 16:35, Paul Davis a écrit :
> On Mon, May 18, 2009 at 10:25 AM, MarcO'Chapeau <marco(a)marcochapeau.org
> > wrote:
>> On Mon, 18 May 2009 17:36:11 +0400, alex stone
>> <compose59(a)gmail.com> wrote:
>>> Marc,
>>> hehe, and the waltz continues. So let's assume that pulse isn't
>>> being
>>> considered here as part of the dbus paradigm intent .
>>
>> Hi again.
>>
>> Ok, let's stop dancing then :) Let me try to explain that dbus here
>> is not
>> the center of what has changed in JACK2.
>
> i'm just going to trying to summarize even more from what Marc has
> said. There are two issues that have become tangled up in this recent
> email flurry.
>
> 1) the current D-Bus support can be mishandled by packagers and this
> can lead to problems for some users
> 2) the only actual implementation that uses the control API is based
> on D-Bus, and this is not a source of happiness and cake for everyone.
>
> There is nothing stopping other implementations (pure C, OSC, python
> etc) using the control API, but at this time, nothing else does.
> Stephane has attempted to correct problem (1) in svn with warnings
> etc. to packagers.
>
> --p
Some more words about that:
JACK2 SVN makes now clear what can be built:
- "classic" JACK : this target compiles the "jackd" executable. This
exe behaves exactly as JACK1 is behaving (beside possible bugs). This
target is the *default* one (that is the one resulting from "./waf
configure). This version is meant to be used with usual tools
Qjackctl, Ardour... (to start the server)... and so on.
- D-Bus JACK: this target compiles the "jackdbus" executable *only*
(that is the "jackd" is not compiled anymore). This target is obtained
using --dbus at configure time. This version is meant to be controled
with D-Bus based control applications (Nedko please clarify this
point...)
- both targets can be mixed but a WARNING is issued at configure time;
that is "./waf configure --dbus --classic" will compile both "jackd"
and "jackdbus" executable. This is to be done only by people who know
exactly what they are doing.
Packagers are then strongly recommended to prepare the "classic" or
the "D-Bus" JACK2. Dependancies have to be handled accordingly (Nedko
please clarify this point...)
The "mixed" target should *not be used* for packaging.
(see http://trac.jackaudio.org/wiki/JackDbusPackaging)
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.
What is the rationale for jackd requiring buffers to have number of
frames set to a power of 2? Could this be relaxed to perhaps a multiple
of 16, 32 or somesuch?
I have a few reasons for wanting to do so
a) Neither 128 nor 64 matches a samplerate of 96K and 1ms between USB
midi messages. 96 would.
b) CUDA (Nvidias gpgpu language) appears to have some magic regarding
192 threads that seems to work most fluently. This also happens to be a
multiple of 96 opening up for some programming efficiency advantages
when threadID equals [a multiple of] frame index.
c) Although certainly possible, 256 parallel "moog"-filters is a bit
overdoing it, no? IMHO, once a multichannel polysynth goes beyond 96
voices (in this case with two filters - one left, one right - per voice
== 192 threads) the experienced return of improved quality/complexity is
diminishing steeply, getting lost in the mix. I'd much rather spend more
clockcycles on, say post-processing of channels - or more room for a
simultanious video stream.
Howdy!
Simple as it could be,
Qsynth 0.3.4 released!
Description:
Qsynth is a fluidsynth GUI front-end application written in C++ around
the Qt4 toolkit using Qt Designer. Eventually it may evolve into a
softsynth management application allowing the user to control and manage
a variety of command line softsynth but for the moment it wraps the
excellent FluidSynth. FluidSynth is a command line software synthesiser
based on the Soundfont specification.
Website:
http://qsynth.sourceforge.net
Project page:
http://sourceforge.net/projects/qsynth
Download:
http://downloads.sourceforge.net/qsynth/qsynth-0.3.4.tar.gz
Weblog:
http://www.rncbc.org
License:
Qsynth is free, open-source software, distributed under the terms of
the GNU General Public License (GPL) version 2 or later.
Change-log:
- Command line option parsing has been slightly refactored to allow
custom override through extraordinary fluidsynth option settings (eg. -o
name=value; fixes bug #2781579).
- Main form layout has been given a little bit more slack space, just
to accommodate some longer text label translations (eg. German).
- Converted obsolete QMessageBox forms to standard buttons.
- Saved channel presets are now effectively loaded on engine startup.
- Russian translation added (thanks to Alexandre Prokoudine).
- Grayed/disabled palette color group fix for dark color themes.
- Qt Software logo update.
- Fait-divers: desktop menu file touched to openSUSE conventions.
- Slight optimizations to the output peak meters refresh rate.
- MIDI and audio device names are now user selectable options through
respective drop-down lists on each engine setup dialog.
- New knob style: Skulpture.
Cheers && Enjoy!
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
(Also posted over at the SDL mailing list; <sdl(a)libsdl.org>.)
Hi!
My son is playing around with my little SDL based drum machine, DT-42
again. He seems to be having fun, but I suppose he'd be better off
with something more straight-forward (DT-42 is more like a MOD
tracker than a conventional drum machine), and something with more
obvious ways of creating melodies... At least, that's what I'd
like! :-D
This brings up some thoughts I've been having for years now: A really
simple, yet somewhat useful and educational music toy. An integrated
synth/sampler/sequencer, possibly with audio recording facilities
down the road... Sort of like a tracker (Amiga MOD style), but with a
more visual GUI. Probably some sort of piano roll. A bunch of nice
sounds (I'm thinking IFFT synthesis) with some pre-wired intuitive
timre controls. Maybe a library of drum patterns... Preferably SDL
based and portable to all sorts of computers and devices.
In short: Tux Paint for music! :-)
Is there something like this already out there?
Any interest in this sort of stuff?
Ideas?
I'll probably use EEL for all high level code, over a C engine. EEL is
probably not the most sensible choice for a Free/Open Source project,
but I'm using EEL for various stuff myself (mostly work related), and
it could use some more pilot projects to guide future development.
URLs:
Tux Paint: http://www.tuxpaint.org/
DT-42: http://olofson.net/mixed.html
EEL: http://eel.olofson.net/
--
//David Olofson - Programmer, Composer, Open Source Advocate
.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
'-- http://www.reologica.se - Rheology instrumentation --'
