NOV
8
2004

ALSA dmix for HP nx5000

You got one of those nice HP nx5000 with SUSE 9.1 preinstalled at aKademy? You were annoyed because the stupid intel chipsets could not handle mixing and the sound device was permanently busy? No more!

Simply place the following code into your home directory as ~/.asoundrc, restart artsd and enjoy your newly-gained software-mixing.


pcm.ossmix {
type dmix
ipc_key 1024 # must be unique!
slave {
pcm "hw:0,0"
period_time 0
period_size 1024 # must be power of 2
buffer_size 8192 # dito.
}

bindings {
0 0 # from 0 => to 0
1 1 # from 1 => to 1
}
}
pcm.!default {
type plug
slave.pcm "ossmix"
}
··
pcm.dsp0 {
type plug
slave.pcm "ossmix"
}

ctl.mixer0 {
type hw
card 0
}

If you need more help, you might want to take a look at this very helpful page which I derived my configuration from. you can now happily use JuK, amaroK, Kaffeine and mplayer aside for the full monty of multimedia expirience.

Comments

Sounds great.

The problem still remains that /dev/dsp is locked as soon as an application accesses it. Why can't alsa just support multiple access to /dev/dsp? :)

At least that would work with every application out there and wouldn't be as incomprehensible as the code you have quoted above.


By Navindra Umanee at Mon, 11/08/2004 - 04:13

isn't that the point of dmix, to allow multiple programs access to /dev/dsp?


By [email protected] at Mon, 11/08/2004 - 05:04

How is it possible for dmix to do that just from a ~/.asoundrc configuration file? So, I don't think so.

That page that danimo linked also says:

No, dmix technically does not get between /dev/dsp and the sound driver, but aoss gets between the application and the real /dev/dsp and routes the audio data over to ALSA's dmix.

So it provides "aoss" which is wrapper similar to "artsdsp".


By Navindra Umanee at Mon, 11/08/2004 - 05:32

look this part:

22 pcm.dsp0 {
23 type plug
24 slave.pcm "ossmix"
25 }

It's mean that all call under /dev/dsp0 gors through ossmix plugin.
since in alsa /dev/dsp is a symlink to /dev/dsp0, you got the result.

The aoss "wrapper" is just a LD_PRELOAD of libaoss library, nothing more.

The section !default make all sounds trying to address non default devices direct to dmix.

This thing really works, excep the part of buffer/period/khz which can have different values depending on the card and tweeking wrong values can make your audio a huge annoyance.

The only thing that don't works well with dmix way is Jack. At least i didn't manage how to do


By Helio Chissini de Castro at Mon, 11/08/2004 - 20:38

As far as I can tell this still means that you have to launch all your dsp using applications as "aoss application". Correct me if I'm wrong.

My main complaint was that all this complication should have been avoided simply by handling it at the /dev/dsp level.

It's a bit depressing that the "new" Linux sound architecture couldn't get something as basic as that right -- from the point of view of an end-user.


By Navindra Umanee at Mon, 11/08/2004 - 21:10

I'll try to answer all those questions above...
Alsa supports two types of OSS emulation, kernel-space (the snd_pcm_oss, snd_mixer_oss kernel modules) and user-space (the aoss tool).

I'll try to illustrate it:

OSS app -> /dev/dsp -> alsa OSS kernel emulation -> alsa snd driver

aoss(OSS app) -> alsa lib -> /dev/snd/pcmXX -> alsa snd driver

dmix is a user-space plugin, so it only works if applications use the alsa libraries (libasound.so).
If the OSS applications work trough the kernel-space OSS emulation they don't call inside libasound so the can't use dmix... but if OSS applications are started via aoss then the dmix plugin will work.

Take notice that there are slight limitations when using dmix compared to directly using the audio device... most of these are ironed out lately.. but there were times when xine would work properly with dmix.


By Damjan Georgievski at Tue, 11/09/2004 - 00:27