The state of the Linux/Unix application audio subsystems remains a mess of competing interfaces and audio mixer and networking demons.
Proposal: Rationalizing Fedora Audio
For Linux alone, there are many applications that still directly use the OSS interface, and will do so for the foreseeable future. Hacking the Fedora Core setup is more possible than fixing all the applications.
There are a number of competing audio mixing demons that can be running by the user at the same time: Esound's esd, KDE's arts, and the Freedesktop's proposed MAS ( http://www.mediaapplicationserver.net/ ). The first two demons available on FC3 default to using the OSS /dev/dsp /dev/audio etc interfaces, competing for use of the /dev/dsp, hogging the audio output.
Even using the ALSA interface, Fedora defaults to sending/receiving applications audio direct to the hardware device, hogging the interface. By default audio output could go to ALSA or better yet a Dmix plug, where the source and destination could be selected and mixed together.
It's possible to get OSS, esd, arts and ALSA working together better with a little configuration... http://alsa.opensrc.org/index.php?page=Dmix+Kde+-+arts%2C+ESD+and+SDL+quick+... FC3 final, or the next release of Fedora Core/Red Hat after that, should do something similar in the default setup.
The default pcm ALSA interface and /dev/dsp should be assigned to a type dmix. HAL/udev should assign hardware sound devices ALSA hw:X and OSS /dev/dspX etc ( with X starting at 1 not 0 see below ). By default the output from first dmix could be piped to the first or owner selected device.
The user should also be provided with command line and GUI interfaces to HAL/udev add and remove dmix devices on the fly and select where the output goes to. The volume for each virtual device should be set at 50% by default. Virtual mixer interfaces would also be created by default, and the interface would show up in the gnome-audio-mixer. This would be great for recording content and for Multiuser systems.
Future proposal : Multiuser/Mixcasting audio - /dev/dsp like /dev/tty
At the moment LTSP and other remote-X servers use ESD,NAS and in the future MAS demons to stream audio over the network. If your the only user assigned to a /dev/dsp it is also sometimes possible to capture the output to OSS and directed to the sound demon. The major problem with this is that the first user to log on gain full ownership of the audio devices, sharing is difficult.
One solution is to hack the kernel ALSA so that hw:0 and /dev/dsp are assigned on the fly depending on the UID of the process much the way /dev/tty is assigned on the fly to the caller process's current /dev/ttyX. HAL/udev could assign numbered dmix type ALSA devices to each user and and the sound demon would be free capture the output.
Even for single user systems, you could use "Xnest -query :X" to log in as a different user and capture all the auto to stream it out or record it to a demo or audioblog.
Hi.
David Mohring heretic@ihug.co.nz wrote:
Even using the ALSA interface, Fedora defaults to sending/receiving applications audio direct to the hardware device, hogging the interface. By default audio output could go to ALSA or better yet a Dmix plug, where the source and destination could be selected and mixed together.
Maybe I did not understand ALSA fully, but: IMHO you will need dmix only when your sound hardware is not capable of hardware mixing (like mine is, for example). If it was, you would not need (or want, for that matter) to use dmix.
PS: inspired by this posting I tried to set up dmix again for my system (had tried it during FC2 testing, and was not impressed, crackling occured), but all seems well now. xine, mplayer, openttd (SDL layer) and bmp all happily sing along. The only thing not working are programs that want to use /dev/dspX directly, but those are few and far between for my uses.
On Oct 18, 2004, at 13:59, Ralf Ertzinger wrote:
Hi.
David Mohring heretic@ihug.co.nz wrote:
Even using the ALSA interface, Fedora defaults to sending/receiving applications audio direct to the hardware device, hogging the interface. By default audio output could go to ALSA or better yet a Dmix plug, where the source and destination could be selected and mixed together.
Maybe I did not understand ALSA fully, but: IMHO you will need dmix only when your sound hardware is not capable of hardware mixing (like mine is, for example). If it was, you would not need (or want, for that matter) to use dmix.
You are right... Some sound cards out there have several hardware audio channels and can perform HW sound mixing of up to a number of sound sources equal to its sound channels. For example, if the card has 4 HW channels it can mix up to 4 simultaneous sound sources.
On Mon, 2004-10-18 at 14:13 +0200, Felipe Alfaro Solana wrote:
On Oct 18, 2004, at 13:59, Ralf Ertzinger wrote:
Hi.
David Mohring heretic@ihug.co.nz wrote:
Even using the ALSA interface, Fedora defaults to sending/receiving applications audio direct to the hardware device, hogging the interface. By default audio output could go to ALSA or better yet a Dmix plug, where the source and destination could be selected and mixed together.
Maybe I did not understand ALSA fully, but: IMHO you will need dmix only when your sound hardware is not capable of hardware mixing (like mine is, for example). If it was, you would not need (or want, for that matter) to use dmix.
You are right... Some sound cards out there have several hardware audio channels and can perform HW sound mixing of up to a number of sound sources equal to its sound channels. For example, if the card has 4 HW channels it can mix up to 4 simultaneous sound sources.
Ok, how about giving the option to deploy audio as either 1) Direct to card hardware Card set up as /dev/dsp hw:0 etc 2) Software Mix Dmix set up as /dev/dsp hw:0 etc Following audio devices set up /dev/dspX hw:X etc And the future kernel hack 3) Multiuser Software Switch a /dev/tty like switch for /dev/dsp hw:0 to each users assigned /dev/dsp hw:0 etc - either hardware or dmix device.
On Tue, 2004-10-19 at 02:29 +1300, David Mohring wrote:
Ok, how about giving the option to deploy audio as either
- Direct to card hardware Card set up as /dev/dsp hw:0 etc
- Software Mix Dmix set up as /dev/dsp hw:0 etc Following audio devices set up /dev/dspX hw:X etc
And the future kernel hack 3) Multiuser Software Switch a /dev/tty like switch for /dev/dsp hw:0 to each users assigned /dev/dsp hw:0 etc - either hardware or dmix device.
Opps last line should read /dev/dspX hw:X etc - either hardware or dmix device.
-- David Mohring heretic@ihug.co.nz
On Tue, 2004-10-19 at 02:29 +1300, David Mohring wrote:
On Mon, 2004-10-18 at 14:13 +0200, Felipe Alfaro Solana wrote:
You are right... Some sound cards out there have several hardware audio channels and can perform HW sound mixing of up to a number of sound sources equal to its sound channels. For example, if the card has 4 HW channels it can mix up to 4 simultaneous sound sources.
Ok, how about giving the option to deploy audio as either
- Direct to card hardware Card set up as /dev/dsp hw:0 etc
- Software Mix Dmix set up as /dev/dsp hw:0 etc Following audio devices set up /dev/dspX hw:X etc
Or, instead of being goofy and making this an "option," just use the HAL FDI system to mark which cards need software mixing and which don't, and make it all nice and automatic like it should be.
And the future kernel hack 3) Multiuser Software Switch a /dev/tty like switch for /dev/dsp hw:0 to each users assigned /dev/dsp hw:0 etc - either hardware or dmix device.
-- David Mohring heretic@ihug.co.nz
On Mon, 18 Oct 2004 09:47:21 -0400, Sean Middleditch elanthis@awesomeplay.com wrote:
Or, instead of being goofy and making this an "option," just use the HAL FDI system to mark which cards need software mixing and which don't, and make it all nice and automatic like it should be.
hal? or would udev rules and/or scripts be more appropriate for this sort of thing?
-jef
On Mon, 2004-10-18 at 10:53 -0400, Jeff Spaleta wrote:
On Mon, 18 Oct 2004 09:47:21 -0400, Sean Middleditch elanthis@awesomeplay.com wrote:
Or, instead of being goofy and making this an "option," just use the HAL FDI system to mark which cards need software mixing and which don't, and make it all nice and automatic like it should be.
hal? or would udev rules and/or scripts be more appropriate for this sort of thing?
HAL provides the information that the udev rules or scripts would use. You'd query some property on the HAl device info as to whether hardware mixing is available or not.
In a more ideal world, the ALSA drivers would directly provide that information, and you wouldn't need a separate database of device info to know whether the current hardware and driver support hardware mixing. I don't know if ALSA exports that kind of information, however; I'm under the assumption that it does not.
-jef
On Mon, 2004-10-18 at 14:13 +0200, Felipe Alfaro Solana wrote:
You are right... Some sound cards out there have several hardware audio channels and can perform HW sound mixing of up to a number of sound sources equal to its sound channels. For example, if the card has 4 HW channels it can mix up to 4 simultaneous sound sources.
Having to configure this manually is a nonstarter. It's very clear that the right thing to do is automatically use hardware mixing if possible, and otherwise fall back to software mixing.
If that isn't possible, then we need to use software mixing by default for all the normal nondemanding sound cases since it will always work; and reserve hardware mixing for complex audio apps that want to play with ALSA directly, or let users turn it on manually by editing some text file, if they care about the performance win.
Users that just want to play mp3's aren't going to understand a bunch of how-is-mixing-implemented configuration nonsense.
Havoc
Ralf Ertzinger wrote:
Hi.
David Mohring heretic@ihug.co.nz wrote:
Even using the ALSA interface, Fedora defaults to sending/receiving applications audio direct to the hardware device, hogging the interface. By default audio output could go to ALSA or better yet a Dmix plug, where the source and destination could be selected and mixed together.
Maybe I did not understand ALSA fully, but: IMHO you will need dmix only when your sound hardware is not capable of hardware mixing (like mine is, for example). If it was, you would not need (or want, for that matter) to use dmix.
PS: inspired by this posting I tried to set up dmix again for my system (had tried it during FC2 testing, and was not impressed, crackling occured), but all seems well now. xine, mplayer, openttd (SDL layer) and bmp all happily sing along. The only thing not working are programs that want to use /dev/dspX directly, but those are few and far between for my uses.
How about using the available hardware audio channels if hardware mixing can be acomplished but default to dmix if the sound card is incapable of hardware mixing. Maybe someone who better understands ALSA:dmix can suggest more creative ways to interface with these cards. I'm sure there are lots of users out there that would love to get simultaneous sound mixing be default. If sound quality is an issure then that will definately have to be addressed
-
David Mohring -
Demond -
Felipe Alfaro Solana -
Havoc Pennington -
Jef Spaleta -
Ralf Ertzinger -
Sean Middleditch