If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

As far as I know, ALSA is Linux-specific while OSS is available on a wide variety of platforms. Portability-wise OSS is better. Are you volunteering to address that?

ALSA = Advanced Linux Sound Architecture
OSS = Open Sound System
So yes, OSS is the way to go - even if many devs will hate you for that (back)move (ever tried to get OSS(4) support into software supporting ALSA without coding it for yourself?).

The same could have been said when ALSA and PulseAudio were made.

For ALSA: No!
For PulseAudio: Yes, and it has been said million times.

It is a perfect reason.

It's not. Patching ALSA/PA or (even better) lobbying OSS4 would be far more useful. But all in all you are right by saying:

The only stupid thing here are the people that try to tell others how to spend their time.

So I don't want to get into detail here.

ALSA is an API. if sound drivers require it, then they are poorly designed.

ALSA is a architecture, containing a internal kernel API used by the drivers (so they have to require it!), a userspace API and userspace tools (alsa-tools/PulseAudio).
So of course drivers require ALSA. You can't use OSS drivers for ALSA nor ALSA drivers for OSS.

The same could have been said for OSS when those were in development. Where were you then?

Again: No.
But this time I'll tell you why not:
You know that the kernel is GPL licensed, right? Now OSS(3) was GPL licensed, too (and BSD and whatnot) so it wasn't a problem to include it into the kernel and everybody was happy. But then the company behind OSS started with OSS 4 which was proprietary licensed only. This was the reason ALSA was developed. Other unix like OSes continued to use (forks of) OSS3.
Later on the company GPLed OSS4, but it was too late.
PulseAudio on the other side was just some kind of e-penis measurement Poettering seems to need from time to time (his next big thing is systemd *cough*, well, now I have to go into detail cause I'm raging... see OFF-TOPIC).

BTW: Are you really the dev of this? I can't find a prove other than you acting like it. Also: Any news on this?

[OFF-TOPIC]http://linuxfr.org/nodes/86687/comments/1249943
Question: "What are the advantages of ALSA/PA versus OSSv4 ? Why do you think the BSDs still use OSS instead of reimplementing ALSA/PA ?"
His answer doesn't even include "ALSA", he's only talking about OSS.
Question: "Systemd use a lot of Linux only technologies (cgroups, udev, fanotify, timerfd, signalfd, etc). Do you really think the Linux API has been taking the role of the POSIX API and the other systems are irrelevant ?"
His answer, shortened to the most important part: "Yes"

With friends like Lennart Poettering linux doesn't need enemies anymore. From systemd to PulseAudio to binary logs and incompatibility to BSD ("irrelevant", orig. quote L. Poettering). All we can do is facepalming cause of all the stupid ideas which are slowly being implemented - bad.

Comment

[OFF-TOPIC]http://linuxfr.org/nodes/86687/comments/1249943
Question: "What are the advantages of ALSA/PA versus OSSv4 ? Why do you think the BSDs still use OSS instead of reimplementing ALSA/PA ?"
His answer doesn't even include "ALSA", he's only talking about OSS.
Question: "Systemd use a lot of Linux only technologies (cgroups, udev, fanotify, timerfd, signalfd, etc). Do you really think the Linux API has been taking the role of the POSIX API and the other systems are irrelevant ?"
His answer, shortened to the most important part: "Yes"

What a glorious collection of cherrypicked BS! I applaud your efforts.

"Question: "What are the advantages of ALSA/PA versus OSSv4 ? Why do you think the BSDs still use OSS instead of reimplementing ALSA/PA ?"
His answer doesn't even include "ALSA", he's only talking about OSS."
He was asked for advantages between ALSA/PA vs OSS stacks. So he talked on shortcomings of OSS. He could have talked on advantages of ALSA. It is different sides of same coin.

"Question: "Systemd use a lot of Linux only technologies (cgroups, udev, fanotify, timerfd, signalfd, etc). Do you really think the Linux API has been taking the role of the POSIX API and the other systems are irrelevant ?"
His answer, shortened to the most important part: "Yes""
His answer, shortened the way it does not damage the meaning, unlike your short troll answer, is: "Yes,..I just don't think it's really in our interest to let us being held back by them (non-Linux) if we want to make sure Linux enters the mainstream all across the board "

"And let's not forget that this guy wants to kill distributions: http://derstandard.at/1342947866275/...icht-fuenfzehn (couldn't find a English translation)."I know german pretty well and he does NOT want to kill distributions.
He wants to kill the system reinvention in the distributions, so distributions focus on delivering software and not on rewriting own versions of time setting.

I think you are a HUGE troll. Lennard made A LOT for linux. You have not.

I think, you are also BSD TROLL.
Because you don't like single point - a freedom protecting GPL, and this way refuse to take Linux and want Lennard to support your BSD thief system, otherwise you start calling him names, cherrypicking articles and falsifying his speech.
Lennard is fscking HERO for Linux and he does A LOT to make Linux mainstream system. It is HIS choice to focus just on Linux. The software is free, so go ahead and port it to/help working on your BSD. Pottering does not own you anything.

Comment

I would love to have sound management on par with OS X. My current plan is to build a hackintosh; got all my parts picked out already. I'm going to do it anyways, but it's nice to know there may be hope for people using Ardour and whatnot on linux-based desktops.

As long as it works WITH PULSEAUDIO, userland applications shouldn't have any compatibility problems.

Comment

Comment

meh, I'm going to switch to OSS, because I'm sick to hear cracks when changing the volume under VLC or Audacious even though I bought a cheap high end sound card (Xonar DX). But I don't know if it will be actually better .
Also, should I keep pulseaudio (maybe needing manual configuration)?, this is so confusing (though OSS does per app mixing already, which is a feature you use once in a blue moon because of a flash object with no volume control)

Really, KLANG would be interesting because you would have everything in one place (as with OSS)
I read a slashdot post not long ago, of someone boasting he added custom features by manually configuring ALSA, to make a point you couldn't do this in PulseAudio. Something like being able to use a sound card's second stereo ouput as a second stereo output. Also, he pointed there was no GUI and sounded like it was making him feel elite.
This is all ridiculous, we'd be better with just one system that does everything, and there would be a GUI to help you map hardware outputs, sources and let you add gains, filters and whatever in the way you like it.
And please I don't want tiny sound cracks when changing the volume with the scrollwheel in a music player.

I feel like upgrading to Windows 8 instead, it's sad that things were better when I had a 5€ used sound blaster with kxdriver under windows XP.

Comment

meh, I'm going to switch to OSS, because I'm sick to hear cracks when changing the volume under VLC or Audacious even though I bought a cheap high end sound card (Xonar DX). But I don't know if it will be actually better .

How about addressing the issue instead? Please head on to Archlinux article on Pulseaudio and check the appropriate paragraph. Especially pay attention to default mixing hz and buffer sizes. The issue was originally present on LMDE and this irons it out. There is also a documented issue with audio drivers that is exposed by PulseAudio, so its also worth trying out.

It is also advisable to disable flat volumes if you want Pulse to consistently remember and maintain individual application volume.

Also, no one is preventing you to configure ALSA manually and use both Pulse and ALSA at same time. This won't be possible with AiO solution.

This is all ridiculous, we'd be better with just one system that does everything, and there would be a GUI to help you map hardware outputs, sources and let you add gains, filters and whatever in the way you like it.

Comment

I think there is one really good point in this article, and that is lowlatency with bigger buffers. If you have small buffers, that alone will make the app consume 4x CPU. And we are moving towards 0.2ms latency, which I think after, nobody will care for less. Currently 0.3ms latency is possible in the standard kernel, with realtime threads. I have tried it, with firewire, and it worked well. But the CPU usage is extreme.

Also if you have ever had a soundcard, that allows routing, between applications (virtual drivers routed in a mixer), you know that is nice functionality to have.

Easy to do systemwide highpass, EQ, limiter etc.

A complete and efficient mixer solution, optimized for low latency (down to 0.2ms), would be very nice.

And why not try and do a good plugin standard while one is at it. LADSPA isn`t that good. Maybe later plugin-developments are better though. But an all round high-level mixer/plugin/routing/low latency driver audio subsystem, for all apps to use for mixing, would be good.

Also, I have a minimal jitter kernel, for OpenGL. It would be very nice if it was as compatible as possible with that.
It currently does 1ms latency stable on a core2duo 2.5ghz. 0.3ms has only a few clicks. Compatibility would mean excellent OpenGL performance, along with developments on low-latency audio.

If redoing an audiosubsystem gives 0.2ms latency, with less cpu, I am all for it. And I think it`s good that it is compatible with ALSA, OSS, also, so it can be a transparent replacement.

And btw, the suggestions of many here about RT-kernel do suppose that it works everywhere, which it doesn`t. Also since the current mainline is so good at latency, it seems RT nolonger is neccesary, even for 0.3ms.

And remember audio is one of those things that doesn`t tolerate osjitter and latencyspikes. Clicking is not good. So special considerations should be made for it.

Also, ofcourse one should have some good software, that people actually use for this. I always wanted to be involved in a project, doing some kind of opensource sequencer, inspired by Logic Audio, but with the more compact design of Renoise in mind. Current software is archaic, so if anyone is interested in this, contact me. I have also done world-leading DSP, (sourceforge pxu). So mastering effects is mostly already done. (And better than the best on windows, such as waves etc.)

Peace Be With You.

Comment

And why not try and do a good plugin standard while one is at it. LADSPA isn`t that good. Maybe later plugin-developments are better though. But an all round high-level mixer/plugin/routing/low latency driver audio subsystem, for all apps to use for mixing, would be good.

I think very few people (aside from yourself) are still writing plugins using LADSPA. it's much more common to see LV2 and VST these days.

And btw, the suggestions of many here about RT-kernel do suppose that it works everywhere, which it doesn`t. Also since the current mainline is so good at latency, it seems RT nolonger is neccesary, even for 0.3ms.

I've never read a single post in the phoronix forums claiming that RT works everywhere. In fact, anyone whom follows the RT-user-list would know better than to say that... RT is about having a very deterministic, realtime, low-latency system. While it is somewhat easy to tune a standard kernel or a BFS kernel for low-latency, there are many situations where RT is more suitable (especially when it comes to 'industrial' uses and certain types of embedded usage). But even on my system my RT-kernels works better than your 'low-latency' 3.5.4 kernel. ie: i get zero xruns with 3.4-rt ~ while with your kernel i got dozens of xruns. Under heavy CPU load your low-latency kernel doesn't meet it's deadlines, where as RT does. The situation is made even worse, ie: even more xruns (using generic or your low-latency kernel) if i happen to be doing a lot of compilation + running a VM or openGL apps while running Jack + applications/clients. This isn't a problem at all using RT.

If you read the last page of the PDF you would see that this work is on going. the parts i have marked in bold, sum up Intel's plans with this. port their code to kernel 3.5, then post the code to netdev in the fourth quarter of 2012.

Originally posted by from Intel PDF

Current work
• Work in progress includes
−Further simplified driver using a polling thread
−Port of the current code to v3.5
• Future work
−Post current v3.5 code to netdev (Q4 – 2012)
−Design and refactor based on comments
−Make sure new flow is measurable and debuggable

but note: this code is for the networking stack, only. Not some universal approach to reducing latency across linux kernel subsystems. - but it doess look to be a worthwhile endeavor, imo.

Also, ofcourse one should have some good software, that people actually use for this. I always wanted to be involved in a project, doing some kind of opensource sequencer, inspired by Logic Audio, but with the more compact design of Renoise in mind. Current software is archaic, so if anyone is interested in this, contact me. I have also done world-leading DSP, (sourceforge pxu). So mastering effects is mostly already done. (And better than the best on windows, such as waves etc.)

I agree that linux could use a decent sequencer or two, but as far as having a 'logic' like sequencer, OOMIDI has a similar layout. But in reality, none of the OSS sequencers or DAWs are going to be comparable or as good as Bitwig studio will be. I think we will see a huge drop in people using other software (such as qtractor, ardour3, etc) when bitwig is released for linux - they just can't complete in features, layout, etc.

While i do enjoy some of your posts, i do have to point something out here (that your probably not going to like me saying). I have used your plugins and i can tell you right now - they don't touch the quality of Waves, T-Racks or any other (professional) plugin/mastering suite for Windows or MacOSX. For one, you have designed and optimized your plugins for 44.1khz ~ which automatically makes them inferior, being how no one in the proaudio industry is tailoring their software for such low sample rates, being as 96khz (or higher) tend to be what most people are using / more standard.... thus your plugins are not 'world-leading DSP'. Even on the GUI side - they look less than professional. I think you are letting your ego convince you they are the best, but that is absurd - no offense... That being said, i am not trying to discourage you, as i think they have potential - but the first thing i would do if i were you is drop LADSPA and port them to VST or LV2 (although VST would be more portable, i think).

cheers

Now as a more general note:

has anyone actually seen any source code for KLANG, is their even access to (working) code?

Comment

Amazing how full of shit people can be. You are getting underruns with this kernel, lol. Maybe it is time to upgrade your soundblaster, and pull the shit out of your ears, and realize waves is shit compared to what I do.

If you had any clue on DSP at all, and ears, you would know. And I can go into details about algorthm.