Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

3 participants
7536 discussions

by Ulrich Lorenz Schlüter

On my system the location of some headers changed. For example /usr/include/lash/lash.h changed to /usr/include/lash-1.0/lash/lash.h. Are the headers in the wrong place or is there a link missing or do I have to change my #includes? Thanks and regards Uli

16 years, 8 months

[LAD] New proposal for the jackd/jackdbus mess

by Stéphane Letz

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

16 years, 8 months

[LAD] Presenting volume control sliders

by Lennart Poettering

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

16 years, 8 months

[LAD] A picture...of the global mess

by Stéphane Letz

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

16 years, 8 months

[LAD] Keeping "guardians" and "rebels" on the same boat

by Stéphane Letz

Hi all, I would be happy to get some reactions of this proposal that tries to keep the "guardians" and the "rebels" on the same boat. The pdf file for this proposal is : http://www.grame.fr/~letz/jackcontrol2.pdf. Compared to latest Fons proposal, this proposal basically combine the "control daemon" and the "jackd" server in a *unique* extended jackd (with control API IPC) (see 5). It also tries to minimize the number of shared libraries in the system, although we may decide to break-up the code in separated libraries if this is really needed (see 3). Concerning Torben proposal to have "control plug-ins" be part of the server, I agree with Fons here: this would be quite limited and more complex: a new interface would have to be defined, "who" is loading those plug-ins in the server... and so on. Let me explain it again: 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 point is this concept of "multi- config share state" (see 3). 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) + config API (TO BE DEFINED) - 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. 3) Centralized multi-settings share state - the idea is to provide a way to *share* multiple server configurations in a unique place for all control applications. This is part the D-Bus proposal in some sense. WE HAVE TO DECIDE IF WE WANT THIS FEATURE BE PART OF JACK OR NOT (this can be coded as part of libjack.so or in a separated library called "libjackconfig.so" is we need to share this code between the sever and client side). - If we don't share a unique state, then any control application (jackdbus or any other in the future) will have the choice to use any format (XML...) but then obviously we loose the fact that all control applications would always see the same settings. 4) General: - a single jack2 package is needed. It contains the "jackd" daemon/ server as before. - "jackdbus" is now conceptually separated from the Jack source code. It only uses jack.h + control.h + config.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. 5) Points of discussion: - this model is somewhat simplified compared to the latest Fons proposal (a daemon process + [possibly] several separated jackd servers). The point is that separated processes for control daemon and jackd servers would need another mechanism for "control daemon" <===> jackd server communications (that is: the control daemon launches the jackd server, but then has to control it while it is running, possibly get some info from it (notifications.. etc..)). If we stay with a unique "extended jackd" (with control API IPC), then things are a lot simpler. We can consider that having a single running jackd server is a common case and having several running jackd server a "corner case". It we decide that several running jackd servers is really necessary, then the "extended jackd" can still handle the situation if we accept to have several jackd servers running in a same process. Otherwise a more complex model for "completely separated control daemon and several jackd servers" has to be defined. - multi-config stare state: is this part of Jack or not? - if multi-config share state is part of Jack, then a new API to handle that has to be defined - when proposing new things, please keep in mind that jack2 is now multi-platform... don't be too Linux focused. Comments welcome! Stéphane

16 years, 8 months

[LAD] more jack/qjackctl madness

by Fons Adriaensen

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.

16 years, 8 months

[LAD] Line Array with AMBDec or WFSfocus

by Tom Brooke

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

16 years, 8 months

Re: [LAD] [ANN] guitarix-0.04.4-1 release

by James Warden

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 >

16 years, 8 months

Re: [LAD] [ANN] guitarix-0.04.4-1 release

by James Warden

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 > > >

16 years, 8 months

Re: [LAD] [Jack-Devel] jackd/jackdbus : D-Bus or not D-Bus...

by Stéphane Letz

Le 19 mai 09 à 11:30, Fons Adriaensen a écrit : > On Tue, May 19, 2009 at 10:38:24AM +0200, Stéphane Letz wrote: > >> 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... > > I will be writing an OSC layer (on top of the existing interfaces) > because I badly need a soluting for scriptable (i.e. non-interactive) > remote control of jackd. > > It will be non-invasive and just use the existing jackd/libjack > without modifying anything. There will be no such thing as an > 'OSC autostart strategy'. > > IMHO dbus could be just the same. This would mean that > any advantages it may bring will be there only if app > writers start using it *explicitly* by directly calling > dbus instead of a jackd/libjack C API function. > > Which just means that dbus will have to prove its value > in the market instead of being forced onto everyone, > and that is a Good Thing (TM). > > Support for accessing dbus could even be integrated in > libjack (or some new library) as long as it just adds > ew calls and does not modify the action of any existing > C API call. > > Ciao, > > -- > FA It seems you really don't want to see that using this "jack_client_open does a fork+exec call to launch jackd with the ./ jackdrc file" has been completely *hard coded* in libjack from day one! And is a really strong constraint for any possible new way of controlling the server. The discussion is now: do we keep this "hard coded thing in libjack" or do we try to relax it a bit ? Stephane

16 years, 8 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Linux-audio-dev