KDE-Forum.org

This is not decided yet.

There are a couple of threads with discussions about this topic in the archives of the kde-multimedia mailinglist.

Cheers,
_

kdemm will be able to use gstreamer, xine, helix, ...

You will have choice !
But i think gstreamer will be the default...

I too think you'll be able to choose what you want.
And this is just my guess, it's not a fact.

Quoted

Originally posted by gnumdk
kdemm will be able to use gstreamer, xine, helix, ...

You will have choice !
But i think gstreamer will be the default...

kdemm will cover the basic stuff, like a game needing a simple way to say "Play that sound file for me." and it can forget about the rest. For advanced control over the sound output the app will still need to know about the specifics of the underlying sound system and thus it won't be switchable unless the app supports more than just the default system.

PS: As far as I know NMM (http://www.networkmultimedia.org/) and MAS are on that list, too.

I hope whatever we do, that it clears up the mess we have right now in Linux et. al. audio support.

With oss, alsa, artsd, "legacy support", and the "collective" distribution of audio software --- this rich diversity causes LOTS of configuratin and inter-operation problems.

We need a hard and fast standard, that provide superior native facilities, seamless legacy support, and accesability(sp?) for other audio standards. artsd provides that, and has an unbelievable power over the processing of audio signals, but it suffers from an issue of rank, rather than ability and openess.

Regarding my experience in GNU/Linux, as a KDE user, we have oss, alsa and artsd each working separately, but cooperatively. My understanding is that oss is supposed to be on the wane (like cobol), alsa is now the suggested audio facility, and that artsd abstracts either or both of those into a virtual device, "routed" in software and rendered to the actual audio device.

Except it's a first come, first serve contest of happenstance between these methods. It is a fragile arrangement, frought with mis-configurations between the participants. If we could get artsd in as a module, or even part of the kernel, participating as it does now --- a sudo audio device, then artsd configuration would be a "kernel level" matter of configuring the "audio device operating subsystem (ados)", abstracting it from regular audio configuration complications. We could then have native KDE hooks into the ados, with advantages, while also providing support for any other device expectation. Where inter-process communications are needed, ados/KDE hooks could provide that --- even where other system wouldn't normally inter-operate.

And THAT would gather LOTS of useful attention to KDE.

Frankly, I think the job before us is to fix the factor of programs dispersed in time and method, rather than developing any particular audio system. KDE4's new audio system needs to address these divergent audio methods and their conflicting default configurations. Audio render has LONG been solved.

David Weeks

Quoted

Originally posted by dkmweeks
If we could get artsd in as a module, or even part of the kernel, participating as it does now ...

Arts is already dead and on its way out. It had exactly one maintainer who quit some time ago so don't expect any more development (maybe some bugfixes, but nothing more).

Sorry about that. It explains a few things, though.

Regardless, I like the idea of a kernel level application, like tux or netfilter, on which we can lay and mix legacy methods, a new KDE method, and allow for future methods.

Given the ease of module aliases, would it be hard to go between current audio modules, and applications that call on them?

What I'd like to see is a better system of autonomous configuration. What we have now is hard to configure, and very easy to break.

It's too bad about artsd. I liked it. I think it has great potential.

And thank you, all, for your work on this. I'm a systems integrator, so there's my bias on this issue. I'd have nothing, though, without you guys. I'd rather mow grass and pull weeds then work with Micro$oft.

David Weeks,
Tampa, Florida, USA.

Quoted

Originally posted by dkmweeks
It's too bad about artsd. I liked it. I think it has great potential.

It was the best available solution for the KDE desktop at the time it was adopted. But it had its problems, too, that could not be solved, like high latency. That made it unsuitable for some applications.

No doubt that the next solution will be even better because the knowledge of what's important has grown. Both gstreamer and NMM look promising.

One of the problems of aRts was that it was extended beyond its intented usage (synthesizing) and used as a sound mixing daemon.

Next generation sound systems stay what they are supposed to be and let something at system level care about joining output from different applications.

Either by letting a sound mixing daemon, a driver or the hardware handle the actual stream joining.

Assuming that ALSA is always able to do this it will remove the need for a sound daemon in Linux, other platforms KDE is deployed on might still need a daemon as a fallback (possibly jackd)

Actually this should already work to some extend, i.e. KDE applications sharing artsd but having it output to ALSA and all other applications as well.

Cheers,
_

Latentcy is (was) a problem. I always have to offset mplayer to watch stuff.

Yet, a kernel level version of artsd (and I'm no champion of any particular thing), or something like it, would no doubt deal with that latentcy. Unix/Linux is not so good with real time stuff, never has been, but abstracting into the kernel would bring VERY efficient access to everything, and "kernel" level and class of peer review (kernel.org) would be helpful.

I like the idea of mixing at the bottom level. Its a natural "choke point" in the system, and best dealt with at the bottom. The OSI network stack is a great point of reference. Audio/video feed is a real-time requirement. Kernel level processing is our current best answer to those requirements. The protocols of audio/video encoding are many, and emerging still (h.264). Layering down to a kernel level facility sensibly abstracts those protocols. IE: ^.*$ >> ip (4/6? who cares?) This is a streaming data issue, and we've been here before.

Thanks for letting me participate.

David Weeks

I thought that kernel 2.6 brought latency downto something much better than before.
artd is launched in the real time process priority. Combined with kernel 2.6, can't buffer sizes be decreased to have acceptable latency?
Maybe these buffer size are now set in a way that it works on both 2.4 and 2.6 kernels, explaining why there is latency.

The problem with the kernel module is that it is more complicated to deploy. It will take more time to get in all distributions than a user application.

Too bad arts is dead. Whatever the new solution, it should have a backward compatibility will all existing APIs including arts...

Quoted

Originally posted by sophana
Too bad arts is dead. Whatever the new solution, it should have a backward compatibility will all existing APIs including arts...

That's why the aRts removal has been delayed for KDE4.0. because earlier is not possible due to compatability requirements.

Cheers,
_

Why don't KDE use ALSA? ALSA supports hardware synthesis instead of software. If aRts can use ALSA just like xine, xmms, gaim, and mplayer, aRts won't occupy the /dev/dsp resource and will reduce latency. I was using Gnomemeeting and skype. They both conflicted against aRts. Putting aRts in the kernel might cause too much work but putting aRts on top of ALSA could make things easier. However, the maintainer of aRts has quit, so there's no way it will happen.