On Sun, 01 Feb 2004 12:05:19 +0100 Jan Weil <Jan.Weil(a)web.de> wrote: Yes, it is possible using the aoss script. But i have the feeling that this still has problems with mmapped mode. Well, here you go: -----.asoundrc #asym fun start here. we define one pcm device called "dmixed" pcm.dmixed { ipc_key 1025 type dmix slave.pcm "hw:0,0" } #one called "dsnooped" for capturing pcm.dsnooped { ipc_key 1026 type dsnoop slave.pcm "hw:0,0" } #asymed to combine the two pcm.asymed { type asym playback.pcm "dmixed" capture.pcm "dsnooped" } #a quick plug plugin for above device to do the converting magic for #alsa apps [saves typing the "plug:" prefix in config dialogs and when #testing with aplay] pcm.pasymed { type plug slave.pcm "asymed" } #a ctl device to keep xmms happy ctl.pasymed { type hw card 0 } #ok and these are the two definitions used by aoss: pcm.dsp0 { type plug #i could have used "pasymed" here, but then we would have the plug thingie twice in the path slave.pcm "asymed" } ctl.mixer0 { type hw card 0 } -----.asoundrc Well, anyways, with above definitions in your .asoundrc it should be possible to use aoss your_oss_app and it should automatically use the "asymed" device. Now point your alsa apps to "pasymed" and you should be ready to go. On my machine though, sending to asymed or pasymed results in no error messages, but also in no sound. So, to test an mmapped game i change the above definition of pcm.dsp0 to pcm.dsp0 { type plug slave.pcm "hw:0,0" } This disables the mixing, but at least i hear something. So when starting enemy territory with aoss et i do get sound, but it crackles and the sound seems to get stuck sometimes [buffers repeating, etc..], sometimes it also off for a minute or so and then returns.. I also don't know if the ctl.mixer0 is honoured. i read that somewhere. The aoss manpage only talks about pcm.dsp0. Flo -- signature :)

The label "Frank Barknecht" hathe been affixed to this message, Maybe something like a meta-driver that you could call from anything... a sort of layer between the actual hardware setup and the rest of the system so that application developers could simply reference the one consistent object without dealing with any other issues. Or will Dmix do that? -- See these tears so blue. An ageless heart that can never mend. Tears can never dry. A judgement made can never bend. ... And I've been putting out fire with gasoline... {Dave}

Screenshot: http://chat.carleton.ca/~drobilla/patchbay.png Waiting on the Jack callback issue to make a pre-release. Anyway, basically I need a name for this thing, and any (UI) suggestions anyone has. Eventually it will be a combined jack/alsa patch bay, so it'd be nice if the name reflected both jack and alsa, but I'd rather not have "Linux" in the title. Any interface ideas (other than the color of the modules ;) ) are welcome... and if anyone has ideas for an elegant automatic-module-placement solution, I'd love to hear them. Right now they're just randomly placed. (Are there known algorithms in graph theory for this sort of thing?) -Dave

On Mon, 2004-02-02 at 01:11, Paul Winkler wrote: Not a bad idea.. certainly not on by default, but it would be nice to have hydrogen appear sane. On the list..

Jesse Chappell wrote on Mon, 02-Feb-2004: Forget that... too many already. How about jackbox? jlc

Dave Robillard wrote: A simple idea would be to place them randomly initially, and thereafter always place them where the user put them the last time. My guess is that a typical user will have the same applications running from session to session, and would prefer if they where positioned at the same place every time. Marcus

On Mon, Feb 02, 2004 at 12:37:32 -0500, Dave Robillard wrote: Hey nice! antialiased too :) Yeah, there is, try citeseer or maybe the dot people have something? http://www.research.att.com/sw/tools/graphviz/refs.html The problem you will find is hat most gaph algorithms dont care about consitency of positioning between graph changes (eg. adding a new client), but you could have an "organise" button to hit if it gets messy. - Steve

On Mon, 02 Feb, 2004 at 12:37AM -0500, Dave Robillard spake thus: I just dribbled on my keyboard. Just yesterday, I decided that I'd do something like this if I ever got the time. Or the skill ;)

On Thu, Feb 05, 2004 at 09:51:42PM -0500, Dave Robillard wrote: - or select them and press del. - right click on a port makes a menupopup where you can select to disconnect connection to foo or all connections. like in galan. i find it quite useable. -- torben Hohn http://galan.sourceforge.net -- The graphical Audio language

On Thu, 2004-02-05 at 21:51, Dave Robillard wrote: So it seems the concensus is right clicking to get a disconnect menu, or click on one port and then the other like connecting? They're certainly not mutually exclusive, so I'll do both (I did the "Disconnect All" menu item last night actually) Thanks all -Dave

last time i looked, the support for splines on the canvas was all stub functions. --p

On Mon, Feb 09, 2004 at 02:13:57 -0500, Dave Robillard wrote: This should be detectable automatically by looking at the JackPortIsTerminal flag or whatever its called. Though being able to override it by hand is good too. - Steve

jack works with intel830 DRI see http://www.pawfal.org/Software/fluxus/ (you might be interested) - it used to have a native jack interface, but now works through portaudio. On Mon, 2004-02-09 at 23:26, Dave Robillard wrote: -- ................................. www.pawfal.org/nebogeo

its a basic problem with real time software, the POSIX API etc. JACK tries to lock *all* the process memory. POSIX doesn't offer any APIs that would allow us to lock only the parts we need locked without a lot of impossibly ugly, non-portable kludgery. the part that needs locking consists of any memory that will be touched by the code run in the JACK-managed "audio" thread. the implementation of DRI by certain video interface drivers means that we end up trying to lock the video memory as well, and this tends to fail for various reasons. its not what to do about this. the most obvious answer is "don't try to run real-time software on systems with these video drivers installed". i know its not very satisfactory, but its all we have for now. --p

or ... you could just get a Matrox video interface, since they seem to be just about the only company that understands the way that video h/w interacts with audio and realtime issues. or maybe i should say the only company that actually cares about it. they even had a booth a NAMM ... --p

On Mon, Feb 09, 2004 at 08:19:55PM -0500, Dave Robillard wrote: I would say that there is still hope as far as ATI is concerned. They are delivering specs to the Linuxbios people, so they can get VGA working through LinuxBIOS :) regards, v

Paul Davis wrote: i'm using a g550 w/ dual-head at work, and i must say this is god's own video card for audio. if only i could afford a second screen at home :( -- The handles of a craftsman's tools bespeak an absolute simplicity, the plainest forms affording the greatest range of possibilities for the user's hand. That which is overdesigned, too highly specific, anticipates outcome; the anticipation of outcome guarantees, if not failure, the absence of grace. - William Gibson, "All Tomorrow's Parties" Jörn Nettingsmeier Kurfürstenstr 49, 45138 Essen, Germany http://spunk.dnsalias.org (my server) http://www.linuxaudiodev.org (Linux Audio Developers)

On Mon, Feb 09, 2004 at 07:32:35PM -0500, Paul Davis wrote: Hm, that sounds bad. Does this problem also happen with the open source drivers from dri.sf.net ? I was just thinking of getting an IBM thinkpad and I might want to change the model I want based on this. Too bad :/ v

On Mon, Feb 09, 2004 at 07:32:35PM -0500, Paul Davis wrote: This is to ensure that nothing gets swapped out, right ? Else it is very hard to ensure real time performance ? (sorry for being somewhat ignorant in this matter). Is this faillure due to the nature of the memory that we are trying to lock ? Or is the problem that we try to lock the same part of memory multiple times ? Would the less obvious answer consist of one of the following ?: - change the video drivers (at least the ones that are source based) - do something at the API level, so we can lock selectively can give us what we want (only locking the memory that gets touched by the audio thread and nothing else), but obviously this goes beyond the scope of jack alone ? Would you consider implementing a work around (aka non portable kludgery) a waste of time ? regards, v

On Tue, Feb 10, 2004 at 01:45:49PM +0100, Robert Jonsson wrote: Ok. I assume that you have a Firegl T2 with 128Mb Ram (using the ATI 3.7.0 drivers) ? Yep, I read that message. I wasn't so sure if that was a complete solution though, as Paul talked about faillure to lock memory for _various_ reasons :) So another solution would be to add more RAM to the machine you're working on ? :) best regards, Vincent

Vincent Touquet wrote on Tue, 10-Feb-2004: BTW, i just ran JACK realtime on a T41p with the firegl T2 128MB, using the ati 3.7.0 drivers on a 2.4.22 PE/LL kernel with no problems. Alsa 0.9.8 using the builtin audio (snd-intel8x0). the machine itself has 512MB of RAM. I tested with alsaplayer, jack-rack and freqtweak together loading the system to > 80% cpu utilization and no xruns at 256 period size (and possibly less) and 48k. And yes, ATI's drivers have DRI enabled.... note that i didn't try to run any opengl accelerated apps at the same time as jack yet..... but i don't see any of the problems with regard to memory locking. maybe 512 is too much RAM to notice the problem. jlc

Vincent Touquet wrote on Tue, 10-Feb-2004: Gentoo. That kernel is the gentoo patched one (with LL and PE). At some point I might test it with the RME hdsp/cardbus, but I think it will be fine, the cardbus chipset is TI. I think you could even go lower.... i actually tried 64 and non-intensive audio duties (alsaplayer only) seemed fine even while compiling. It all depends on your target application.... for low-impact softsynths or samplers I think you can get some pretty impressive playability even from the builtin audio. As it only has a mic input... i don't think you'll be using it for realtime fx :) jlc

Paul Davis wrote: What are the factors influencing the amount of memory the JACK process needs? Maybe it's possible to reduce it. Unless I misread what you wrote and by "*all* the process memory" you mean the memory of all processes on the system and not just JACK. Chris

Vincent Touquet <vincent.touquet(a)pandora.be> writes: In the 2.4 kernel this test in mm/mlock.c limits page locking to half of physical memory... /* we may lock at most half of physical memory... */ /* (this check is pretty bogus, but doesn't hurt) */ if (current->mm->total_vm > num_physpages/2) goto out; Maybe that test is being confused by the presence of video memory somehow. If you're looking for kludges, try commenting it out to see what happens. -- joq

On tis, 2004-02-10 at 03:45, Benjamin Flaming wrote: I didn't know there was an optimized 3D driver for the 7500? /jens

Dave Robillard wrote: i'm using dri with an ancient 3dfx voodoo3 3000 agp card, and i have no problems with jack in realtime mode. -- The handles of a craftsman's tools bespeak an absolute simplicity, the plainest forms affording the greatest range of possibilities for the user's hand. That which is overdesigned, too highly specific, anticipates outcome; the anticipation of outcome guarantees, if not failure, the absence of grace. - William Gibson, "All Tomorrow's Parties" Jörn Nettingsmeier Kurfürstenstr 49, 45138 Essen, Germany http://spunk.dnsalias.org (my server) http://www.linuxaudiodev.org (Linux Audio Developers)

On Tue, Feb 10, 2004 at 08:31:10AM -0500, Dave Phillips wrote: Personally, if I would have to buy a new video card, I'd rather give the money to a knowledgeable hacker for a workaround :) I'm not yet sure if the problem will affect me (I think it will though, I want to use jack in realtime mode together with accelerated 3D on a laptop, which I will get in a few weeks time), but if it does, I'll certainly consider forking over some cash to pour in a GPLed solution. v

On Fri, Feb 13, 2004 at 12:14:53PM +0000, Steve Harris wrote: Right. Cool, only right now I don't have the time to chase it down myself, at least not fast enough without help. v

On Friday 13 February 2004 13.53, Tim Goetze wrote: [...] Yes... That's a really rather annoying side effect. However, there are actually quite powerfull cards with large, fan-less heatsinks. It doesn't get more silent than that! ;-) And there's always the option of replacing the original heatsink + fan assembly with a water cooling block (provided you have a water cooled machine) or a big fan-less heatsink, like this one: http://www.zalman.co.kr/english/product/ZM80C-HP.htm I've mounted these on two ATI FireGL 8800 cards without (major) problems. The heatsinks are supposed to support bigger/hotter cards as well, but you should definitely use the optional fan for those. (I'm using the fan anyway, as there isn't much self circulation with horizontal heatsinks. Very silent but quite sufficient at 5 V.) Well, as annoying as it it, it seems like we'll just have to accept that the drivers are part of the package. You buy a video card, and you get drivers one way or another; drivers that are pretty close to firmware, except that it runs on the host CPU. And you don't have the source of the firmware in your printer, modems and other devices, do you? Doesn't really matter as long as they work, and speak some comprehensible standard protocol. Still, I'd really prefer if I could debug these bl**dy ATI drivers myself, rather than wasting time posting bug reports to ATI. And having the source of my laser printer's firmware could be fun... Actually, many OpenGL developers do sort of take s/w OpenGL in account: They explicitly do not support it, as it's dog slow pretty much by definition, and there isn't much to do about that. OpenGL doesn't lend itself well to s/w implementation. Well, M$ and Apple desktop environments seem to be moving towards using 3D acceleration for all rendering, but 3D acceleration probably isn't cheap and widely available enough for this approach to completely replace s/w rendering and 2D acceleration just yet. Embedded PC hardware still generally comes without 3D acceleration, and it'll probably stay that way until GPU power consumption has been reduced by at least an order of magnitude. I'd assume your average laptop user would really rather not waste power on eyecandy either. So, I guess the 2D acceleration and s/w rendering APIs will be relevant for several more years to come - and applications should preferably support *both* 2D and 3D APIs when appropriate. (Could be done through 2D-over-3D wrappers or backends.) //David Olofson - Programmer, Composer, Open Source Advocate .- Audiality -----------------------------------------------. | Free/Open Source audio engine for games and multimedia. | | MIDI, modular synthesis, real time effects, scripting,... | `-----------------------------------> http://audiality.org -' --- http://olofson.net --- http://www.reologica.se ---

On Fri, Feb 13, 2004 at 03:24:05PM +0000, Steve Harris wrote: Which one ? :) Nice ! v

On Friday 13 February 2004 16.52, Steve Harris wrote: Looks very nice, but (always "but" :-/ ) it appears to have a RAMDAC bandwidth restriction that limits the maximum dual head resolution to 1920x1440. Is it possible to use 2048x1536 + 1808x1356 or similar, or is the big, noisy (*how* noisy, actually?) Parhelia still the only viable option for my apparently insanely high end setup...? (The 750 has the same limitation *and* a fan, so that's not an option.) How about OpenGL? I heard there's an unsupported OpenGL driver now. Tried it? //David Olofson - Programmer, Composer, Open Source Advocate .- Audiality -----------------------------------------------. | Free/Open Source audio engine for games and multimedia. | | MIDI, modular synthesis, real time effects, scripting,... | `-----------------------------------> http://audiality.org -' --- http://olofson.net --- http://www.reologica.se ---

Steve Harris wrote: where? -- The handles of a craftsman's tools bespeak an absolute simplicity, the plainest forms affording the greatest range of possibilities for the user's hand. That which is overdesigned, too highly specific, anticipates outcome; the anticipation of outcome guarantees, if not failure, the absence of grace. - William Gibson, "All Tomorrow's Parties" Jörn Nettingsmeier Kurfürstenstr 49, 45138 Essen, Germany http://spunk.dnsalias.org (my server) http://www.linuxaudiodev.org (Linux Audio Developers)

[Steve Harris] i think you're doing the right thing to offer this as an alternative, but i must confess i don't envy your position as code maintainer. :) tim

Dave Phillips wrote: Maybe it's your sound card. I know that my crap laptop sound card definitely responds to keyboard, mouse, and cpu activity. Maybe though it's some kind of audio buffer problem. What happens to audio if you don't run X? Best way in theory to troubleshoot is to divide the problem in half by taking away half of the pieces, and iterate until you find it. In practice it can be hard to determine where "half" is. Try no X :) Chris

On Tue, 2004-02-10 at 08:31, Dave Phillips wrote: - Take that binary driver out of your kernel (I know you need it, but remove it temporarily to see if it's the problem) - Get jack running in realtime mode! (The 'zippering' and other really brutal errors are probably because of this) - For noise problems (hum), google for the Linux Sound Quality HOWTO I hope for your sake the vid driver isn't the problem, because if it is there's not a single thing you or anyone else can do. < insert rant here > -Dave

On Tue, 10 Feb 2004 13:21:08 +0100, Vincent Touquet wrote I've had problems getting v19 to work, so I don't think the released fluxus version supports the new api yet - it's only a few small changes though. cheers, dave ................................. www.pawfal.org/nebogeo

On Tue, 10 Feb 2004 14:45:30 +0100 (CET), CK wrote yep indeed - cheers - I just haven't released this fix yet as v19 is broken on my laptop, maybe I should release a test version (or give them a hand with portaudio and make myself useful ;)) cheers, dave ................................. www.pawfal.org/nebogeo

On Mon, 2004-02-02 at 05:37, Dave Robillard wrote: What toolkit does it use? Bob -- Bob Ham &lt;rah(a)bash.sh&gt;