I am not necessarily interested in defending Artsd since I myself also do not care much for it. What I can do is though explain that artsd supposedly does a lot of other things that the KDE ppl seem interested in. In other words, chances for us convincing them to switch strictly to Jack are nil (tried before, as I'm sure some of you did as well, and pretty much got nowhere). This way at least we get to have JACK as the backbone of all servers and have KDE still with its architectural solution intact. I think it's great news, considering the alternatives. Ivica Ico Bukvic, composer & multimedia sculptor http://meowing.ccm.uc.edu/~ico

Let's hope the JACK support in arts is built that way then - a bit of liaison required with the KDE folks, perhaps? Maybe it's just me, but if I'm listening to or recording music I don't really want bings and beeps being sent to the soundcard by every program running on the desktop. I guess that's why I never missed artsd after I disabled it... Cheers Daniel

Daniel James wrote: Or why we don't want to encourage apps that just need that functionality to use jack by default. Good reaon to let them run via artsd. Then it's just a simple task of turning on artsd support when you want that functionality and turning it off when you dont. We could accomplish this by making jackd disable artds on startup ;) Another flag for someone to implement :) -- Patrick Shirkey - Boost Hardware Ltd. Http://www.boosthardware.com Http://www.djcj.org - The Linux Audio Users guide ======================================== Being on stage with the band in front of crowds shouting, "Get off! No! We want normal music!", I think that was more like acting than anything I've ever done. Goldie, 8 Nov, 2002 The Scotsman

Hallo, Steve Harris hat gesagt: // Steve Harris wrote: Well, but what's the point of having a soundserver at all when ALSA can do the mixing of the bings and beeps with its dmix plugin itself? Even format and samplerate conversion could be done with ALSA. The advantage is, that a soundserver would not block the soundcard all the time and thus has to be disabled by users. (Before I'm misread: There is a place for Jack, of course, which is way more than a soundserver) ciao -- Frank Barknecht _ ______footils.org__

In theory, yes, but has anyone seen KDE running on Solaris or anything like that? All the non-Linux platforms running free software desktops that I've seen have had GNOME - BSDs users, for example. Sun even built SUSE with a GNOME interface for its (cough...) 'Java Desktop'. I guess artsd could be retained for legacy use, but with ALSA 1.0 just around the corner, what's any Linux distributions excuse for not making it the default? And we know that artsd won't be much use until the non-KDE applications support it, which isn't very likely. Cheers Daniel

FreeBSD on the desktop is quite a minority taste though, isn't it? That's the rub... I thought JACK had been ported to OS X, at least initially? If you're producing serious audio software, I would have thought OS X is the most compelling target platform after Linux. Cheers Daniel

I disagree. The resources of free software developers are finite, and yet the potential demand from users for diverse (and therefore difficult to support) configurations is great. The reason that Linux audio is becoming successful is that a number of developers have standardised their work around that kernel. Imagine if everyone on this list ran a different system, maybe Hurd or Darwin based - progress would be very hard. The only free software system with a chance of breaking into the mainstream desktop market is a Linux based one, and that's by no means assured. So I see no point in supporting any other kernel for the time being. Of course, some people don't care about the bigger picture, and are quite happy to use an operating system to their individual taste while 99% of the desktop market remains proprietary. The problem is that the dominance of the 99% can mean the free operating systems are prevented from running on the next generation of hardware somehow. Cheers Daniel

I just got demudi 1.0, installing regular debian woody 3.0, and then using apt-get to grab alsa, jack, and the other demudi apps. I realized that even though Suse's kernel is better than a stock debian or redhat kernel, I found with apt-get its very easy to install the new low latency demudi kernel, and unlike Suse I don't have to spend $80 every six months to keep things current, everything I wanted from Suse is available with apt-get. I did find a couple of errors with demudi, where sox has a little problem, but most everything worked very easily, especially the hard stuff like installing the new kernel. I can always build sox from source.

On Mon, 2003-11-24 at 17:39, Rob wrote: I guess I should but I am using linux only:-) [only use freebsd at work] erik

On Mon, 2003-11-24 at 19:58, Guy Clotilde wrote: the verdict is not out yet... :-) don't believe all your feelings. I just like the idea of having different systems... meanwhile, at home, I use linux almost exlusively (except of games, I dual boot win for that) at work I use freeBSD and before that I used number of different unix system (ultrix, u/ux, solaris, sco, interactive unix) and I didn't see much difference between them, why should audio be any different? and yes, I am quite happy about linux audio development and appreciate all the work of developers that work on alsa, jack etc. (I've been following lad before). erik

I also have a Via 8233 audio controller and have no audio output from the conector on the back part of the PC. I only have output from the front conector. I was assuming that MY hardware had some problem. Is it normal?... GZS My hardware is as follows: 00:00.0 Host bridge: VIA Technologies, Inc. P4M266 Host Bridge 00:01.0 PCI bridge: VIA Technologies, Inc. VT8633 [Apollo Pro266 AGP] 00:08.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] (rev 34) 00:09.0 Multimedia video controller: Brooktree Corporation Bt848 Video Capture (rev 12) 00:10.0 USB Controller: VIA Technologies, Inc. USB (rev 80) 00:10.1 USB Controller: VIA Technologies, Inc. USB (rev 80) 00:10.2 USB Controller: VIA Technologies, Inc. USB (rev 80) 00:10.3 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 82) 00:11.0 ISA bridge: VIA Technologies, Inc. VT8235 ISA Bridge 00:11.1 IDE interface: VIA Technologies, Inc. VT82C586/B/686A/B PIPC Bus Master IDE (rev 06) 00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233 AC97 Audio Controller (rev 50) 00:11.6 Communication controller: VIA Technologies, Inc. Intel 537 [AC97 Modem] (rev 80) 00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 74) 01:00.0 VGA compatible controller: S3 Inc. [ProSavageDDR K4M266] Q wrote: -- This Message is sent from my Red Hat 9.0 Linux server Machine Registration number 205692 at http://counter.li.org/ .-. Gustavo Zamorano S. .-. | Registered Linux user number 320898 .-. | | at http://counter.li.org/ | | | | ___ |

On Fri, 21 Nov 2003, Daniel James wrote: <snip> I was trying to stay out of this thread, but... GNOME is prevalent on Solaris because 1) building something like GNOME or KDE on Solaris is non-trivial and you want the vendor (Sun) to do it for you. I have no idea why many vendors have chosen GNOME. At least here at work and among the geeks I know outside, KDE usage (on linux or BSD, whatever) is much higher than GNOME usage, by a wide margin. YMMV. artsd does have some uses (see below) and you can disable it if you want. Artsd works well for things like emulating full-duplex on crap-arse onboard sound rigs like this 810 rig I'm sitting at. Sure. it doesn't rock on the big iron hardware but for a general consumer sound rig it works fine. I've been running arts on top of ALSA for 2 years now w/o a failure or glitch. There's no reason for non-KDE apps to support artsd, as far as I can see so long as they can get to the OSS-emulation layer or better yet are ALSA native. Also, as I understand it, ALSA is standard (in linux) starting with 2.6.0, right? // John Bleichert // syborg(a)earthlink.net

On Sat, 22 Nov 2003, Steve Harris wrote: Quite likely. I asked around with some friends on the internet and it seems split pretty evenly. That and many people don't use either (I do most of my recording using fluxbox). Too much coffee, not enough brain. In ths spirit of this thread, is it really even possible that any sound server could be used across window managers? Are people suggesting that jackd be used as the lower-level sound daemon all the window managers could talk to? I assume ALSA in 2.6 is going to look (from above) just like the OSS sound layer. Doesn't this solve the problem? Or do artsd/esd/whatever get "in the way"? Will a window manager have to be re-coded if it assumes there's a lower-level daemon that emulates full-duplex on cheap hardware? artds has saved my bacon on 2 workstations at work with cheap-arse onboard sound. Would something like KDE require significant re-coding to use jackd? artsd seems to work fine for me, including sound in browsers. But I turn off all the window manager sounds (when using KDE) so maybe I've just never seen the conflict. I don't use it when I use jack/ardour though. off-topic: are there any newsgroups like this one that deal with home studio design and layout for the hobbyist? // John Bleichert // syborg(a)earthlink.net

Hi, I apologize as I didn't read maybe the first 20 posts in this thread, but I haven't seen any discussion of this in the last 15 I read this morning. If this got covered really early on please excuse my going over old ground. Has anyone considered trying to write an arts device driver that instead of talking to hardware talks to Jack? Why can't all of Alsa & Jack just look like hardware to arts? Arts apps could then use arts, and then arts itself got down to trying to send audio the arts 'driver' would just be talking to Jack. I am presuming that the 'ta da' issue would be easily addressed by something like this. It was reported some time ago that Wine has Jack support doing something like this I presume. I don't see why you couldn't run many sound servers doing something like this, but I'm sure there's some simple reason. (Or not...) Sorry for butting in so late... - Mark

On Mon, 2003-11-24 at 07:36, Steve Harris wrote: Thanks Steve. I guess I should have read the first 20 posts as I certainly don't understand where this thread moved to. Bye, Mark

On Fri, Nov 21, 2003 at 10:22:57AM +0000, Daniel James wrote: I'll take a swing. It's a working way to get multiple stream output for applications. Yes, we would scoff at its performance but that's not important. I don't really care if xmms and gaim have some amount of latency in their playback. All I care is that the sound comes out within a reasonable amount of time. So this would let there be two classes of audio apps - important ones, and unimportant ones ::-). Important apps like ardour can use JACK directly and have synchronized operation and low-latency. Unimportant apps like gaim can just go "bong" at some point when they need to. -- Ross Vandegrift ross(a)willow.seitz.com A Pope has a Water Cannon. It is a Water Cannon. He fires Holy-Water from it. It is a Holy-Water Cannon. He Blesses it. It is a Holy Holy-Water Cannon. He Blesses the Hell out of it. It is a Wholly Holy Holy-Water Cannon. He has it pierced. It is a Holey Wholly Holy Holy-Water Cannon. He makes it official. It is a Canon Holey Wholly Holy Holy-Water Cannon. Batman and Robin arrive. He shoots them.

Ross Vandegrift wrote: that's one fat lie (yes it does but no it doesn't solve the problem it's supposed to solve). if you need it in the first place (card does not support multi channels) you cannot use it because not all aps use it and you're in the same audo blocking hell as without it. example: set mozilla to use arts, set xmms to use arts etc... and then go and surf the web, flash, realplayer etc. all do not use arts and thus your mozilla blocks (looks frozen) on number of pages... (I suspect it's mostly flash, used in banners, not playing any sound but still trying to open audio) now what did arts help exactly? that's why the problem of multiple applications trying to use soundcard has to be solved by something that pretty much everybody uses erik

Hallo, Robert Jonsson hat gesagt: // Robert Jonsson wrote: aoss does the same for ALSA. It *might* even work with Flash, at least would be worth a try. ciao -- Frank Barknecht _ ______footils.org__

Ross Vandegrift wrote: double shrug! this is not the problem of the non free apps, this is a problem of _bad_ infrastructure (or perhaps unfinished - imagine a world without X, with only berlin, ggi, svgalib etc. - that's an analogy of current audio situation). free or non-free it should work and it doesn't. yes I could fix some of them or bug developers to fix it or pay somebody to fix or... but the important part of free software is that it actually _works_, nobody has time to fix everything... (even for values of everything limited to the programs that one uses) there has to be something that everybody will/can use and will not create a weak impersonations of BSOD while running (like programs freezes when they try to access the soundcard, often it's not that easy to find out that it's waiting for the soundcard (for general users)) perhaps dmix in alsa is that something... erik

On Thu, Nov 27, 2003 at 11:06:28 +0100, Hartmut Z Noack wrote: Depends how much ram you have - jack requires quite a lot. The cpu load is pretty low though, for largish buffer sizes. No - adding things like sample format negotiation and sample rate conversion would seriously hurt JACK. - Steve

for Sorry, couldn't help not to respond to this one. I understand that many people out there are still trying to squeeze the very last bit of life from their old hardware, but let's face it, if we want to see Linux on the desktop as a dominating force any time soon, then we need to stop worrying whether every single feature will run on our grandma's 486. We all know that Linux is about choice, but more importantly it is about understanding when it is appropriate to utilize particular features this choice offers us. In other words: If you want to run Artsd directly through the soundcard on your old thunderbucket pc just to hear that "you got mail," you can. But let's face it, you won't be using that computer for any serious DSP work. Hence you have no need for Jack, nor do you need to worry whether it will run on such a machine well (because it most likely won't and more importantly it shouldn't have to). OTOH, if you want a serious workstation that is still able to do silly blips every time your desktop wants to warn you about something, then with the artsd implementing Jack you'll be able to do that too. Some people have mentioned that they have really not missed these blips and beeps since they disabled the artsd. I happen to believe that such sounds are integral part of our healthy desktop experience (think people with disabilities, audible reminders from our calendars that make us be on-time for our appointments even though we are in the middle of our creative frenzy, or finally getting rid of that lousy and annoying built-in speaker beep), and as such it is a big stepping stone in having Linux desktop adopted by the mainstream customer base. Some people do not care if Linux ever gets adopted by the mainstream customer base. I tend to think that the adoption of Linux into the mainstream desktop environment will elicit more interest from the commercial audio companies and eventually bring us a winning combination of the OSS and commercial audio apps. Call me a dreamer if you want, but I think that we're very close to this. Now, if we could only get Gnome to do the same with their Gstreamer architecture, and make sure that Jack can run indefinitely without crashing, we'll be set! (please correct my ignorance if this has already been done) Ico

Hallo, Hartmut Z Noack hat gesagt: // Hartmut Z Noack wrote: ALSA's builtin dmix can do that. ALSA can (or should) be that. ciao -- Frank Barknecht _ ______footils.org__

On Friday 21 November 2003 16:06, Daniel James wrote: What we should be lobbying the KDE developers about - and also working towards from the audio end is ensuring compatibility between ALSA/Jack apps and KDE in general. I'm using Agnula/Demudi and it's taken a fair amount of juggling to be able to have both KDE and ALSA apps running in the same installation. This has more to do with libqt3 versions than ALSA. I assume this is due to many audio developers not using KDE at all (?yes that's an assumption). I can't remember where, but I know I've read many times the suggestion that we should disable arts in Kcontrol. I don't miss the whistles and bells at all - if I need an audible reminder I put cdplay in an "at" or "cron" job. Frankly I can't see myself doing any serious audio work using the KDE desktop - if I need a gui I'll use fluxbox, however it would be nice to easily switch between modes as has been suggested. btw: I tried running Jack on a P133 and hahahahahaha you must be joking :-) take care & take it often tim hall