Debian ALSA (2.6 kernel)

int0x80 · 01-09-2006, 09:49 AM

I am running a 2.6.14.3 kernel in Debian with the ALSA packages installed. The sound card is a VIA (onboard), and is correctly identified by ALSA when the system loads. Its driver is compiled into the kernel as opposed to being loaded as a module.

However, the sound does not play on this system. When booting into KDE, I get the useless message from artsd that device /dev/dsp can't be opened. Granted there are many potential causes for this, however I don't see why this is the case for this situation.

* I have already adjusted the mixer settings using alsamixer.

dmesg

Code:

Advanced Linux Sound Architecture Driver Version 1.0.10rc1 (Mon Sep 12 08:13:09 2005 UTC).
via82xx: Assuming DXS channels with 48k fixed sample rate.
         Please try dxs_support=5 option
         and report if it works on your machine.
         For more details, read ALSA-Configuration.txt.
ACPI: PCI Interrupt Link [ALKC] BIOS reported IRQ 0, using IRQ 22
ACPI: PCI Interrupt Link [ALKC] enabled at IRQ 22
ACPI: PCI Interrupt 0000:00:11.5[C] -> Link [ALKC] -> GSI 22 (level, low) -> IRQ 20
PCI: Via IRQ fixup for 0000:00:11.5, from 10 to 4
PCI: Setting latency timer of device 0000:00:11.5 to 64
ALSA device list:
  #0: VIA 8235 with CMI9761 at 0xe000, irq 20

lspci

Code:

0000:00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 50)

Any suggestions? If there are any other file contents or outputs you'd like to see, please request them.

PS: I've searched all over Google, and through the LQ forums already.

Notwerk · 01-09-2006, 11:14 AM

Try:

Code:

#killall esd

if that works you know what to investigate

int0x80 · 01-09-2006, 12:14 PM

Thanks for the suggestion. The esound package is not installed, however. I have seen that in the past where esd blocks artsd and causes problems. Unfortunately this is not the case here.

Notwerk · 01-10-2006, 06:04 AM

In that case, check the permissions for /dev/dsp

You might need to add your user account to the "audio" group (or whichever is applicable in your case), or modify the device permissions to allow read/write to regular users.

Did you try to dump stuff into /dev/dsp? e.g. $cat /dev/[u]random > /dev/dsp. That should generate some sound if you have the right permissions (as a regular user).

nx5000 · 01-10-2006, 06:08 AM

I think by default users are part of audio group but check..
Relaunch alsaconf (you need your driver as a module for this!)

int0x80 · 01-10-2006, 11:00 AM

I currently don't have access to the machine, but:

Quote:

Originally Posted by Notwerk

In that case, check the permissions for /dev/dsp

You might need to add your user account to the "audio" group (or whichever is applicable in your case), or modify the device permissions to allow read/write to regular users.

Did you try to dump stuff into /dev/dsp? e.g. $cat /dev/[u]random > /dev/dsp. That should generate some sound if you have the right permissions (as a regular user).

I recall the permissions for /dev/dsp being crw-rw----. Unfortunately I didn't think to grep audio /etc/group. However, it appears I was automatically added to the audio group on the Debian system I'm currently on. Therefore, I would assume the same holds true for the system in question. I didn't think to cat anything to /dev/dsp, so that's something to try. Funny that idea didn't cross my mind as that's usually how I find my mouse

Quote:

Originally Posted by nx5000

I think by default users are part of audio group but check..
Relaunch alsaconf (you need your driver as a module for this!)

It appears you were right about the users being part of the audio group. alsaconf won't do much for me in this case as the driver was compiled into the kernel, instead of being built as a module. Usually, I make the sound driver as a module, and then use alsaconf. However, when I first did that in this case, alsaconf would fail to unload the sound modules. Then when I would run alsamixer, I would get an error. I believe it was "alsactl:load_state: 1134: No sound cards found".

ericb · 01-10-2006, 11:31 AM

i have the same problem, and i'm not very good with linux, so could you maybe dumb it down a little bit?

int0x80 · 01-10-2006, 12:18 PM

ericb: Just hang tight. Once the solution is determined, it will be explained. Also there are many potential causes for this problem. I found several solutions that worked for others through google. None of them worked for me, however.

ericb · 01-10-2006, 12:35 PM

alright cool, i still gotta fuck around with alsa, i just installed my system, and so far it hasn't work on slackware, and barely on fedora (i got the sound to work, but it had little stupid problems

nx5000 · 01-11-2006, 02:06 AM

Quote:

Originally Posted by GNUbie

alsaconf won't do much for me in this case as the driver was compiled into the kernel, instead of being built as a module. Usually, I make the sound driver as a module, and then use alsaconf. However, when I first did that in this case, alsaconf would fail to unload the sound modules.

Yes, it is an annoying limitation of alsaconf, I discovered it a few days ago.
I also usually compile it as module but just for having a bit more quicker kernel , I linked everything to the kernel.
Then looked at alsaconf and saw

Code:

# In Debian the tool always operates in modinfo mode
#    -m|--modinfo)
#       use_modinfo_db=1; shift ;;

So now, I have my audio drivers as the only modules...
After running alsaconf, everything went fine (you have to be sure to close all apps accessing the sound system)
I'm running artsd on top of it (through KDE Sound System) to enable sharing of the device by multiple programs.
Works ok. (until now..)

ericb · 01-11-2006, 11:03 AM

i actually got my sound to work on my old soundcard, but it won't detect my newer better one (better than no sound though haha)

int0x80 · 01-11-2006, 05:02 PM

Quote:

Originally Posted by Notwerk

You might need to add your user account to the "audio" group (or whichever is applicable in your case), or modify the device permissions to allow read/write to regular users.

Did you try to dump stuff into /dev/dsp? e.g. $cat /dev/[u]random > /dev/dsp. That should generate some sound if you have the right permissions (as a regular user).

That's actually what the problem was. Catting /dev/urandom to /dev/dsp produced a horrific noise, and adding the user to /etc/group, then restarting kdm/X fixed the problem! Thanks so much

Notwerk · 01-11-2006, 06:40 PM

I've seen this happen before (on my machine).
The first user account created (through the GUI) after the install was automatically added to the audio group but subsequent user accounts weren't.

nx5000 · 01-12-2006, 02:11 AM

You are right notwerk, I have the same on my machine.
Never seen this.