Re: No /dev/dsp after switch from 2.6.12/hotplug to 2.6.15/udev
On Sunday 05 March 2006 01:03, Michael Marte wrote:
> Hello *,
>
> recently I upgraded my kernel from 2.6.12 to 2.6.15 and encountered some
> problems:
>
> - ACPI gets activated though my machine (a Dell Latitude CS 400 XT with
> a Pentium II processor) has only APM. It was easy to work around this
> problem by adding the kernel parameter "acpi=off". Nevertheless this
> seems to be kernel bug introduced somewhere between 2.6.12 and 2.6.15.
>
> - When upgrading the kernel, I was forced to replace hotplug by udev and
> now /dev/dsp is gone. First I found that the sound driver nm256_audio
> has disappeared and so I replaced the corresponding entry in
> /etc/modules by snd_nm256 which seems to replace nm256_audio and causes
> udev to create the files
>
> crw-rw---- 1 root audio 116, 0 Mar 5 07:52 controlC0
> crw-rw---- 1 root audio 116, 24 Mar 5 07:52 pcmC0D0c
> crw-rw---- 1 root audio 116, 16 Mar 5 07:52 pcmC0D0p
> crw-rw---- 1 root audio 116, 33 Mar 5 07:51 timer
>
> in /dev/snd and the files
>
> lrwxrwxrwx 1 root root 5 Mar 5 08:54 NM256ZX -> card0
> dr-xr-xr-x 5 root root 0 Mar 5 08:54 card0
> -r--r--r-- 1 root root 0 Mar 5 08:54 pcm
> -r--r--r-- 1 root root 0 Mar 5 08:54 timers
>
> in /proc/asound. But still no /dev/dsp! What is going wrong here? Am I
> using the wrong driver? Here is what lspci tells me:
>
> 000:01:00.1 Multimedia audio controller: Neomagic Corporation NM2360
> [MagicMedia 256ZX Audio]
>
> Thank you for hints,
> Michael
I am pretty sure that the alsa drivers are being used and not the oss ones.
Instead of trying to work with oss, in order to get /dev/dsp, you could use
the program aoss which is part of the alsa-oss package. Once installed you
could then set up a .asoundrc file such as this:
pcm.dsp0 { type plug slave.pcm "hw:0,0"}
man aoss will show something similar.
Then to run those sound applications that require access to /dev/dsp, you
would do something like this from the command line.
aoss rezound
Note: This is not a way of getting back to loading the OSS drivers which may
be what you want to do. I used the above technique to get around
applications that needed access to /dev/dsp.
John
Reply to: