Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

7501 discussions

xaudio - AUDIO Extension for the X Window System

by Robin Gareus

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hey LADs, Looking at the FOSDEM 2008 schedule I found a talk [1] about xaudio [2]. I was surprised that xaudio has not yet popped up on LAD or LAU (or have I missed it?). Has anyone checked that out already? Besides Desktop integration this could become quite interesting for tight audio/video sync. robin [1] http://www.fosdem.org/2008/schedule/events/xorg_xaudio [2] http://www.chaoticmind.net/~hcb/murx/xaudio/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHruVseVUk8U+VK0IRAq7aAJ0aLYUOI67ly+X2AER9wx7WxWO4sQCdGiXk MhmWLEnzjviURqAe111AhKI= =t7po -----END PGP SIGNATURE-----

17 years, 4 months

Summercode 2008: LASH, pt. 3

by Juuso Alasuutari

Here comes the third part of our exciting LASH trilogy. Unfortunately I lost the previous threads' mails while migrating from kmail & POP to thunderbird & IMAP, so I'll have to start yet another one. I'd like to apologize to those whose comments and questions I might have neglected to reply to during past discussions. I've needed to concentrate on my studies for the past week or two, and have had little energy to spend here. So if anyone has something to say, please do. Here's a rough sketch of what I think should be done in what order. A lot of the stuff that came up during the discussions here is missing, and that's how it should be. This list is supposed to end up being actually doable and realistic. Remember the magic words: "For starters." 1) Switch to using the JACK D-Bus interface for lashd<->jackd communication. 2) Add a D-Bus control interface to LASH, which is supposed to eventually replace the current liblash server interface API. 3) Change the liblash client interface's internals to use D-Bus for communication with lashd. 4) Start serious work on re-planning the API (extending it or adding an alternative one) and implementing new features. Most of the things discussed so far will fall under this category, and many of the suggested feature improvements will also affect API design. When this stage begins we should have another look at what's been said so far, and what we can make out of it. I'd like to add that although this is more or less what I'll be putting in my Summercode application, things probably will, and by all means should, also evolve on their own weight. Some of the changes I listed may already be written before June; who knows, maybe we'll have sharks with lasers. And my application may not be chosen at all, but that should only matter in terms of available resources to LASH development. Thanks, Juuso

17 years, 4 months

Re: [LAD] [Fwd: Re: Summercode 2008: LASH as a D-Bus service]

by Juuso Alasuutari

Bob Ham wrote: > In case you missed this. Sorry that this took me so long! > On Sat, 2008-01-26 at 22:25 +0200, Juuso Alasuutari wrote: >> On Friday 25 January 2008 18:27:10 Bob Ham wrote: >>> On Fri, 2008-01-25 at 14:04 +0200, Juuso Alasuutari wrote: >>>> On Wednesday 23 January 2008 23:21:21 Bob Ham wrote: > >> And I can imagine how the session loading could happen approximately like >> this: >> - LASH launches the JACK controller app, >> - the JACK controller app modifies JACK settings and possibly restarts JACK if >> necessary, >> - LASH launches the rest of the clients, >> - LASH connects the ports between the clients. > >> Now imagine the above scenario, but imagine that the JACK controller app >> doesn't get launched first. It will potentially wreck the session if it >> restarts JACK after other clients have loaded. If controlling JACK settings >> is done by one of the session clients, should that client be able to register >> to LASH with a special flag which indicates that it should launch first? > > This would be dealt with by client priorities (or dependencies.) What would guarantee that a JACK controller app would always get first priority (or be a "root dependency")? The controller app itself via an init flag? The user (bad idea IMHO)? Anyway I'm not sure if this topic is going anywhere in the foreseeable future. I fully agree that priorities/dependencies is a good idea, though. >>>>> User interface standard >>> Promote a standard to LASH clients in order to present a consistent user >>> interface. This would be like the GNOME HIG but audio-specific, eg, >>> specifying knob widget appearance and behaviour, recommending audio >>> widget toolkits, etc. >> You're treading on flammable ground here. I wouldn't want LASH to have the >> slightest authority over what toolkits and/or widgets the clients are coded >> with. And I don't see any reason why LASH should even care; LASH isn't a >> plugin host. I should be able to include an Ncurses-based drum machine with >> my session if I please. > > The GNOME HIG isn't enforced. Nor, I believe, is there any way to > enforce it. It's simply a document to communicate to developers of > GNOME applications the expectations that any application has on it when > taking part in a GNOME desktop. > > Similarly, the user interface standard for LASH would simply be a > document to communicate to developers of LASH clients the expectations, > in terms of user interface harmony, that any client has on it when > taking part in a LASH session. I didn't realize you meant a recommendation and not some UI protocol. (I'm not too familiar with GNOME.) Sure, but why should it be LASH-centric? Why not write an official linuxaudio.org HIG? Another question is how needed/desired something like this actually is. (Does the VST SDK come with a HIG document?) >>>>> Automatic client installation >>>> This sounds an awful lot like stepping on the toes of packagers and >>>> package managers. Unless you mean something completely different, of >>>> course. >>> What's meant is: if you load a session and it includes a client that >>> isn't installed on the system, then make it such that it is installed >>> and the session can be loaded. This is no small thing. There are a few >>> options: >>> >>> 1. Create a system which abstracts package management for different >>> distros >>> 2. Try and create an automatic compilation environment, similar to >>> ports on Freebsd or portage on Gentoo (lol) >>> 3. Use autopackage >>> >>> From the client side, this would be very simple: the programmer just >>> provides a URL to some meta-information that describes the packages >>> needed for that LASH client. I think this is pretty doable now that >>> number 3 exists. >> Yes, you are stepping on packagers' toes here -- heavily. > > Why do you think packagers' toes are being stepped on? I can't see any > conflict between package developers and a LASH package installer. If we are to restrict this topic to strictly providing hooks for existing package managers, then we might be able to stay out of trouble. Otherwise I suggest you go ask about it on #debian. :) >> Abstracting package management for distros is an insanely huge task > > Note the phrase "this is no small thing" above. > >> , and not >> likely to work in practice. > > Possibly > >> Creating an automatic compilation environment -- >> well, I assume you're joking > > Nope > >> because this would equal writing your own >> source-based package manager > > Yep All I have to say is good luck. :) >> Using autopackage is out of the question, >> because you simply can't fulfill the needs of all distros > > Autopackage exists. It works. It doesn't seem to be out of the > question. The issue isn't fulfilling the needs of the distro but > fulfilling the needs of the user. The point isn't to safeguard the poor packagers from grey hair, although to a certain extent that's also a factor. What I'm worried about is how on earth will a rogue package manager, working irrespective of the distro's own managing system, benefit the users in the long run? Sure, you will be able to quickly install externally provided packages via some nifty tool, just like you can quickly unpack binary tarballs in your root. And when the distro's package manager pulls a straw up its nose due to broken lib dependencies and whatnot, I guess the users won't feel too good afterall. >> If a session manager would take on package management like this -- which it >> definitely _shouldn't_ in the first place > > Why not? I apologize if this sounds like circular logic, but it is: A package manager is what you use for managing packages, and when managing packages what you should use is a package manager. Linux != Windows. >> -- it would have to work absolutely >> _perfectly_ on _all_ possible distros. Either that, or nothing. > > Why would reverting to normal, not-as-astonishingly-cool behaviour on > some distros be bad? An external package installation system would by and far not work "normally" at all on many systems. >> I wouldn't want autopackage messing around with my box -- I want >> packages installed the way they normally are with Source Mage. > > Then don't use the automatic LASH client installer :-) Or you could > implement the distro-specific functionality for your distro. That would > allow you to have your packages installed the way they normally are with > Source Mage. That's as far as I'd be prepared to go. If LASH would notice that I didn't have $PROGRAM installed, and it would tell me my distro's package name for $PROGRAM, I'd be very happy. I would _possibly_ even be willing to click on a link saying, "Click here to install $PROGRAM using $YOUR_PACKAGE_MANAGER". And even that "simple" feature would require LASH to ship with an up-to-date matrix of program names matched against all distros' corresponding package names... >> Considering how you've been defending LASH from features that you deem outside >> of its domain, I'm surprised that you would come up with this idea. > > Session loading is within the domain of LASH. I would strongly argue that managing packages is way beyond the concept of session loading. But I don't feel that we should really be wasting much time on this subject at this point anymore. >>>>> Redesign client/server communication >>>>> Certificate based security/encryption >>>> Why would managing an audio session demand that the connections be >>>> certified and encrypted? Unless you're thinking network-wise (i.e. >>>> sessions that span several networked computers). >>> I'm thinking network-wise. >> As I've said before, I don't believe it's a good idea to add this stuff to the >> client protocol. Inter-host communication is a different thing. > > There's an assumption here that lashd<->lashd and lashd<->client > protocols aren't the same thing. They would be communicating very > similar information. Having two protocols would be unwieldy. Can you clarify whether you mean the LASH client or server interface when you say that they would communicate similar information? Juuso

17 years, 4 months

midi player for jack ?

by Fons Adriaensen

Salve, Is there anything like pmidi for midi-over-jack (i.e. a command line midi file player) ? Ciao, -- FA Laboratorio di Acustica ed Elettroacustica Parma, Italia Lascia la spina, cogli la rosa.

17 years, 4 months

jack-midi? what are the benefits?

by Marcell Mars

i was following the discussion on technical details.. it was interesting and i learnt a few things.. still not enough to put it into any code.. i sort of sorted out what is the jack-midi about but was trying to play a bit stupid (sometimes i can't stop that game even when i want ;)) and fnd something on mailing list or web site... couldn't find it.. these would be the questions: what would be the benefits of using jack-midi over alsa sequencer? is that related to jack transport somehow? how? is that better timing? why? is that better integration/sync with some other jack events related to time? which events? it would be great if answers are not just 'yes' ;) but i'm not really looking for more than one sentence for any question... i can then format it into something which then could be put on the web site... hope this is not too much of wasting time of developers... thanx

17 years, 4 months

[OT] an ogg vorbis player for Java ME mobile phones?

by Joern Nettingsmeier

hi everyone! i recently got myself a sony ericsson k850i, which is ok phone-wise and as a modem for linux, except that it doesn't know about ogg vorbis. since it provides a java environment, it must be possible to correct that :) does anyone have pointers to open-source ogg vorbis player implementations for java phones? iiuc, the program needs to be a MIDlet (whatever that means), i.e. it can't be a standalone app with a static void main(), but must inherit from some javax.microedition.foo class similar to web applets. thanks, jörn -- jörn nettingsmeier home://germany/45128 essen/lortzingstr. 11/ http://spunk.dnsalias.org phone://+49/201/491621 Kurt is up in Heaven now.

17 years, 4 months

Re: [LAD] Summercode 2008: LASH, pt. 3

by Phil Mendelsohn

Fons Adriaensen said: > It's the same when you > work in a physical studio: you can use any instruments > you want, make any music you want, use all the effects > equipment, but you're not allowed to modify the studio > itself. I'm not going to argue with your point, but I can come up with a number of counter examples of modifying a physical studio during a session! Putting the playback speakers out of phase so that the vocal mic could be placed in a cancellation node in the live room - neat trick, try it! - in order to accomodate a singer who could not wear headphones due to an injury involved pulling the speaker to get to the banana plug. The signal to the amp had to be mono, and it was harder to get to the back of the amp rack... Some of my most fun in the studio (back in the days) was modifying the studio! -- "Nothing is too small to know, and nothing too big to attempt." --Sir William Cornelius Van Horne

17 years, 4 months

[Fwd: Re: Summercode 2008: LASH, pt. 3]

by Juuso Alasuutari

I'm assuming you meant to post this to the list, Paul. In reply to your comment: One of the motives behind jack-dbus is that a JACK control application shouldn't have to be RT capable since it's not processing any realtime-sensitive data anyway. From a technical perspective, could libjack be extended with such a non realtime control API? -------- Original Message -------- Subject: Re: [LAD] Summercode 2008: LASH, pt. 3 Date: Mon, 04 Feb 2008 11:33:44 -0500 From: Paul Davis <paul(a)linuxaudiosystems.com> Reply-To: paul(a)linuxaudiosystems.com Organization: Linux Audio Systems To: Juuso Alasuutari <juuso.alasuutari(a)gmail.com> References: <47A4B4DC.8080306(a)gmail.com> <20080204123036.GJ2670(a)zita2.kokkinizita.net> <47A73ADC.5060207(a)gmail.com> On Mon, 2008-02-04 at 18:18 +0200, Juuso Alasuutari wrote: > That being said, I still do favor D-Bus over OSC. The point is that they are both irrelevant in the context of JACK itself. First you need an API in JACK to control what you want to control. Then you need a JACK-aware application that speaks <your preferred protocol>. When it gets <your preferred message> it invokes the <relevant part> of the JACK API.

17 years, 4 months

Re: [LAD] jack client autoconnection

by Kjetil S. Matheussen

Fons Adriaensen: > > On Mon, Feb 04, 2008 at 03:32:23PM +0100, Fons Adriaensen wrote: > >> Where jack_autoconnect() would use environment variables, >> read .rc files, invoke the Buddha, or consult Paul Davis or >> the oracle of Delphi to find out which ports to use, but >> without requiring any special support from jackd itself. > > The code required is much shorter than the length of this > thread so far, so I take the liberty to post it. > Quickly but not fully tested. > > I would say that your function is a connect-many-ports-at-once function, not an autoconnect function. What I'm thinking is that the jackd program has an extra option called "--autoconnect-ports / -ap", which contains a comma-separated list of port names. If its not supplied, or "--no-autoconnect / -no" is not supplied either, jack_autoconnect(client,num_ports,port); will connect to the physical ports. This requires some modification to jack. But it shouln't be that much of a work. Besides, two other functions are needed as well: int jack_get_num_autoconnect_playback_ports(void); int jack_get_num_autoconnect_record_ports(void);

17 years, 5 months

Re: [LAD] jack client autoconnection

by Kjetil S. Matheussen

Fons Adriaensen: > >> You can be as much of a professional user as you want to. >> It doesn't change the fact that other professionals might >> not want the system to behave like you do. > >Which again means it should be configurable. Absolutely. I think a new function for jack would be better than an environment variable though: int jack_autoconnect_playback (jack_client_t *, int portnum, const char *source_port); int jack_autoconnect_record (jack_client_t *, int portnum, const char *destination_port); The reason is that this API will make it easier for programs to make autoconnection configurabe. Autoconnecting the old way (which includes finding the physical ports and/or checking environment variables for ports to connect to, etc.) is a lot more hassle than just calling the functions above. > BTW, JSB may turn in his grave, but I _do_ like the > sound of sandysth... I still have to go through the > works to understand the algorithm... Thank you very much. :-) I don't understand the algorithm myself, so if someone else understood it, that would be great. I think its quite similar to green noise, which I read about later, created by moore at ucsd if I remember correctly.

17 years, 5 months

Jump to page:

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