If your card doesn't support hardware mixing then just use dmix. What's the problem?

You can actually get jackd to work with dmix, you just have to use matching ALSA parameters (default or plug:dmix or something device, samplerate, buffersize etc) for jack and run in playback-only-mode

HI This is the problems I am having trying to get away from Sonar and windoze. I have all the planetCCRMA stuff but cant actaully get any sound at all from my MOBO VIA-97 or my RME card. I can just get jack and Ardour started and working but untill I can here anything I'm stuck. Am I caught between OSS and Alsa alsa conf says its configured my cards. cheers Bob

 Am I caught between OSS and Alsa alsa conf says its configured my cards.

Here is the output. [root@puma ~]# cat /proc/asound/cards 0 [V8235          ]: VIA8233 - VIA 8235                      VIA 8235 with VIA1612A at 0xe000, irq 22 1 [R15            ]: RME9636 - RME Digi9636 (Rev 1.5) RME Digi9636 (Rev 1.5) at 0xde000000, irq 19 cheers

PS I saw a post about volume levels Er I'm sure I checked them

the problem is: i install one app, install another app, both are outputting sound, and it won't work.

you can port open source apps to audio, and blame commercial companies to write apps for alsa (Id did, the new doom III release has alsa support)

but u still need to struggle around with alsa config, etc.

the problem is that it doesn't work out of the box like on WinD0w$. well - don't get me wrong, i actually like the fact that linux is highly configurable, and i personally have no problem to write my .asoundrc, but if linux should have success on the desktop, thats definitely a must-have.

Yes. BTW: have a look here: http://www.portaudio.com/docs/proposals/status.html this should support jack, alsa, oss, so its definitely a good thing, and also non linux systems (sgi, mac, windows). I unfortunately do not have the time to look on the api specs and sample implementations, but i'm sure, if u create such an high portable api, you'll sacrifice some of teh native apis advanced features.

dmix

Why can't ALSA be the common layer?

They should not have to.  If you have to hack .asoundrc and google for hours to get sound working then IT'S A BUG IN YOUR DISTRO.  Please file a bug report.

Yeah, like always: we have no common soundserver :( . If you have running JACK all time and using KDE, you can make arts a JACK client and make kaffeine play the video through arts to jack. Best regards ce

Have fun: you'll know confusing things :) . Yeah, freedesktop.org is somehow a common base both try to use. Worse: Because there's no common audio layer in linux, I guess that Gnome and KDE will start using a common soundserver, but then again it's again a KDE/Gnome only solution.

The questions are: * Would JACK be stable enough? I guess yes. Furthermore, we can make a deamon which restarts jack if it dies * Is JACK secure enough? Certainly jack would never be started by any distribution per default with realtime privileges. But this is not needed for the common user, so users who need it can turn it on later. * Could JACK be started during boot time and collect audio from any user? As discussed before, this is not necessaryly needed, JACK could also be started as soon a user logs in. But I like the idea that I can have multiple X sessions and every of these users can play audio * One problem remains, JACK cannot use different soundcards because of the cards quartzes. So, would we have to start a seperate JACK instance for each card?

On Fri, 2005-01-07 at 22:45 +0100, Christoph Eckert wrote: Linspire (formerly Lindows, then L*nd*ws or something) posted to the jackit-devel list that they are in fact using JACK as the sound server for their next release. Let's see how well they pull it off...

On Fri, Jan 07, 2005 at 06:02:47 -0500, Lee Revell wrote: > On Fri, 2005-01-07 at 22:45 +0100, Christoph Eckert wrote: > > The questions are: > > > > * Would JACK be stable enough? I guess yes. Furthermore, we > > can make a deamon which restarts jack if it dies

> > * Is JACK secure enough? Certainly jack would never be started > > by any distribution per default with realtime privileges. But > > this is not needed for the common user, so users who need it > > can turn it on later.

> > * Could JACK be started during boot time and collect audio > > from any user? As discussed before, this is not necessaryly > > needed, JACK could also be started as soon a user logs in. > > But I like the idea that I can have multiple X sessions and > > every of these users can play audio

> > * One problem remains, JACK cannot use different soundcards > > because of the cards quartzes. So, would we have to start a > > seperate JACK instance for each card?

> Linspire (formerly Lindows, then L*nd*ws or something) posted to the > jackit-devel list that they are in fact using JACK as the sound server > for their next release. Let's see how well they pull it off...

The tricky bit is stopping non-RT apps (the bings and bongs apps) from messing up the deadlines for the RT apps. I would be more confortable if they'd made a MAS server (or gstreamer, whatever) that talks JACK, then you only have one non-RT app (the server) that has to be carefully vetted.

But I could not start two sessions for two different users and both having sound support on the same card? OK, thanks, I understood.

Perhaps, some day, jack will be able to run as root and allow different users with priviledges to do so to make connections to it :) .

AFAIR I have heard the users always work as root. I really do not want to support this design.

Jack, Ardour recording what we play, ... comes "soon".  I'm slow, you know.

so what to do if u have a cheap onboard sound (nForce board) that has no hardware mixing capabilities? looks like the following: 1) try to get TS work with aoss. 2) give up. search the internet. try artsdsp. 3) download openal-source via cvs 4) download a patch for openal to use it with ut2004 5) recompile openal with alsa support (need to install libasound2-dev packags before ...) 6) copy the library to ut2004 directory 7) make an .asoundrc file that allows dmixing for artsd and ut2004, and audio input for artsd 8) modify TS startup script so that it will start artsd if not already running, and LD_PRELAOD artsdsp libraries. optional: 9) feel pisssed of about all (arts(dsp) adds some noticable lag to audio!) that and get an audigy2

Lee Revell schrieb: Windows users don't come to this situation. the install windows, install their soundcard drivers, install ts, install ut2004, and thats it- if a windows user gets a "real" soundcard, then due to other reasons, eg. the onboard sound sucks, or he wants to get some extra fps. btw: see step 9) yes, hehe. it would be good if they (TeamSpeak !) would switch to alsa- and in fact they are pretending taht they work on TS3 with alsa support, but until then, no chance. And i guess this will still take some time. a word on the nForce chipset: 1) the original nForce has an DSP built in 2) the nForce 2 with MCP-T southbridge has DSP built in, the MCP doesn't 3) AFAIK, nForce 3 and nForce 4 also lack the DSP but thats not the point. i bought that audigy2, and its a good soundcard, apart from a few issues that will be fixed sooner or later. but what i wanted to say was the following: it's not easy to use for someone thats new to linux- in fact, once i succeeded to convince someone to give linux a try- but he could not get this to work with just 2 mouseclicks. So he switched back to windows :( Thats the point ... if linux should become a desktop alternative, then we definitely need such an `Common linux audio layer`. but: less linux gamers, less games ported to linux :'( there is the ut series, and all stuff from id. but no halflife 2 btw. this was meant as an reply to Dubphil. -tom

what is really the need to give Linux an audio Multiuser OS ? Imagine 2 or more users using the same computer to make music, listen to their video etc

How could you imagine a "Multi user" audio layer integrated into the OS ? audio is not like any other server tasks, you usually have to access the hardware directly by plug in your mic, your midi gear etc... and you usually have to be near the computer in order to listen to the music you are playing... etc so what is really the need to give Linux an audio Multiuser OS ? Imagine 2 or more users using the same computer to make music, listen to their video etc and using the ability from Linux to mix all the stuff, it would be a genious inaudible "cacophony" at the sound card output :)

Hope I'm wrong and I don't understand the mean of this thread :)

This kind of solution has been there for more than 10 years and it's called Open Sound System (OSS). OSS has kernel level mixing features that permits multiple applications to use the same device at the same time (no need to use esd or any other user land layers). And (in addition to Linux) OSS is available for all Unix versions (Solaris, BSD, HP-UX and all others). It's price is $0,00 for home and non profit users.

I get the impression that freedesktop.org are trying to pick/have picked a common lesser-of-the-evils for unix desktops.

Perhaps programmers of current low-level audio apps will feel that they may lose control by approaching this organization. Then again, it might significantly elevate the need of audio in the linux community by utilizing the x.org organization as the vehicle to promote and develop a Unified Audio Driver.

The point is that OSS, whatever version, is not going to be the standard sound layer on Linux, if not for technichal reasons then for political ones.

So the *x community should invent yet another audio driver API (in addition to OSS and ALSA-driver). Isn't the situation already messy enough?

At this moment all Unix vendors (other than official Linux) are already behind OSS. esd works on top of it. artsd works on top of it. Jack works on top of it.

All applications (other than few alsa-* ones) are compatible with it. Even significant part of alsa-lib has been ported to work on top of OSS (this work started just about a month ago). So is there anything that is still missing from OSS?

The current draft of the OSS 4.0 *) specification is available in http://www.fi.opensound.com/developer . If there is something important missing? We can consider adding such features in the near future. Comments are higly welcome.

*) The OSS version included in the Linux kernel as well as ALSA's OSS emulation are based on OSS v3.8 which is almost 10 years old. For this reason they lack all the new features we have implemented during past years.

At this moment all Unix vendors (other than official Linux) are already behind OSS.

If possible, not only speakers. If we could manage to make JACK the common audio layer, then it even would be possible to write a jackclient that takes the audio from an other application and streams it over tha web - live, of course, not simply reading a file. We could play together over the internet :) !

Yes. We have the freedom to choose - but the common user does not want to choose. He simply expects that his operating system can play sound at any time from any application.

If we'd be able to offer a perfect solution, it'll be used by the distributors.

But of course it would need a bit of promotion and 'marketing'. The question is if we are willing and able to drive this; maybe we are not the right people to do so.

But if we do not know how to do it, who else ;-) ? First, we'd need a general idea how to do a common audio layer.

Hmm, some people seem to have the impression that Linux audio is the byzantine beast that it is because Linux users like it that way. This could not be farther from the truth. Many of us are working feverishly to make it "Just Work" the way Mac and Windows do.

Hasn't anyone been listening?  dmix can do this now.  It's a bug in your distro if this blocking behavior is the default.  There's no excuse for it.

As for closed apps using the OSS API, if they won't port their software to ALSA, what makes you think they'd port it to this new API?

Alsaconf frequently fails to do anything useful IME :-(

Lee Revell <rlrevell(a)joe-job.com> writes: Lee, How well does dmix work with JACK? Does it support mmap()?

Yeah yeah, I'm Googling already ...

Last Saturday 08 January 2005 18:53, Lee Revell was like: It might bear a little further explanation. Does anyone have any pointers to useful documentation? If this is the same as the dbus-1 daemon then it's only just made it into DeMuDi and I for one haven't figured its function yet. Yeah yeah, I'm Googling already ... cheers tim hall http://glastonburymusic.org.uk

Furthermore, it's a pity when dmix is only present on some single machines where the user has created an asoundrc file manually. There seems to be an interesting technology, but noone does use it. What about creating a shell script which helps us in creating an /etc/asound.conf resp. an ~/.asoundrc? It'd be great even if distributors woult use it as a backend to install dmix on every machine.

Well, Jaroslav Kysela and Takashi Iwai are both employed by SuSE, as is Matthias Nagorni. I think that might have something to do with it...

At the risk of recomplicating the issue, I guess some complication is a result of the Linux multiuser and networking capabilities.

I haven't used Windows beyond Win95, maybe someone can answer how Windows in the multiuser implementations handles these three situations (are there more):

* If there is more than one user on a machine (each with his own "terminal" (i.e., keyboard, CRT, mouse and *sound card and speakers*), and one of those users starts an audio application, what does Windows do? (Presumably, the right thing is that Windows notes which user requests the application and routes the sound to his sound card/speakers.)

* If there is more than one user on a machine (each with his own "partial terminal" (i.e., keyboard, CRT, mouse, but they *share a common sound card and speakers*), and one of those users starts an audio application, what does Windows do? (I'm not sure of the right thing here, my guess is that the default would be to route the output to a mixer driving the common audio card, with easily accessible options to do things like mute the existing sound output, or mute the new application's output, or ???)

* If there is more than one user on a machine (but the user in question is logging in remotely (as via Telnet, ssh, remote X, or similar), and one of those remotely logged in users starts an audio application, what does Windows do? (I'm guessing that the right thing is to route the audio output back to the remote user (somehow) and not interfere with the audio output of the "local" computer, again with options to route the output to the sound card of the local computer.)

Of course ( ;-) ) for the simplest case, (a single user on a single user machine), the sound application should be default simply route the sound to the (single) (local) sound card, mixing the output with that of any other audio applications, with options to mute either the output of the old sound application(s) or the new sound application.

I guess part of my point is that the "proper" behavior needs to be agreed upon for each of these cases (and others?), before a complete resolution can be developed.

PS: Aside: Until recently, I was a lurker on some of the Xfree86 and (what's the new one, X.org?) mail lists, and one or both of these organizations were considering somehow dealing with audio issues similar to the above. I have no idea how far along they are with such efforts (or whether they've since decided to drop the issues.)

Yeah. Furthermore, a common interface for audio programmers (»Make your application a jack client«) would be great. Normal applications shouldn't access an audio device exclusively. KDE and Gnome will always have an underlaying soundserver. at least for portability issues. That's absolutely OK, as long that their servers talk - maybe - to jack instead of grabbing the device exclusively.

Best regards & thanks for all thoughts ce

I guess it would be very easy to write a jack client which streams audio over a (fast) network to an other machine also running a JACK server. Write this JACK client, plug in your guitar, I'll plug in my synths and we'll try it out ;-) .

On Sun, 2005-01-16 at 08:41 -0800, Mark Knecht wrote: Microsoft claims that the audio system in Longhorn solves this problem. It looks like their solution requires driver & hardware support for mmaping (aka very fast access from userspace) the wall clock and position registers, then they correct for the drift. Of course this certainly involves resampling everything in software. Anyway it's an interesting read. http://download.microsoft.com/download/5/b/5/5b5bec17-ea71-4653-9539-204a67… Lee

They don't match up. The fast machine sends the slow machine 44101 packets, but the slow machine cannot use two of them every second. The slow machine sends the fast one 44099 packets per second but the fast one feels starved for two mare packets that it will not receive.

Sure it's possible.  There are even prototypes people have written.

But it's not "very easy".  :-)

Dropping a video frame is almost invisible to the eye.  Droping an audio frame creates unpleasant audible clicks.

Hmm, some people seem to have the impression that Linux audio is the byzantine beast that it is because Linux users like it that way.  This could not be farther from the truth.  Many of us are working feverishly to make it "Just Work" the way Mac and Windows do.

hi Christoph and list, [ ** mildly longish reactions to the thread follow ** ] I'm a newb on this list, but have been using linux for a while and recently have had some fun and success with linux audio. I consider myself a user, with a technical inclination, and so whenever someone starts talking about "users" I just have to put my piece in. (you are talking about me afterall right?). If you are not talking about me then you begin to see the problem of using such abstract terms to drive the direction of any development. Firstly, I have to say that I run windows, mac and linux in my studio. So I'm not an everyday desktop user, but I'm still a user, yes? (I don't code beyond html and PHP hacking, so I wouldn't consider myself a developer by any stretch). Of these systems, only one has a common audio layer, and that is OSX. Windows has no less than four different audio layers, each employing different technical means to deliver audio to speakers from applications (MMS, DirectSound, ASIO, Giga...). These are driver models I know, and these systems only have a single "distribution" , but my point is, there are different driver models to achieve different things, just as there are different users who want to do different things. It is only recently that in windows things such as multiclient drivers have been released, although directsound has offered software mixing for some time. On the systems that I run, Jack seems to offer to me the best model for managing sound as it allows a single point of call for most configuration without over simplifying things to the point of excluding me from whats going on underneath. Jack on osx has brought a little of that flexibility to my preferred graphical environment, and I like what it has brought. My point here is that Jack in itself, to me, is something that linux has that is (or was, until the osx port) both unique (and hence marketable), technically versatile and well thought out, and can also offer users a single point of call for most audio system configuration. Another point I would make is about the things that attracted me to linux in the first place. They are - it's free to download, install and run. One of things that makes it so is that its development is driven by volunteers as much as by organisations, and the volunteers are also users. The more linux would become reliant on capital investment to fund development, the more those investors are going to expect a return on their investment. I would honestly rather a system that requires me to learn (heaven forbid!) but remains economically accessable, than a system that is technically beautiful but prohibitively expensive (osx anyone?). Linux also allows me to learn more about the technicalities underlying the applications I use rather than just giving me some monolithic working environment that someone else decided was good for me to use. If I wanted a desktop environment that just works for daily use out of the box I would choose OSX, or if on a budget and forced by gunpoint, windows. Linux offers something different, and I don't see the advantage of trying to make it all things to all people. It's obvious the linux development community doesn't have the resources to offer a one size fits all approach, at least not to perfection, and as suggested by the Linspire example, individual distros can offer unified audio subsystems by including only applications that talk to the sound server of choice included in that distro. Hence users can make the choice that suits them best, and learn to fill in any gaps along the way. The choice is there to make, and I'm glad for it, as it offers me the chance to learn about the technical alternatives and hence make more informed choices, and also learn more about what might consitute 'good' computing techniques as opposed to having to accept the mandated from above techniques offered so as to keep the "average user" happy. My point is I guess, rather than trying to imagine what it is that everybody else wants, and going on a crusade to conquer the desktop world with linux, I think it best to decide what I want, and find the best way to implement that and be happy. Hey, it's free after all! I've tried in the past to get all advocacy with linux and switch friends and family to use it, mainly because I believe in the politics of FOSS, but ultimately they stick with windows precisely, as has been stated here, because it works out of the box. Even if Linux could do the same (work out of the box, in whatever sense) that in itself offers no real incentive to an average user because they don't tend to care about the ethics of their operating system choice. Sad and unfortunate, but true. I know people who refuse to eat McDonalds but still can't see the moral dimension of computing. Why would they switch from something that works to something that works if the second something that works means they have to learn a new computing environment? If they didn't have the learning curve, that would mean Linux and Windows would be indistinguishable, and frankly, I didn't start using linux because I wanted a windows clone and that is the last thing I would want it to become. Windows is developed with the user in mind, or rather, with the intention of appealling to as many users as possible, as this is the ideal economic model for mass industrialisation. Personally, I think rather than pursuing a user driven, mass commercialisation agenda, linux should be pursuing the path of technical ingenuity, ethical computing, and better computing practice. That to me means diversity, and the ability for users to choose the distro that is molded best to suit their individual needs. I'm not really sure their is such a thing as a common or average user except in market demographic reports and profit forecasts. I'm not arguing against broadening the appeal of linux as a desktop computing environment, but I just don't think that is linux' strength or needs to be, and I certainly don't think that should be undertaken if it undermines the things that distinguish linux from the competition. It is possible to create a large user base from a collection of niches rather that a single "user", single "linux" type solution. anyway, that's my piece done. I don't mean to sound dismissive of your call for a Common linux audio layer, as I think it is a start at defining just where linux might head in the long term. I just think, if someone wanted to roll a distro that had this, the technologies are already there to do it - just restrict the user to use the apps that suit such a unified vision. Restrictions are after all what makes windows "easy to use". I wouldn't however, wish to place restrictions on existing distros by mandating that they must ALL use the same, and hence common, audio layer for the distributions. Perhaps what you are calling for if the same thing that Linspire, or Sun with their Java Desktop thingimy are trying to do, and that is a common-user-centric (cuc!) distribution that is conifgured to run out of the box. What I think both these distros/environments have in common is that have a fairly well conceived user in mind. That isn't me. This user, being me, is quite happy, if not impressed with the current solutions available in all their diversity, strengths and weaknesses, and all things considered wouldn't want my linux any other way. best regards Michael Noble