ALSA 1.0.25 Is Out With Many Linux Audio Changes

[RealNC]

There are few applications that don't actually allow changing just their own volume, all KDE applications allow this (because they use Phonon), while most games use either OpenAL or SDL. The only thing alsa could do (and what Pulseaudio does now) is to provide a unified extra layer that does this adjustment and provide a centralized way to adjust the volume for all running applications.


The extra layer must exist, if it were included in ALSA

It's already there. It's called "dmix." What it lacks is runtime control of volumes for each incoming stream. Right now, dmix takes the streams and resamples them if needed, and then mixes them together and sends the result to the audio driver. What it should do in addition to all that, is adjust the volumes of each incoming stream before doing the mixing and also export the streams at mixer controls. There's no new layer needed at all! It's a matter of extending what is already there.

OSS4 does this like that. It does not use some weird sound server or something similar. It all happens in the mixer.

[geearf]

Still no LPCM multichannel audio for Radeons HDMI output I am guessing :/

[Ansla]

It's already there. It's called "dmix." What it lacks is runtime control of volumes for each incoming stream. Right now, dmix takes the streams and resamples them if needed, and then mixes them together and sends the result to the audio driver. What it should do in addition to all that, is adjust the volumes of each incoming stream before doing the mixing and also export the streams at mixer controls. There's no new layer needed at all! It's a matter of extending what is already there.

Pulseaudio accesses the card directly, not through dmix. So yeah, the code is there, but it could as well be removed and Pulseaudio or other sound server made mandatory. And again, the "killer feature" of Pulseaudio is changing the output device at runtime. This could be done in the kernel, but it would be ugly. And now all computers have at least 2 sound cards (the one built into the motherboard and HDMI/Displayport) plus many headphones having a USB card instead of regular jack this feature is becoming very important.

OSS4 does this like that. It does not use some weird sound server or something similar. It all happens in the mixer.

As I said, it's possible to do it in the kernel, but it wouldn't provide any real benefit over a user space implementation. And having complex code in the kernel that could have very well be implemented in user space is just asking for trouble, think of the security implications of a bug in kernel space versus one in a user space server with no special privileges (/usr/bin/pulseaudio used to be setuid, but no longer requires that).

[DanL]

Okay, alsa-utils was using the old ALSA include files (libasound2-dev). Once I removed that package, everything compiled/installed. You still need to build/install alsa-lib before alsa-utils.

[RealNC]

Pulseaudio accesses the card directly, not through dmix. So yeah, the code is there, but it could as well be removed and Pulseaudio or other sound server made mandatory. And again, the "killer feature" of Pulseaudio is changing the output device at runtime. This could be done in the kernel, but it would be ugly. And now all computers have at least 2 sound cards (the one built into the motherboard and HDMI/Displayport) plus many headphones having a USB card instead of regular jack this feature is becoming very important.


As I said, it's possible to do it in the kernel, but it wouldn't provide any real benefit over a user space implementation. And having complex code in the kernel that could have very well be implemented in user space is just asking for trouble, think of the security implications of a bug in kernel space versus one in a user space server with no special privileges (/usr/bin/pulseaudio used to be setuid, but no longer requires that).

I don't see why you assume it has to be in the kernel. dmix and libalsa are entirely in userspace. Doing per-application volume with dmix does not require kernel code, since neither dmix nor libalsa run in kernel space.

[liam]

What you are describing is bad interface design for the application you are using. With Amarok I just place the mouse cursor over it's icon in systray and use the scroll wheel to adjust the volume in real-time. Also for most KDE apps you can set global key shortcuts to adjust the volume if you prefer to use the keyboard. Pulseaudio could not make it easier that this.

That seems like a bad design decision. For one thing, it isn't obvious that the functionality is there;it seems as though you'd have to scrub for it. Second, it's not clear what scrolling the wheel should do. It could just as easily move to the next track/ff in the current track/change playlists/toggle repeat/basically any linear functionality. If all systray icons had that functionality it would make more sense (but scrubbing is still a bad thing for interfaces) but they clearly don't all even have the volume property. If you clicked on the systray button and a small dialog popped up with volume as a control and then you hovered over the volume area then using the scroll wheel makes sense.
Regardless, knowing KDE I assume you can set the functionality of the scroll wheel on hover, right? That at least gives the user the option, but, by default (and IMHO), you should have to click the icon. That makes things consistent.

[Ansla]

I don't see why you assume it has to be in the kernel. dmix and libalsa are entirely in userspace. Doing per-application volume with dmix does not require kernel code, since neither dmix nor libalsa run in kernel space.

Hmm, you're right, dmix is in libalsa, only OSS has vmix in kernel. That would indeed make it relatively easy to implement all Pulseaudio functionality in libalsa, including changing default output device or any other config option at runtime.

[Ansla]

That seems like a bad design decision. For one thing, it isn't obvious that the functionality is there;it seems as though you'd have to scrub for it. Second, it's not clear what scrolling the wheel should do. It could just as easily move to the next track/ff in the current track/change playlists/toggle repeat/basically any linear functionality. If all systray icons had that functionality it would make more sense (but scrubbing is still a bad thing for interfaces) but they clearly don't all even have the volume property. If you clicked on the systray button and a small dialog popped up with volume as a control and then you hovered over the volume area then using the scroll wheel makes sense.
Regardless, knowing KDE I assume you can set the functionality of the scroll wheel on hover, right? That at least gives the user the option, but, by default (and IMHO), you should have to click the icon. That makes things consistent.

Indeed it's not easy discoverable, but once you found out about it's very useful. And it's consistent with kmix, where scrolling over it's systray icon will change the master volume. Clicking on the icon will bring the full Amarok interface and there is indeed a volume control in the upper-right corner that you can scroll over. And no, the behavior is not configurable, it's hard-coded to change the volume on scroll.

[RealNC]

Indeed it's not easy discoverable, but once you found out about it's very useful. And it's consistent with kmix, where scrolling over it's systray icon will change the master volume. Clicking on the icon will bring the full Amarok interface and there is indeed a volume control in the upper-right corner that you can scroll over. And no, the behavior is not configurable, it's hard-coded to change the volume on scroll.

Since you talk about "consistency", doesn't anyone here think that adjusting volumes somewhere other than KMix isn't consistent? If you really value consistency, then applications should be controllable through the place that deals with volume: KMix. Anything else is not really consistent.

Also, if every application out there creates a systray icon from which we can control its volume, then why would we need a task bar to begin with? Wouldn't it make more sense to register a KMix slider for volume control purposes?

[djdoo]

5.1 Surround Sound...

Guys really I think a discussion about a complete sound framework in an operating system to be dominated about a subject like that you are debating here, I refer to the pulseaudio stuff about every app getting a private slider, I believe is terribly unfair for the job of the developers and not affiliated with ALSA development at all... Pulse Audio is a different project which I personally think is not that important...
ALSA should be judged as a sound framework and the features that encloses meaning:
-> Sound Quality (full support of all sample rates and frequencies hardware has to offer)
-> Low Latencies
-> Usability of Hardware Connections
-> Professional Usage Abilities
-> Proper Multichannel Audio Reproduction
-> Full Featured Drivers
-> New Technology Support (HDMI, DspPort, Blu-Ray, Positioning Audio for 3D games etc.)

For example one feature that is missing for a proper multichannel sound reproduction on a 5.1 speaker system with small satellite speakers and a subwoofer is the Bass Management. Sending all low frequencies to Subwoofer from the other channels.
This requires a software Crossover Filter and Rerouting plugin let's say. Well nothing shows in the horizon about this feature.(correct me if I am wrong here...)

Believe me guys if you are trying to judge the quality of ALSA and as a result the work of ALSA developers with a laptop better think again... I know many small portable radios reproducing better sound than many laptops...