Hi all,
New much simplified proposal, should be "Fons compatible", hopefully
"Nedko compatible" (with little work), "Paul one package only
compatible", others "keep it simple compatible"...
The first "big" conceptual change compared to the current SVN state is
this new "control IPC" scheme. That is the so called control API can
be used on client side also. The other conceptual change is that
"jackd" process is supposed to be an "always running" daemon that
defines an IPC entry point to be used from "clients". This daemon does
not "automatically" starts the server (as it does now), but will when
requested (either by the "jackd" code directly using C API ) or by the
request of external control font-end using IPC.
1) Server side:
- libjackserver.so contains: server code + C control API + "new" IPC
control API (server side) + C Jack API + IPC Jack API (server side)
- jackd executable is linked with libjackserver.so (nothing new here)
- backends (ALSA, dummy...) are linked with libjackserver.so (nothing
new here)
- a "standalone" client (that wants to embed the server in it's
process) is linked with libjackserver.so and directly uses the C
control API to control/start the server and C Jack API to be a client
(nothing new here).
2) Client side:
- libjack.so contains : "new" IPC control API (client side) + IPC
Jack API (client side)
- clients are linked to libjack.so (nothing new here)
- new control front-end (jackdbus, jackOSC...) are linked to
libjack.so: they control the server using the IPC control API (client
side), they can be regular clients using IPC Jack API (client side) to
deal with connections management and so on...
- a "default" centralized state for the server is always kept in ~/
jackdrc. When a client wants to auto-start, this "default" state is
used. (this is important to keep in mind)
- libjack may have to start the "jackd" executable using the fork+exec
way, or the "jackd" process is an "always running + relaunch" process
(this has to be more defined later on...)
- Qjakctl stays as a regular client, it can still start the "jackd"
process as usual. It can keep its own way of keeping multiple
configurations as it does now.
- more sophisticated control front-end (jackdbus, jackOSC...) are now
regular clients. They can use the IPC control API (client side) for
more sophisticated control of the server. As regular clients, they
access the API to control connections... and so on. The important
thing is that those clients are *obliged* to deal with this "default"
centralized state. Even if they deal with multiple configs in a new
format (XML...) they are supposed to always put a "default" state in
~/jackdrc for the client "auto-start" feature to continue working.
- Ardour can still do it's server control mess on its own... ((-:
3) General:
- a single jack2 package is needed. It contains the "jackd" daemon/
server are before.
- "jackdbus" is now conceptually separated from the Jack source code.
It only uses jack.h + control.h and is linked to libjack.so as any
regular client. It can be distributed separately as a more
sophisticated control front-end available, or be available in the
jack2 package.
- old fashion users can keep their habits
- new "D-Bus aware" guys can explore new fields...
This scheme seems to hopefully solve most of the problems we had, and
requires only a bit of change for the "jackdbus" front-end to continue
working, but not much.
Comments?
Stephane
Heya!
I am currently working on the volume control handling of
PulseAudio. Until now the sliders in the UI mapped their position
linearly to the dB volume scale. i.e. if the slider is at '0%' we get
-90dB, if it is at '100%' we get 0dB, and between that we map linearly
from those percentages to the dB value. To be frank, this sucked big
time because the 'interesting' part is usually way up at -10dB to
0dB. and the remaining part of the volume sliders is pretty boring.
>From reading through the ALSA drivers I know that a lot of sound card
mixer controls usually have a much higher dB resolution near 0dB then
the have near -90dB. Most of the time the steps they choose are very
arbitrary however.
So, I was looking for better suggestions for mapping 'pixel
distances' in the UI to volume factors. I googled a bit and found this:
http://www.robotplanet.dk/audio/audio_gui_design/
Which suggests a cubic relation between 'pixel distances' and the
linear factor.
Any opinions on that? Other suggestions?
Thanks,
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
He all,
A picture to try summary what I understand about we would like :
- a new shared library called "libjackontrol.so" : is does implement
the so called control API and a IPC mechanism to use it.
- "jackcontrol" is an *always" running deamon that defined an entry
IPC point. jackcontrol get requests from control applications.
"jackcontrol" can start a seprated server called "jackserver (using a
fork+exec) way. "jackcontrol" is a *unique* place where setting are
handled.
- "jackd" is a recoded control application that parse it's command
line, and use the control IPC to speak to "jackcontrol" (then just
quits). jackcontrol then start the "jackserver" whith the appropriate
paramaters.
- "jackddbus" is a D-Bus aware control application; It receive DBus
requests and translate them to control IPC to speak to "jackcontrol".
jackcontrol then start the "jackserver" whith the appropriate paramaters
- "libjack.so" speaks also to "jackcontrol" using the control IPC: an
client that auto-start actually use this mecanism
Does it helps?
Stephane
To whom it may concern: (again)
Jackdmp 1.9.2, Qjackctl 0.3.4
I do the following:
- Log in.
- Start a jack app.
- The app starts jackd, but using the wrong card,
and things don't work as expected.
Questions:
1. Which parameters are used for such an autostart ?
Certainly not the ones in ~/.jackdrc, these would
have been correct.
2. Qjackctl also ignores ~/.jackdrc, so what is the
purpose of this file ?
- I terminate the app. Check with ps, there is no
more jackd running.
- I start qjackctl. It immediately shows a running
jackd, but his has restarted the previous wrong one.
- Click Stop, Start in qjackctl. Get the same wrong
jackd again.
- Verify qjackctl's Setup window. This shows the
settings for the right jackd, while it is running
another one.
This is *madness*
One more: you can't terminate qjackctl without
terminating jackd as well. Why not ? Killing
qjackctl does the right thing.
A request to the jackdmp and qjackctl devs:
PLEASE REMOVE THAT DBUS MADNESS
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
I am looking to put together a line array speaker system and I would
like to experiment with with adjusting the focus with dsp. I looked at
the AES article about WFSfocus by Fons Adriaensen and it looks like
this could be used and it also looks like ambdec could be adopted by
changing the filters. I plan to have a stereo pair of 8 woofer tweeter
combinations per side
Does anyone know if WFsfocus is available or suggestions for adopting
ambdec. Or if this is even feasable
Tom Brooke
that's my point: there's no point in checking the pointer validity after you pass it as an argument to a 3rd party function ;)
I believe Hermann just made a quick hack last night and he got things cleaned up at last :)
Cheers,
J.
--- On Sun, 5/24/09, Fons Adriaensen <fons(a)kokkinizita.net> wrote:
> From: Fons Adriaensen <fons(a)kokkinizita.net>
> Subject: Re: [LAD] [ANN] guitarix-0.04.4-1 release
> To: linux-audio-dev(a)lists.linuxaudio.org
> Date: Sunday, May 24, 2009, 9:48 AM
> On Sun, May 24, 2009 at 05:36:49AM
> -0700, James Warden wrote:
>
>
> > I think any jack function will check if the client
> pointer passed
> > as an argument is valid so it is safe to call
> jack_get_buffer_size
> > before checking the client pointer validity.
>
> Probably (didn't check) Jack will survive, but don't
> expect a valid return value if your client* is bogus.
> What's the point of doing this ?
>
> Ciao,
>
> --
> FA
>
> Io lo dico sempre: l'Italia è troppo stretta e lunga.
>
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev(a)lists.linuxaudio.org
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
>
Hi Hermann,
Great, I tested it against jack1 and jack2, and it is working fine now :)
I looked at your additions. I have a couple of comments, nothing you should consider as important or critical:
- guitarix.cpp, line 529-530:
I think any jack function will check if the client pointer passed as an argument is valid so it is safe to call jack_get_buffer_size before checking the client pointer validity. However, I have the habit of checking pointer validity before passing it to a 3rd party function. You never know, when the 3rd party lib is closed-source and its API badly documented, you may get crashes. It's not the case here so you can keep it like that.
- guitarix.cpp, line 570-579: I would create a local function for this block of code because you call it in some other place as well. You will have only one place to maintain and gain more control on the variation of gNumOutChans. Turn it into:
if (merke == 0)
{
gtx_unregister_ports();
}
- german looking variable names: I have nothing against german, even learned it at school :D but it's open-source, not open-german-source ;)
- I would also formalize a bit more what is guitarix's code so someone can tell right away which is your code and which is not. For example, start all your home made standalone functions with gtx_ (for GuiTariX)
For home made classes, GtxSomeClass
For class members of home made classes: fGtxSomeMember
For class methods of home made classes: gtxSomeMethod()
This will become much more readable.
You don't have to though, and cleaning up is a bit of a tedious job ... but if it is to grow as you add more functionality, keep this in mind :)
Thanks for your work, I heard that you had to spend quite some time last night to make my patch fit in for jack1 ;)
Tschuess :)
J.
--- On Sun, 5/24/09, hermann meyer <brummer-(a)web.de> wrote:
> From: hermann meyer <brummer-(a)web.de>
> Subject: Re: [LAD] [ANN] guitarix-0.04.4-1 release
> To: warjamy(a)yahoo.com
> Cc: linux-audio-dev(a)lists.linuxaudio.org
> Date: Sunday, May 24, 2009, 2:17 AM
> Am Samstag, den 23.05.2009, 05:04
> -0700 schrieb warjamy(a)yahoo.com:
> > discussion started at LAD about changing the jack
> server latency from the app called guitarix (like ardour
> does from its menu JACK -> Latency). Proposed guitarix
> patch (by me) works nice against jack2 but not against
> jack1. See below.
> >
> > Hermann,
> >
> > I quickly ran guitarix in debug mode through gdb. You
> get a crash at dsp_audio.cpp, line 469. Looks like memory at
> output[2] and output[3] cannot be accessed. I tried to
> understand what you attempt to do but this function
> (mydsp::compute) is way to much for me to understand. It
> looks like some sort of auto-code ...
> >
> > Anyway, output[2] and output[3] are passed in from
> process() (process callback function). I believe these
> arrays should correspond to buffers that you receive from
> jack audio ports 2 and 3. However, at the time we try to
> change the latency, they are already unregistered because of
> DSP.setNumOutputs().
> >
> > So it looks to me that resetting the jack buffer size
> on the fly from guitarix badly interacts with how jack1
> handled your port deregistration requests. I don't know why
> it works with jack2. Running guitarix through gdb against
> jack2, I could see that output[2] and output[3] were still
> valid memory locations after changing the jack buffer size
> on the fly.
> >Â Â Â
> > This is a bit unfortunate that we get different
> behaviors when using jack1 or jack2. I hope you'll sort it
> out, I don't have more time to spend on it.
> >
> > J.
> >
> Morning James
>
> So I got it working. Your Code is submit to SVN with some
> little
> additions. Thanks James, that is the "first direct code
> contribution"
> the guitarix projekt recive, I hope more will follow. :D
>
>
>
discussion started at LAD about changing the jack server latency from the app called guitarix (like ardour does from its menu JACK -> Latency). Proposed guitarix patch (by me) works nice against jack2 but not against jack1. See below.
Hermann,
I quickly ran guitarix in debug mode through gdb. You get a crash at dsp_audio.cpp, line 469. Looks like memory at output[2] and output[3] cannot be accessed. I tried to understand what you attempt to do but this function (mydsp::compute) is way to much for me to understand. It looks like some sort of auto-code ...
Anyway, output[2] and output[3] are passed in from process() (process callback function). I believe these arrays should correspond to buffers that you receive from jack audio ports 2 and 3. However, at the time we try to change the latency, they are already unregistered because of DSP.setNumOutputs().
So it looks to me that resetting the jack buffer size on the fly from guitarix badly interacts with how jack1 handled your port deregistration requests. I don't know why it works with jack2. Running guitarix through gdb against jack2, I could see that output[2] and output[3] were still valid memory locations after changing the jack buffer size on the fly.
Â
This is a bit unfortunate that we get different behaviors when using jack1 or jack2. I hope you'll sort it out, I don't have more time to spend on it.
J.
PS: by the way, be careful with hardcoded values. On one hand you have gNumOutChans (= 4), on the other you have arrays declared with [4].
--- On Sat, 5/23/09, hermann meyer <brummer-(a)web.de> wrote:
> From: hermann meyer <brummer-(a)web.de>
> Subject: Re: [LAD]Â [ANN] guitarix-0.04.4-1 release
> To: "James Warden" <warjamy(a)yahoo.com>
> Cc: linux-audio-dev(a)lists.linuxaudio.org
> Date: Saturday, May 23, 2009, 2:24 AM
> Am Freitag, den 22.05.2009, 09:07
> -0700 schrieb James Warden:
> > Hermann,
> >
> > I added a Latency menu to guitarix. You can now change
> the jack server latency on the fly from guitarix (a la
> ardour). See patches below:
> >
> > ---------
>
> Hi James
>
> Many thanks, it's real welcome, but unfortunatly I
> experience a lot of
> chrash's with your patch added.
> I work (at time) with jackd, not jackdmp, and guitarix
> recive often a
> wrong(NULL) pointer after change the buffer size and
> chrash'd, also,
> when jackd cant set the selected buffersize, jackd
> chrash'd.
> So here is a proper errorhandling needed.
>
> Anyway, I have include the jack_set_buffer_size_callback,
> to recreate
> the intern buffer's from guitarix, when the buffersize
> change, so that
> guitarix can handle a buffersize change (currently not
> commit).
>
> I did'nt have check it with jackdmp, did it work for you
> without
> experience some chrash's ?
>
> regards
> Â Â Â Â Â Â hermann
>
>