USB audio died via "upgrade"
I had a perfectly fine setup, with ALSA compiled into
the kernel and esd running.
Well, it was as fine as can be with esd, but anyway...
After a general multi-package upgrade, nothing works.
Of course I do not know the cause, but the new userspace
managed to OOPS the OSS emulation with a NULL
pointer ref in snd_pcm_oss_release and snd_pcm_oss_sync.
I decide to avoid the OOPS by avoiding OSS emulation.
I install all of Debian's ALSA-related packages, try a couple
fresh kernels... nothing.
I have the device files. The permissions are set fine.
The kernel boot shows this:
Advanced Linux Sound Architecture Driver Version 1.0.11rc4 (Wed Mar 22
10:27:24 2006 UTC).
usbcore: registered new driver snd-usb-audio
ALSA device list:
#0: Virtual MIDI Card 1
#1: Apple Computer, Inc. Speakers at usb-0001:10:18.0-2.1, full speed
It seems alsaconf doesn't do USB. It tells me:
No supported PnP or PCI card found.
Would you like to probe legacy ISA sound cards/chips?
Heh. No thanks. On a Mac, I'm afraid to try probing for
an ISA sound card. Very bad things probably happen.
I can specify any driver I like, and mpg321/mpg123 still won't
make a sound. Trying valgrind makes things much worse; the
program doesn't SIGSEGV outside of valgrind:
==5893== Process terminating with default action of signal 11 (SIGSEGV)
==5893== Access not within mapped region at address 0x100380
==5893== at 0x118823B4: (within /lib/ld-2.3.6.so)
So I guess that tool is broken on PowerPC. From the strace
command I see that the audio app does this:
access("/etc/asound.conf", R_OK) = -1 ENOENT (No such file or directory)
access("/home/albert/.asoundrc", R_OK) = -1 ENOENT (No such file or directory)
open("/usr/share/alsa/cards/aliases.conf", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=1245, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x3001d000
read(3, "#\n# Define aliases for various "..., 4096) = 1245
open("/usr/share/alsa/pcm/default.conf", O_RDONLY) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=507, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x3001e000
read(4, "#\n# Default output\n#\n\npcm.!defau"..., 4096) = 507
read(4, "", 4096) = 0
close(4) = 0
munmap(0x3001e000, 4096) = 0
open("/usr/share/alsa/pcm/dmix.conf", O_RDONLY) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=1192, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x3001e000
read(4, "#\n# dmix output\n#\n\npcm.!dmix {\n\t"..., 4096) = 1192
read(4, "", 4096) = 0
close(4) = 0
munmap(0x3001e000, 4096) = 0
open("/usr/share/alsa/pcm/dsnoop.conf", O_RDONLY) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=1194, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x3001e000
read(4, "#\n# dsnoop\n#\n\npcm.!dsnoop {\n\t@ar"..., 4096) = 1194
read(4, "", 4096) = 0
close(4) = 0
munmap(0x3001e000, 4096) = 0
read(3, "", 4096) = 0
read(3, "", 4096) = 0
close(3) = 0
munmap(0x3001d000, 4096) = 0
open("/dev/snd/controlC0", O_RDONLY) = 3
close(3) = 0
stat64("/usr/share/alsa/alsa.conf", {st_mode=S_IFREG|0644,
st_size=7640, ...}) = 0
open("/dev/snd/controlC0", O_RDONLY) = 3
close(3) = 0
open("/dev/snd/controlC0", O_RDWR) = 3
ioctl(3, USBDEVFS_CONTROL, 0x7fa775f8) = 0
ioctl(3, UI_DEV_CREATE, 0x7fa775a0) = 0
close(3) = 0
access("/usr/share/alsa/cards/VirMIDI.conf", R_OK) = -1 ENOENT (No
such file or directory)
open("/dev/snd/controlC1", O_RDONLY) = 3
close(3) = 0
stat64("/usr/share/alsa/alsa.conf", {st_mode=S_IFREG|0644,
st_size=7640, ...}) = 0
open("/dev/snd/controlC1", O_RDONLY) = 3
close(3) = 0
open("/dev/snd/controlC1", O_RDWR) = 3
ioctl(3, USBDEVFS_CONTROL, 0x7fa775f8) = 0
ioctl(3, UI_DEV_CREATE, 0x7fa775a0) = 0
close(3) = 0
access("/usr/share/alsa/cards/USB-Audio.conf", R_OK) = -1 ENOENT (No
such file or directory)
BTW, I have to wonder, will the mess of clashing sound
daemons ever get sorted out? Single-open /dev/dsp was
perfectly fine, without conflicts, until the sound daemons
were invented. For me, the daemons created the very
problem they were intended to solve.
Reply to: