Bug 222157

Summary: Allow KDE to share audio with other applications by enabling dmix
Product: Red Hat Enterprise Linux 4 Reporter: Matt Seitz <matseitz>
Component: alsa-libAssignee: Martin Stransky <stransky>
Status: CLOSED WONTFIX QA Contact:
Severity: low Docs Contact:
Priority: medium    
Version: 4.0   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-01-11 09:52:33 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
My .asoundrc file to enable dmix none

Description Matt Seitz 2007-01-10 18:30:37 UTC 
Description of problem:

If a KDE application is playing audio, non-KDE applications are blocked from
using audio.  This can be worked around by adding an ~/.asoundrc file to enable
dmix (see attached).  It would be easier if dmix were just enabled by default.

Version-Release number of selected component (if applicable):

alsa-lib-1.0.6-5.RHEL4

How reproducible:

Always

Steps to Reproduce:
1.  Start playing an audio file using "noatun"
2.  Go to http://news.com and play a Flash video.

  
Actual results:

The audio for the Flash video cannot be heard.

Expected results:

The audio from both "noatun" and Flash should be heard.
Comment 1 Matt Seitz 2007-01-10 18:30:37 UTC 
Created attachment 145273 [details]
My .asoundrc file to enable dmix
Comment 2 Matt Seitz 2007-01-10 18:43:18 UTC 
It looks like this may be fixed in a later build of alsa-lib.  Any chance of
either releasing this build for RHEL, or backporting the fix?

* Sat Apr 23 2005 Martin Stransky <stransky> 1.0.9rc2-1
  - updated to 1.0.9rc2
  - add ainit tool 
  - dmix is now default pcm device
Comment 3 Martin Stransky 2007-01-11 09:52:33 UTC 
(In reply to comment #2)
> It looks like this may be fixed in a later build of alsa-lib.  Any chance of
> either releasing this build for RHEL, or backporting the fix?

I don't think so, there're more important updates for RHEL-4 and number of the
updates is limited. It works out of the box in RHEL-5 and all Fedoras since FC4.
Comment 4 Matt Seitz 2007-01-11 17:49:29 UTC 
Given how close we are to RHEL 5, I can understand that this would be a low
priority for backporting.  Thanks for your quick response.  

For RHEL 4, is there a recommended workaround?

Just curious:  if this is fixed in RHEL 5, why was this marked "WONTFIX" instead
of "NEXTRELEASE"?  Would "NEXTRELEASE" imply this would be fixed in an RHEL 4
Update or Errata?  I'm just trying to understand what the Red Hat Bugzilla
"Resolution" values mean.
Comment 5 Martin Stransky 2007-01-12 09:16:36 UTC 
It's not going to be fixed in any new update of RHEL-4 so I closed is as a
wontfix. But I think NEXTRELEASE could be used here, too.

as a workaround, check the latest ALSA drivers/packages for RHEL-4, here:

http://people.redhat.com/stransky/alsa

(or you can use rpm packages provided by ATrpms and so on)