Hi Antonio, Tuesday 30 September 2003 19.53 skrev Antonio: Yes, the output buffers which are 2x512 frames need to be filled before you hear anything. No, emu10k1/2 based cards are currently limited to this setting. I think this is a limitation of the driver and not the hardware though. There is an asio driver available for windows from some russian developers that achieve massively lower latency. (I think 2x128, or even lower) Someone should really check with them if there is something easy that can be changed in the alsa driver to achieve this... You can skip jack if you want, but there is no difference in latency. Some people argue it's a problem with the hardware of Audigy/SBLive, but I'm quite confident that it's a driver problem. Or, put another way, the problem is probably that Creative doesn't provide good enough specs of the card. /Robert

Antonio, is it the USB based Audigy you are talking about? If so, forget everything I said ;) /Robert

Thanks to all for the anwers. Anyway (there have been some incomprention) my card is a pci audigy player, not an usb one. I use for example ams in realtime driven via midi. If I don't use jack and output directly to alsa, why doesn't the latency decrease? I think: midi in latency + synth lat + alsa out lat instead of midi in latency + synth lat + jack lat + alsa out lat What's wrong? I've another issue. When I use the digital output of my card I cannot adjust the volume, but only mute/unmute the output from the alsamixer. Is it a driver limit or maybe have I to put something in asound.conf (I don't have that file, only asound.state)? Antonio, bye.

Hi, onsdagen den 1 oktober 2003 16.06 skrev Antonio: As Fernando pointed out jack doesn't add any latency, it's the same audio buffers that are filled every iteration. Jack does add somewhat to the CPU utilization, but the price for that is very low when compared to the connectivity possibilities you aquire. To lower the latency you need to adress the buffering on the soundcard. Some softsynths may have their own internal buffers that may add to the latency. Normally this isn't a problem though. As for the scenario you laid out eariler. Using softsynths at 2x512, I do exactly that and I think it's quite usable. My system can usually go lower than that, latency wise, but I don't feel a need to put the extra load on the system. I have both an Audigy and an SB-Live, to my knowledge I can't make any of them use buffers smaller than 512 frames. But as I said earlier, I'm convinced it's a driver issue and may be fixable. /Robert ps. Here's a link to the windows sb-live audigy drivers I mentioned: http://kxproject.lugosoft.com/index.php?skip=1 ds.

Sorry for the error Re in the object.

On Tue, 30 Sep 2003 18:09:34 +0400 "horsh" <horsh(a)mail.ru> wrote: ricktaylor(a)speakeasy.net wrote: {SNIP} {SNIP} {tho' FVWM is fairly similar and makes for a really nice Unfortunatly, I've only worked with FVWM so I can't compare it to the rest. But I can tell You that it's __very__ lightweight, boots up __very__ quickly and uses __very__ little resources. And there's not even __one__ "built in" feature that You're "stuck with". For instance... in KDE (the only other Window Manager I have experience with) always loads the "task bar". I'm sure if I hacked around I could find a way to __not__ start up with it. But FVWM can be so stripped down that there's not even a back ground color. All you see is that grey mesh that You see just before (whatever window manager You're using at the time) starts up. Yet it has ways of creating just about any convience you want (like a task bar). Also... (and maybe this was what you were referring to when you said "border gravity") but the config file let's you set (if my memory serves Me well) "--geometry" for a window, so that it will open up at whatever position you want (or whatever desktop you want to send it to). And if You're completly determined to have them all together, locked into the (aformentioned) "FvwmPartion" (which sounds like a great approach), but yet, the whole modual filled with programs are too big for Your screen, FVWM has a feature were the Virtual Desktops can be "borderless". So if the bottom half of the modual disapeared beyond the bottom of Your screen, you can move your mouse down to the bottom and all of a sudden, you're at the Desktop were the lower half of the modual disappeared to (you would look up at the top of the screen and see the second half of the modual). Of course, in that case, maybe it would be better to have just have the most used parts of the components sent to desktop 1 (on start-up) and the secondary components sent to desktop 2, each stuck together with it's own FvwmPartion modual. The other thing that is cool (and I assume is common to all Window Managers) is the ability to have __some__ programs show up on __all__ desktops, and __others__ show up on __only__ __one__ desktop. Which can be another way of organizing things. I can see this as an advantage if (for instance) you have so many programs opened up that you are __forced__ to use mulitple desktops, then at least you can use the "common to all" program (a mixer would be a good example) follow you to each desktop you go to. So... there's your mixer up on the left top corner of you screen... yet you just moved to a different desktop were there's suddenly a whole new set of programs... and yet... the mixer is still were you like it to be. Of course... You can alway learn C, take the source code of all these programs and create one "monster program" (OK, that was kind of a long shot... but I thought I would suggest it... heehee...). Rocco