Page 4 of 4 FirstFirst ... 234
Results 31 to 40 of 40

Thread: ALSA 1.0.25 Is Out With Many Linux Audio Changes

  1. #31
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,791

    Default

    Quote Originally Posted by Ansla View Post
    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.
    Last edited by RealNC; 01-26-2012 at 03:42 PM.

  2. #32
    Join Date
    Dec 2011
    Posts
    81

    Default

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

  3. #33
    Join Date
    Oct 2010
    Posts
    311

    Default

    Quote Originally Posted by RealNC View Post
    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.

    Quote Originally Posted by RealNC View Post
    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).

  4. #34
    Join Date
    Oct 2007
    Posts
    1,275

    Default

    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.

  5. #35
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,791

    Default

    Quote Originally Posted by Ansla View Post
    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.

  6. #36
    Join Date
    Jan 2009
    Posts
    1,404

    Default

    Quote Originally Posted by Ansla View Post
    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.

  7. #37
    Join Date
    Oct 2010
    Posts
    311

    Default

    Quote Originally Posted by RealNC View Post
    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.

  8. #38
    Join Date
    Oct 2010
    Posts
    311

    Default

    Quote Originally Posted by liam View Post
    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.

  9. #39
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,791

    Default

    Quote Originally Posted by Ansla View Post
    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?

  10. #40
    Join Date
    Sep 2007
    Location
    Athens-Hellas
    Posts
    255

    Default 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...

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •