Today on this ol' server

Fixing sound on an Ultra 20

Today we're going to look debugging a sound problem on an Ultra 20.

A friend called me up saying he couldn't get sound working on his ultra20. I didn't have an ultra 20 just lying around running Solaris 10 (build 74l2a) so he gave me access to his system via vpn.

I didn't know why the sound wasn't working. Sound was rumored to work, and he said he had upgraded and reinstalled all the sound drivers. I checked dmesg; there wasn't any system issue preventing the sound from working. I asked him to run sdtaudiocontrol, a sound program I was familar with.

sdtaudiocontrol has a nice status panel which shows the playback sampling. He said sdtaudiocontrol would show the record feature, but the playback tab was grayed out. I confirmed the same output by redisplaying the program to my desktop.

Since I had no clue as to why this was not working, I had no choice but to watch sdtaudiocontrol via truss. (Yes, I would have used dtrace if I had more experience with it.) truss is my main tool of choice. It's bulky; there's loads of data to wade though when looking at the system calls of any medium or large app. I needed to be sure the sound program could access all of the libraries and devices, and other pieces of programs it interfaced with. I also didn't know which libraries or devices sound was using. Also I wanted to see any weirdness unobstructed. truss will definitely do that, although some would argue the pertinent bits may be obstructed by the eyesore of digging through all that data.

I have, of course, since then found nice dtrace scripts to find file access issues, and pfiles would have shown me which files are in use.

Start truss of /ust/dt/bin/sdtaudiocontrol

truss -f -o /var/tmp/sound.truss.out /ust/dt/bin/sdtaudiocontrol
14398:  execve("/usr/bin/ksh", 0x08047D48, 0x08047D54)  argc = 2
14398:  resolvepath("/usr/bin/ksh", "/usr/bin/ksh", 1023) = 12
14398:  sysconfig(_CONFIG_PAGESIZE)                     = 4096
...
14419/1:        pipe()                                          = 11 [12]
14419/1:        open("/dev/audioctl", O_WRONLY)                 = 13
14419/1:        ioctl(13, I_SETSIG, S_MSG)                      = 0
...

The truss showed no errors when opening /dev/audioctl, and no other identifiable errors or whackiness.

Ok, it opened the device just fine. Let's see what's at the end of that device. Interestingly /dev/audio points to a usb device which is different compared to an OpenSolaris box down the hall.

bash-3.00# ls -l audio*
lrwxrwxrwx   1 root     root          10 May  2 11:50 audio -> usb/audio0
lrwxrwxrwx   1 root     root          18 May  2 11:50 audioctl ->
usb/audio-control0

My friend confirms that there is no speaker off the usb hub.
Humm. Let's look for raw audio devices.

bash-3.00# find /devices -name \*sound\* -ls 
2163736579  1 drwxr-xr-x   2 root     sys           512 Apr  7 16:31 /devices/pci@0,0/pci108e,5347@2/hub@1/device@3/sound@2
32505860    0 crw-------   1 root     sys       62,   0 May 24 16:35 /devices/pci@0,0/pci108e,5347@2/hub@1/device@3/sound@2:usb_as
2163474435    1 drwxr-xr-x   2 root     sys           512 Apr  7 16:31 /devices/pci@0,0/pci108e,5347@2/hub@1/device@3/sound-control@1
31981574    0 crw-------   1 user staff     61,   1 Apr  7 11:11 /devices/pci@0,0/pci108e,5347@2/hub@1/device@3/sound-control@1:sound,audioctl
31981572    0 crw-------   1 user staff     61,   0 Apr  7 11:11 /devices/pci@0,0/pci108e,5347@2/hub@1/device@3/sound-control@1:sound,audio
31981586    0 crw-------   1 root     sys       61,   7 May 24 16:35
/devices/pci@0,0/pci108e,5347@2/hub@1/device@3/sound-control@1:mux
19398662    0 crw-------   1 user staff     37,   1 May  2 09:44
/devices/pci@0,0/pci108e,5347@4:sound,audioctl
19398660    0 crw-------   1 user staff     37,   0 May  2 09:44
/devices/pci@0,0/pci108e,5347@4:sound,audio

The raw audio devices are definitely pointing to the usb hub. My friend says he doesn't have any speakers on the usb hub. He does have a webcam though. I ask him to remove the webcam. Maybe we can get devfsadm to find the correct devices.

bash-3.00# devfsadm -v
bash-3.00# 

Nope. No changes made by devfsadm. Ok, we can force devfsadm to make a move by removing those links.

(cd /dev)
bash-3.00# mv audio audio.old 
bash-3.00# mv audioctl autioctl.old 

See if devfsadm picks up the right device

bash-3.00# devfsadm -v  
devfsadm[14694]: verbose: symlink /dev/audio -> usb/audio0
devfsadm[14694]: verbose: symlink /dev/audioctl -> usb/audio-control0

Nope, devfsadm put back exactly what we removed. So we'll remove it again.

bash-3.00# rm audio audioctl 

Ok, I'll change the links to point to the devices on the PCI hub like the OpenSolaris system down the hall.

bash-3.00# ln -s ../../devices/pci@0,0/pci108e,5347@4:sound,audio audio 
bash-3.00# ln -s ../../devices/pci@0,0/pci108e,5347@4:sound,audioctl audioctl

Check that devfsadm won't undo our work:

bash-3.00# devfsadm -vs 

And as luck would have it, yes, it didn't undo our work.

Check links:
bash-3.00# ls -l *au*
lrwxrwxrwx   1 root     root          48 May 24 16:40 audio ->
../../devices/pci@0,0/pci108e,5347@4:sound,audio
lrwxrwxrwx   1 root     root          10 May  2 11:50 audio.old -> usb/audio0
lrwxrwxrwx   1 root     root          51 May 24 16:40 audioctl ->
../../devices/pci@0,0/pci108e,5347@4:sound,audioctl
lrwxrwxrwx   1 root     root          18 May  2 11:50 autioctl.old ->
usb/audio-control0

The driver loaded in the kernel was still using the old devices. Success! After a reboot the system picked up the new device files, and my co-worker had sound!

It's worth mentioning that mixer(7I) and usb_ac(7D) have futher details on how to tweak usb audio. Also, /kernel/drv/usb_ac.conf will allow usb audio to be enabled or disabled.
opensolaris

Posted at 09:03AM Jun 14, 2006 by saf in Sun  |  Comments[0]