Hi!
I have SB Live! here. I remember it worked long time ago. Now I can't
get it to produce any sound :-(.
root@hobit:~# cat /proc/asound/cards
0 [Live ]: EMU10K1 - SBLive! Value [CT4830]
SBLive! Value [CT4830] (rev.7,
serial:0x80261102) at 0x3000, irq 20
1 [Bt878 ]: Bt87x - Brooktree Bt878
Brooktree Bt878 at 0xd0001000, irq 17
root@hobit:~# uname -a
Linux hobit 2.6.16-rc4 #1 SMP PREEMPT Sat Feb 18 23:53:41 CET 2006
i686 GNU/Linux
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
Pe data de Dum 19 Feb 2006 01:14, a-ţi scris:
> Hi!
>
> I have SB Live! here. I remember it worked long time ago. Now I
> can't get it to produce any sound :-(.
>
> root@hobit:~# cat /proc/asound/cards
> 0 [Live ]: EMU10K1 - SBLive! Value [CT4830]
> SBLive! Value [CT4830] (rev.7,
> serial:0x80261102) at 0x3000, irq 20
> 1 [Bt878 ]: Bt87x - Brooktree Bt878
> Brooktree Bt878 at 0xd0001000, irq 17
>
> root@hobit:~# uname -a
> Linux hobit 2.6.16-rc4 #1 SMP PREEMPT Sat Feb 18 23:53:41 CET 2006
> i686 GNU/Linux
>
Same problem here some time ago. See below forwarded message.
Subject: Re: Fw: PROBLEM: SB Live! 5.1 (emu10k1, rev. 0a) doesn't work
with 2.6.15
Date: Lun 13 Feb 2006 23:52
From: ghrt <[email protected]>
To: Takashi Iwai <[email protected]>
Pe data de Lun 13 Feb 2006 17:08, a-ţi scris:
> At Mon, 13 Feb 2006 04:09:00 -0800,
>
> Andrew Morton wrote:
> > Begin forwarded message:
> >
> > Date: Sat, 14 Jan 2006 00:03:48 +0200
> > From: ghrt <[email protected]>
> > To: [email protected]
> > Subject: PROBLEM: SB Live! 5.1 (emu10k1, rev. 0a) doesn't work
> > with 2.6.15
> >
> >
> > hello
> >
> > i've compiled vanilla 2.6.15 and my sound card doesn't work
> > anymore. i can see it in kmix (and adjust the volumes, too), it
> > appears in dmesg (at ALSA devices), xmms & mplayer doesn't say
> > anything about errors, but it doesn't make any sound.
> > the onboard soundcard, via8233, works well with the same 2.6.15.
> > sb live! works well with 2.6.14.2 and previous.
> > i'm using an updated Slackware.
> >
> > if you have any questions i'll answer.
>
> First check /proc/asound/cards to see whether the emu10k1 model is
> detected properly. If '[Unknown]' is shown, your model is not
> listed in the whitelist.
Seems ok (see below). But i came to the conclusion that it might be
KMix as well, because alsa-mixer (console) works fine.
Maybe if the name of the output (or input) device (now both are
"Wave") is changed to be different from the other names the problem
will dissapear. I didn't have time to do this (i am not a programmer
also).
When i unmute in KMix input->Wave it works (sounds) perfectly. The
problem is that KMix is wrongly linking input->Wave as output->Wave,
as far as i can see.
Giving these channels diff. names in kernel will prevent this
problem.
root@ghrt:~# cat /proc/asound/cards
0 [V8233 ]: VIA8233 - VIA 8233
VIA 8233 with VIA1612A at 0xe000, irq 5
1 [Live ]: EMU10K1 - SB Live 5.1 [SB0220]
SB Live 5.1 [SB0220] (rev.10, serial:0x80651102)
at 0xe800, irq 12
> There was a bug that the front control conflicts with ac97 and
> emu10k1 dsp which was already fixed in the latest version (at least
> on 2.6.16-rc3).
i saw (already in 2.6.15.1 as well) and i will try it in weekend
(sooner if it's urgent).
tia
--
ghrt
> Takashi
Hi!
> > root@hobit:~# uname -a
> > Linux hobit 2.6.16-rc4 #1 SMP PREEMPT Sat Feb 18 23:53:41 CET 2006
> > i686 GNU/Linux
> >
> Same problem here some time ago. See below forwarded message.
Thanks.
> > First check /proc/asound/cards to see whether the emu10k1 model is
> > detected properly. If '[Unknown]' is shown, your model is not
> > listed in the whitelist.
>
> Seems ok (see below). But i came to the conclusion that it might be
> KMix as well, because alsa-mixer (console) works fine.
> Maybe if the name of the output (or input) device (now both are
> "Wave") is changed to be different from the other names the problem
> will dissapear. I didn't have time to do this (i am not a programmer
> also).
I tried enabled everything I could in alsamixer, but still could not
get it to produce some sound :-(.
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
Also sprach Pavel Machek <[email protected]> (Sun, 19 Feb 2006 00:48:05
+0100):
> Hi!
Hello,
> I tried enabled everything I could in alsamixer, but still could not
> get it to produce some sound :-(.
I usually use some simple mixer like rexima and a small .wav or .ogg
aplay/play/ogg123'ed for testing.
Have one of those in a UP P3 here (but 2.6.15):
$ cat /proc/asound/cards
0 [Live ]: EMU10K1 - SBLive! Value [CT4670]
SBLive! Value [CT4670] (rev.5, serial:0x201102) at 0xdc00,
irq 10
$ cat /proc/asound/devices
1: : sequencer
4: [0- 0]: hardware dependent
8: [0- 0]: raw midi
19: [0- 3]: digital audio playback
18: [0- 2]: digital audio playback
26: [0- 2]: digital audio capture
25: [0- 1]: digital audio capture
16: [0- 0]: digital audio playback
24: [0- 0]: digital audio capture
0: [0- 0]: ctl
6: [0- 2]: hardware dependent
9: [0- 1]: raw midi
10: [0- 2]: raw midi
33: : timer
# lsmod [sound]
emu10k1_gp 1152 0
snd_emu10k1_synth 4160 0
snd_emux_synth 26048 1 snd_emu10k1_synth
snd_seq_virmidi 2976 1 snd_emux_synth
snd_seq_midi_emul 4224 1 snd_emux_synth
snd_emu10k1 89284 1 snd_emu10k1_synth
snd_rawmidi 13344 2 snd_seq_virmidi,snd_emu10k1
snd_ac97_codec 69344 1 snd_emu10k1
snd_ac97_bus 768 1 snd_ac97_codec
snd_util_mem 1312 2 snd_emux_synth,snd_emu10k1
snd_hwdep 4320 2 snd_emux_synth,snd_emu10k1
Any message when you try to play a file? Or just no sound output, but
progress while playing?
sl ritch
On Sun, 2006-02-19 at 00:48 +0100, Pavel Machek wrote:
> I tried enabled everything I could in alsamixer, but still could not
> get it to produce some sound :-(.
Is 2.6.15.4 also broken?
Lee
On 2/19/06, Pavel Machek <[email protected]> wrote:
> Hi!
>
> I have SB Live! here. I remember it worked long time ago. Now I can't
> get it to produce any sound :-(.
>
> root@hobit:~# cat /proc/asound/cards
> 0 [Live ]: EMU10K1 - SBLive! Value [CT4830]
> SBLive! Value [CT4830] (rev.7,
> serial:0x80261102) at 0x3000, irq 20
> 1 [Bt878 ]: Bt87x - Brooktree Bt878
> Brooktree Bt878 at 0xd0001000, irq 17
>
> root@hobit:~# uname -a
> Linux hobit 2.6.16-rc4 #1 SMP PREEMPT Sat Feb 18 23:53:41 CET 2006
> i686 GNU/Linux
>
I've got an SB Live! card here as well. Not exactely the same as yours
(mine's rev. 10, yours is rev. 7), but mine works just fine with
2.6.16-rc4, so whatever is wrong it does not seem to effect all SB
Live! cards...
root@dragon:~# cat /proc/asound/cards
0 [Live ]: EMU10K1 - SB Live [Unknown]
SB Live [Unknown] (rev.10, serial:0x80671102) at
0xd880, irq 20
root@dragon:~# lspci -v
<...>
04:05.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 0a)
Subsystem: Creative Labs SBLive! 5.1 eMicro 28028
Flags: bus master, medium devsel, latency 32, IRQ 20
I/O ports at d880 [size=32]
Capabilities: [dc] Power Management version 1
root@dragon:~# uname -a
Linux dragon 2.6.16-rc4 #1 SMP PREEMPT Sat Feb 18 02:13:29 CET 2006
i686 athlon-4 i386 GNU/Linux
--
Jesper Juhl <[email protected]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
There is definately something going on with these cards.
Ref. my LKML thread here:
http://lkml.org/lkml/2006/2/11/25
My card as reported in dmesg:
PCI: Found IRQ 12 for device 0000:00:0f.0
ALSA device list:
#0: SBLive 5.1 [SB0060] (rev.7, serial:0x80611102) at 0xe000, irq 12
lspci:
00:0f.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 07)
00:0f.1 Input device controller: Creative Labs SB Live! MIDI/Game Port (rev 07)
Now, I built and installed latest:
alsa-utils-1.0.11rc2
alsa-lib-1.0.11rc3
and _that_ appeared to fix my problem. But I just rebooted, and prior
to reboot as root I issued alsactl restore ~ no problems.
Following reboot, I now get (different control error) this:
alsactl: set_control:888: warning: iface mismatch (3/2) for control #80
alsactl: set_control:890: warning: device mismatch (0/0) for control #80
alsactl: set_control:892: warning: subdevice mismatch (0/0) for control #80
alsactl: set_control:894: warning: name mismatch (EMU10K1 PCM Send
Routing/External Amplifier) for control #80
alsactl: set_control:896: warning: index mismatch (0/0) for control #80
alsactl: set_control:898: failed to obtain info for control #80
(Identifier removed)
And now the confusing bit. If I run alsamixer but DO NOT DO ANYTHING,
exit, then issue 'alsactl store', then 'alsactl restore' works again
OK - until next reboot...
??
Nick
On Sun, 2006-02-19 at 11:18 +0000, Nick Warne wrote:
> alsactl: set_control:888: warning: iface mismatch (3/2) for control
> #80
> alsactl: set_control:890: warning: device mismatch (0/0) for control
> #80
> alsactl: set_control:892: warning: subdevice mismatch (0/0) for
> control #80
> alsactl: set_control:894: warning: name mismatch (EMU10K1 PCM Send
> Routing/External Amplifier) for control #80
> alsactl: set_control:896: warning: index mismatch (0/0) for control
> #80
> alsactl: set_control:898: failed to obtain info for control #80
> (Identifier removed)
>
>
> And now the confusing bit. If I run alsamixer but DO NOT DO ANYTHING,
> exit, then issue 'alsactl store', then 'alsactl restore' works again
> OK - until next reboot...
Sounds like you have 2 different alsactls installed. The ALSA default
one saves the mixer state in /etc/asound.state but lots of distros hack
it up to save the state somewhere under /var.
Use "alsactl -f" to force a restore of mixer state even if the mixer
controls have changed (distros should do this by default but don't).
Lee
On Sunday 19 February 2006 19:29, Lee Revell wrote:
> > And now the confusing bit. If I run alsamixer but DO NOT DO ANYTHING,
> > exit, then issue 'alsactl store', then 'alsactl restore' works again
> > OK - until next reboot...
>
> Sounds like you have 2 different alsactls installed. The ALSA default
> one saves the mixer state in /etc/asound.state but lots of distros hack
> it up to save the state somewhere under /var.
>
> Use "alsactl -f" to force a restore of mixer state even if the mixer
> controls have changed (distros should do this by default but don't).
Lee,
Everybody here keeps saying that to me - I _don't_ have two alsactl's, I
_don't_ have 2 asound.states (or more/any other alsactl files).
My base is Slackware 10 - a pretty clean distro.
Tonight my MIC is not working again from a reboot, and I can't get it going
like I did before (??)...
Every reboot 'alsactl restore' breaks on one control or another now.
You mean -F too? I don't understand why I should have to use --force.
It's a mystery?
Nick
--
"Person who say it cannot be done should not interrupt person doing it."
-Chinese Proverb
On Sun, 2006-02-19 at 20:20 +0000, Nick Warne wrote:
> On Sunday 19 February 2006 19:29, Lee Revell wrote:
>
> > > And now the confusing bit. If I run alsamixer but DO NOT DO ANYTHING,
> > > exit, then issue 'alsactl store', then 'alsactl restore' works again
> > > OK - until next reboot...
> >
> > Sounds like you have 2 different alsactls installed. The ALSA default
> > one saves the mixer state in /etc/asound.state but lots of distros hack
> > it up to save the state somewhere under /var.
> >
> > Use "alsactl -f" to force a restore of mixer state even if the mixer
> > controls have changed (distros should do this by default but don't).
>
> Lee,
>
> Everybody here keeps saying that to me - I _don't_ have two alsactl's, I
> _don't_ have 2 asound.states (or more/any other alsactl files).
>
> My base is Slackware 10 - a pretty clean distro.
>
> Tonight my MIC is not working again from a reboot, and I can't get it going
> like I did before (??)...
>
> Every reboot 'alsactl restore' breaks on one control or another now.
>
> You mean -F too? I don't understand why I should have to use --force.
>
> It's a mystery?
Sorry, no idea. You'll have to do a binary search with ALSA CVS to find
out exactly when it broke.
Lee
On Sun, 2006-02-19 at 20:20 +0000, Nick Warne wrote:
> Every reboot 'alsactl restore' breaks on one control or another now.
>
diff asound.state.working asound.state.bad
On 19.02.2006 [11:18:04 +0000], Nick Warne wrote:
> There is definately something going on with these cards.
>
> Ref. my LKML thread here:
>
> http://lkml.org/lkml/2006/2/11/25
>
> My card as reported in dmesg:
>
> PCI: Found IRQ 12 for device 0000:00:0f.0
> ALSA device list:
> #0: SBLive 5.1 [SB0060] (rev.7, serial:0x80611102) at 0xe000, irq 12
I also have a SBLive 5.1 card, seems to be the same rev/serial and I
have no problems using it (I haven't check any of the non-speaker ports,
though).
[ 55.007817] Advanced Linux Sound Architecture Driver Version 1.0.11rc2 (Wed Jan 04 08:57:20 2006 UTC).
[ 55.022668] ALSA device list:
[ 55.022672] #0: SBLive 5.1 [SB0060] (rev.7, serial:0x80611102) at 0xac00, irq 209
> lspci:
>
> 00:0f.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 07)
> 00:0f.1 Input device controller: Creative Labs SB Live! MIDI/Game Port (rev 07)
0000:01:06.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 07)
0000:01:06.1 Input device controller: Creative Labs SB Live! MIDI/Game Port (rev 07)
/proc/asound/cards:
0 [Live ]: EMU10K1 - SBLive 5.1 [SB0060]
SBLive 5.1 [SB0060] (rev.7, serial:0x80611102) at 0xac00, irq 209
> Now, I built and installed latest:
>
> alsa-utils-1.0.11rc2
> alsa-lib-1.0.11rc3
I run Ubuntu Breezy, which has:
alsa-utils = 1.0.9a-4ubuntu5
This is all from 2.6.16-rc4, btw.
Thanks,
Nish
On Sun, 2006-02-19 at 12:51 -0800, Nishanth Aravamudan wrote:
> I run Ubuntu Breezy, which has:
>
> alsa-utils = 1.0.9a-4ubuntu5
The alsa-utils version should not matter, it's alsa-lib that must be
kept in sync with the ALSA version in the kernel.
Lee
Hi!
> > I tried enabled everything I could in alsamixer, but still could not
> > get it to produce some sound :-(.
>
> I usually use some simple mixer like rexima and a small .wav or .ogg
> aplay/play/ogg123'ed for testing.
>
> Have one of those in a UP P3 here (but 2.6.15):
Mine output looks similar... pretty much okay. Set all in alsamixer to
max, plugged headphone-like speaker into green connector. No sound.
> Any message when you try to play a file? Or just no sound output, but
> progress while playing?
Everything looks okay, but no sound. Nothing in dmesg.
root@hobit:~# mpg123
/usr/share/emacs/site-lisp/emacspeak/sounds/emacspeak.mp3
High Performance MPEG 1.0/2.0/2.5 Audio Player for Layer 1, 2, and 3.
Version 0.59q (2002/03/23). Written and copyrights by Joe Drew.
Uses code from various people. See 'README' for more!
THIS SOFTWARE COMES WITH ABSOLUTELY NO WARRANTY! USE AT YOUR OWN RISK!
Directory: /usr/share/emacs/site-lisp/emacspeak/sounds/
Playing MPEG stream from emacspeak.mp3 ...
MPEG 1.0 layer III, 128 kbit/s, 44100 Hz joint-stereo
[0:03] Decoding of emacspeak.mp3 finished.
root@hobit:~# dmesg | tail -5
EXT3-fs: mounted filesystem with ordered data mode.
e1000: eth0: e1000_watchdog_task: NIC Link is Up 100 Mbps Full Duplex
coda_read_super: Bad mount data
coda_read_super: device index: 0
coda_read_super: No pseudo device
root@hobit:~#
aplay complains about nonexisting /dev/ files:
root@hobit:~# aplay
/usr/share/xemacs21/xemacs-packages/etc/sounds/hammer.wav
aplay: main:533: audio open error: No such file or directory
root@hobit:~#
...I'll try to fix it.
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
Hi!
> > I tried enabled everything I could in alsamixer, but still could not
> > get it to produce some sound :-(.
>
> Is 2.6.15.4 also broken?
2.6.15.4 does not have support for my SATA controller, so it would be
quite complex to test that... I may have something wrong with
userspace, but alsamixer all to max, then cat /bin/bash > /dev/dsp
should produce some sound, no?
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
On Ne 19-02-06 16:30:37, Lee Revell wrote:
> On Sun, 2006-02-19 at 12:51 -0800, Nishanth Aravamudan wrote:
> > I run Ubuntu Breezy, which has:
> >
> > alsa-utils = 1.0.9a-4ubuntu5
>
> The alsa-utils version should not matter, it's alsa-lib that must be
> kept in sync with the ALSA version in the kernel.
Ugh, not a good news. How do I tell if my alsa libs are recent enough?
It should at least warn, no?
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
Hi!
> > I run Ubuntu Breezy, which has:
> >
> > alsa-utils = 1.0.9a-4ubuntu5
>
> The alsa-utils version should not matter, it's alsa-lib that must be
> kept in sync with the ALSA version in the kernel.
I tried to play with mpg123 using OSS emulation, so that it does not
have anything to do with ALSA. No luck. Trying aplay:
root@hobit:/dev/snd# aplay
/usr/share/xemacs21/xemacs-packages/etc/sounds/hammer.wav
aplay: main:533: audio open error: No such file or directory
while stracing:
open("/dev/snd/pcmC0D0p", O_RDWR) = -1 ENOENT (No such file or
directory)
close(3) = 0
write(2, "aplay: main:533: ", 17aplay: main:533: ) = 17
write(2, "audio open error: No such file o"..., 43audio open error: No
such file or directory) = 43
write(2, "\n", 1
... but pcmC0D0p is not described in devices.txt...?
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
On Sun, 2006-02-19 at 22:47 +0100, Pavel Machek wrote:
> On Ne 19-02-06 16:30:37, Lee Revell wrote:
> > On Sun, 2006-02-19 at 12:51 -0800, Nishanth Aravamudan wrote:
> > > I run Ubuntu Breezy, which has:
> > >
> > > alsa-utils = 1.0.9a-4ubuntu5
> >
> > The alsa-utils version should not matter, it's alsa-lib that must be
> > kept in sync with the ALSA version in the kernel.
>
> Ugh, not a good news.
This has been the case for ages (distros still get it wrong). It is not
an ideal situation.
> How do I tell if my alsa libs are recent enough?
1.0.10 should be OK
> It should at least warn, no?
Yes.
Lee
On Sun, 2006-02-19 at 22:49 +0100, Pavel Machek wrote:
> Hi!
>
> > > I run Ubuntu Breezy, which has:
> > >
> > > alsa-utils = 1.0.9a-4ubuntu5
> >
> > The alsa-utils version should not matter, it's alsa-lib that must be
> > kept in sync with the ALSA version in the kernel.
>
> I tried to play with mpg123 using OSS emulation, so that it does not
> have anything to do with ALSA. No luck. Trying aplay:
>
> root@hobit:/dev/snd# aplay
> /usr/share/xemacs21/xemacs-packages/etc/sounds/hammer.wav
> aplay: main:533: audio open error: No such file or directory
>
> while stracing:
>
> open("/dev/snd/pcmC0D0p", O_RDWR) = -1 ENOENT (No such file or
> directory)
> close(3) = 0
> write(2, "aplay: main:533: ", 17aplay: main:533: ) = 17
> write(2, "audio open error: No such file o"..., 43audio open error: No
> such file or directory) = 43
> write(2, "\n", 1
>
> ... but pcmC0D0p is not described in devices.txt...?
Hmm, that's a udev problem or something. If you have a static dev the
snddevices script that comes with ALSA will create the device files.
Lee
Also sprach Pavel Machek <[email protected]> (Sun, 19 Feb 2006 22:42:29
+0100):
> Hi!
hi!
> > >[...]
> >
> aplay complains about nonexisting /dev/ files:
>
> root@hobit:~# aplay
> /usr/share/xemacs21/xemacs-packages/etc/sounds/hammer.wav
> aplay: main:533: audio open error: No such file or directory
> root@hobit:~#
>
> ...I'll try to fix it.
I think this is just to due missing oss (emulation) drivers. It's
snd_pcm_oss and snd_mixer_oss IIRC.
Anyway that "sounds" :) weired: There might be a mixer be muted or some
bobo with the driver.
I just looked into /proc/asound/cardX/pcm0p/sub0/status and it shows
progress when playing -- This _might_ mean that alsa is working. Did the
same on the box with the Live! now and got little bit lost by the amount
of channels, but it seems to be the same /pcm0p/sub0/status there.
> Pavel
sl ritch
On Ne 19-02-06 16:54:34, Lee Revell wrote:
> On Sun, 2006-02-19 at 22:49 +0100, Pavel Machek wrote:
> > Hi!
> >
> > > > I run Ubuntu Breezy, which has:
> > > >
> > > > alsa-utils = 1.0.9a-4ubuntu5
> > >
> > > The alsa-utils version should not matter, it's alsa-lib that must be
> > > kept in sync with the ALSA version in the kernel.
> >
> > I tried to play with mpg123 using OSS emulation, so that it does not
> > have anything to do with ALSA. No luck. Trying aplay:
> >
> > root@hobit:/dev/snd# aplay
> > /usr/share/xemacs21/xemacs-packages/etc/sounds/hammer.wav
> > aplay: main:533: audio open error: No such file or directory
> >
> > while stracing:
> >
> > open("/dev/snd/pcmC0D0p", O_RDWR) = -1 ENOENT (No such file or
> > directory)
> > close(3) = 0
> > write(2, "aplay: main:533: ", 17aplay: main:533: ) = 17
> > write(2, "audio open error: No such file o"..., 43audio open error: No
> > such file or directory) = 43
> > write(2, "\n", 1
> >
> > ... but pcmC0D0p is not described in devices.txt...?
>
> Hmm, that's a udev problem or something. If you have a static dev the
> snddevices script that comes with ALSA will create the device files.
I'm using static /dev... snddevices script indeed fixed that, but it
still does not work. (Is earphone in green connector enough?)
Ouch and that device should be still listed in devices.txt, no?
root@hobit:/dev/snd# aplay
/usr/share/xemacs21/xemacs-packages/etc/sounds/hammer.wav
Playing WAVE
'/usr/share/xemacs21/xemacs-packages/etc/sounds/hammer.wav' : Unsigned
8 bit, Rate 8000 Hz, Mono
root@hobit:/dev/snd#
Actually, in a quiet room I think I can hear *something*. Too faint to
recognize :-(.
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
On Sun, 2006-02-19 at 23:25 +0100, Pavel Machek wrote:
> I'm using static /dev... snddevices script indeed fixed that, but it
> still does not work. (Is earphone in green connector enough?)
>
No idea. There are like 50 varieties of this card.
> Ouch and that device should be still listed in devices.txt, no?
Probably...
Lee
On Sun, 2006-02-19 at 17:28 -0500, Lee Revell wrote:
> On Sun, 2006-02-19 at 23:25 +0100, Pavel Machek wrote:
> > I'm using static /dev... snddevices script indeed fixed that, but it
> > still does not work. (Is earphone in green connector enough?)
> >
>
> No idea. There are like 50 varieties of this card.
>
> > Ouch and that device should be still listed in devices.txt, no?
>
> Probably...
Hmm, OK - try *reverting* the emu10k1 fix that was in 2.6.15.4. This
was needed to get sound on some newer SBLive! varieties but may have
broken yours. Typical...
Lee
On Sunday 19 February 2006 21:50, Lee Revell wrote:
> On Sun, 2006-02-19 at 22:47 +0100, Pavel Machek wrote:
> > On Ne 19-02-06 16:30:37, Lee Revell wrote:
> > > On Sun, 2006-02-19 at 12:51 -0800, Nishanth Aravamudan wrote:
> > > > I run Ubuntu Breezy, which has:
> > > >
> > > > alsa-utils = 1.0.9a-4ubuntu5
> > >
> > > The alsa-utils version should not matter, it's alsa-lib that must be
> > > kept in sync with the ALSA version in the kernel.
> >
> > Ugh, not a good news.
>
> This has been the case for ages (distros still get it wrong). It is not
> an ideal situation.
>
> > How do I tell if my alsa libs are recent enough?
>
> 1.0.10 should be OK
I'm still using 1.0.9 on 2.6.16-rc4 with no problems, Audigy 2 (one that uses
emu10k1).
--
Cheers,
Alistair.
'No sense being pessimistic, it probably wouldn't work anyway.'
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
On Sun, 2006-02-19 at 23:23 +0000, Alistair John Strachan wrote:
> I'm still using 1.0.9 on 2.6.16-rc4 with no problems, Audigy 2 (one
> that uses
> emu10k1).
It's a specific change to the SBLive! that did not affect the Audigy
that causes alsa-lib 1.0.10+ to be required on 2.6.14 and up. These
types of incompatible changes should be rare.
It was a necessary precursor to fixing the well known "master volume
only controls front speakers" bug.
Lee
Hi!
> > I'm still using 1.0.9 on 2.6.16-rc4 with no problems, Audigy 2 (one
> > that uses
> > emu10k1).
>
> It's a specific change to the SBLive! that did not affect the Audigy
> that causes alsa-lib 1.0.10+ to be required on 2.6.14 and up. These
> types of incompatible changes should be rare.
Do you have that patch somewhere handy?
How do I tell alsa-lib version?
Does alsa-lib bug still affect me when I'm using oss emulation?
> It was a necessary precursor to fixing the well known "master volume
> only controls front speakers" bug.
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
On Mon, 2006-02-20 at 00:46 +0100, Pavel Machek wrote:
> Hi!
>
> > > I'm still using 1.0.9 on 2.6.16-rc4 with no problems, Audigy 2 (one
> > > that uses
> > > emu10k1).
> >
> > It's a specific change to the SBLive! that did not affect the Audigy
> > that causes alsa-lib 1.0.10+ to be required on 2.6.14 and up. These
> > types of incompatible changes should be rare.
>
> Do you have that patch somewhere handy?
>
Attached
> How do I tell alsa-lib version?
>
Check your distro's package manager.
> Does alsa-lib bug still affect me when I'm using oss emulation?
>
No.
> > It was a necessary precursor to fixing the well known "master volume
> > only controls front speakers" bug.
>
> Pavel
On Sunday 19 February 2006 23:32, Lee Revell wrote:
> On Sun, 2006-02-19 at 23:23 +0000, Alistair John Strachan wrote:
> > I'm still using 1.0.9 on 2.6.16-rc4 with no problems, Audigy 2 (one
> > that uses
> > emu10k1).
>
> It's a specific change to the SBLive! that did not affect the Audigy
> that causes alsa-lib 1.0.10+ to be required on 2.6.14 and up. These
> types of incompatible changes should be rare.
>
> It was a necessary precursor to fixing the well known "master volume
> only controls front speakers" bug.
Thanks for this info Lee, and understand I don't hold anybody specifically in
the alsa team responsible but *deep breath*:
Please let everybody know about incompatible changes to alsa-lib know about it
prior to making the change mandatory.
This means immediately update http://www.alsa-project.org/ with the
information. I do not mean add a one-liner to the changelog.
ALSA's great and I wholeheartedly support it, but this sort of thing cannot
happen without informing people about the requirement. Expecting people to
"just upgrade" is frankly not acceptable. At all. We're not using Rawhide.
--
Cheers,
Alistair.
'No sense being pessimistic, it probably wouldn't work anyway.'
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
On 19.02.2006 [18:53:41 -0500], Lee Revell wrote:
> On Mon, 2006-02-20 at 00:46 +0100, Pavel Machek wrote:
> > Hi!
> >
> > > > I'm still using 1.0.9 on 2.6.16-rc4 with no problems, Audigy 2
> > > > (one that uses emu10k1).
> > >
> > > It's a specific change to the SBLive! that did not affect the
> > > Audigy that causes alsa-lib 1.0.10+ to be required on 2.6.14 and
> > > up. These types of incompatible changes should be rare.
> >
> > Do you have that patch somewhere handy?
> >
>
> Attached
>
> > How do I tell alsa-lib version?
> >
>
> Check your distro's package manager.
Hrm, I didn't mention any alsalib version, because this is what apt told
me:
root@arkanoid:/home/nacc# aptitude search alsa | grep ^i
i alsa-base - ALSA driver configuration files
i alsa-utils - ALSA utilities
root@arkanoid:/home/nacc# aptitude search alsa | grep lib
v alsalib -
v alsalib0.1.3 -
v alsalib0.3.0 -
v alsalib0.3.0-dev -
v alsalib0.3.2 -
v alsalib0.3.2-dev -
Am I missing something?
Thanks,
Nish
On Sun, 2006-02-19 at 23:56 +0000, Alistair John Strachan wrote:
> Thanks for this info Lee, and understand I don't hold anybody
> specifically in
> the alsa team responsible but *deep breath*:
>
> Please let everybody know about incompatible changes to alsa-lib know
> about it
> prior to making the change mandatory.
I thought it was already common knowledge that alsa-lib should be
upgraded when upgrading the kernel.
Each ALSA driver has both a userspace and a kernel component so alsa-lib
has to be upgraded to get new drivers anyway.
Lee
On Sun, 2006-02-19 at 16:04 -0800, Nishanth Aravamudan wrote:
> root@arkanoid:/home/nacc# aptitude search alsa | grep ^i
> i alsa-base - ALSA driver configuration files
> i alsa-utils - ALSA utilities
> root@arkanoid:/home/nacc# aptitude search alsa | grep lib
> v alsalib -
> v alsalib0.1.3 -
> v alsalib0.3.0 -
> v alsalib0.3.0-dev -
> v alsalib0.3.2 -
> v alsalib0.3.2-dev -
>
Some distros call it "libasound".
Lee
On Sun, 19 Feb 2006, Lee Revell wrote:
> On Sun, 2006-02-19 at 23:56 +0000, Alistair John Strachan wrote:
>> Thanks for this info Lee, and understand I don't hold anybody
>> specifically in
>> the alsa team responsible but *deep breath*:
>>
>> Please let everybody know about incompatible changes to alsa-lib know
>> about it
>> prior to making the change mandatory.
>
> I thought it was already common knowledge that alsa-lib should be
> upgraded when upgrading the kernel.
it's not (at least among general Linux users, it probably is among alsa
developers).
Especially after the comments that Linus made a few months ago about how
important it is to not break userspace interfaces.
> Each ALSA driver has both a userspace and a kernel component so alsa-lib
> has to be upgraded to get new drivers anyway.
but people frequently upgrade kernels on existing machines so they aren't
after new drivers.
if alsalib really needs to be upgraded in lockstep with the kernel then it
should be included with the kernel (and it still leaves people in trouble
when they need to shift back and forth between two different kernels, how
do you select the alsalib version to use on boot to make it match the
kernel you booted from?)
David Lang
> Lee
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
-- C.A.R. Hoare
On Monday 20 February 2006 00:12, David Lang wrote:
> On Sun, 19 Feb 2006, Lee Revell wrote:
> > On Sun, 2006-02-19 at 23:56 +0000, Alistair John Strachan wrote:
> >> Thanks for this info Lee, and understand I don't hold anybody
> >> specifically in
> >> the alsa team responsible but *deep breath*:
> >>
> >> Please let everybody know about incompatible changes to alsa-lib know
> >> about it
> >> prior to making the change mandatory.
> >
> > I thought it was already common knowledge that alsa-lib should be
> > upgraded when upgrading the kernel.
>
> it's not (at least among general Linux users, it probably is among alsa
> developers).
I agree, and should I not have had an SBLive Version Voodoo with Problem X, I
wouldn't need to upgrade, would I?
This isn't an acceptable solution. Upgrades that aren't subsuming an existing,
working codebase need to be explained. And I'll read that explanation and
decide whether to upgrade. That's how it should be, period.
--
Cheers,
Alistair.
'No sense being pessimistic, it probably wouldn't work anyway.'
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
On Sun, 2006-02-19 at 16:12 -0800, David Lang wrote:
>
> it's not (at least among general Linux users, it probably is among
> alsa
> developers).
>
> Especially after the comments that Linus made a few months ago about
> how
> important it is to not break userspace interfaces.
In the future this will be the case, this change occured before that
statement from Linus.
Lee
Hi!
> > > > I'm still using 1.0.9 on 2.6.16-rc4 with no problems, Audigy 2 (one
> > > > that uses
> > > > emu10k1).
> > >
> > > It's a specific change to the SBLive! that did not affect the Audigy
> > > that causes alsa-lib 1.0.10+ to be required on 2.6.14 and up. These
> > > types of incompatible changes should be rare.
> >
> > Do you have that patch somewhere handy?
> >
>
> Attached
Thanks, I tried that. No change, AFAICT.
> > How do I tell alsa-lib version?
> >
>
> Check your distro's package manager.
Heh..
root@hobit:~# apt-cache show libasound1
Package: libasound1
Status: install ok installed
Priority: optional
Section: libs
Installed-Size: 148
Maintainer: Masato Taruishi <[email protected]>
Source: alsa-lib-0.5
Version: 0.5.10b-1
~~~~~~~~~~~~~~~~~~
:-(
...but if I launch plain old aumix, I should be able to unmute it and
use normally... and that is not the case :-(.
> > > It was a necessary precursor to fixing the well known "master volume
> > > only controls front speakers" bug.
> >
> > Pavel
> -stable review patch. If anyone has any objections, please let us know.
> ------------------
>
> Fix the confliction of 'Front' controls on models with STAC9758 codec.
>
> Signed-off-by: Takashi Iwai <[email protected]>
> Signed-off-by: Chris Wright <[email protected]>
> ---
>
> sound/pci/emu10k1/emumixer.c | 2 ++
> 1 files changed, 2 insertions(+)
>
> Index: linux-2.6.15.3/sound/pci/emu10k1/emumixer.c
> ===================================================================
> --- linux-2.6.15.3.orig/sound/pci/emu10k1/emumixer.c
> +++ linux-2.6.15.3/sound/pci/emu10k1/emumixer.c
> @@ -750,6 +750,8 @@ int __devinit snd_emu10k1_mixer(emu10k1_
> "Master Mono Playback Volume",
> "PCM Out Path & Mute",
> "Mono Output Select",
> + "Front Playback Switch",
> + "Front Playback Volume",
> "Surround Playback Switch",
> "Surround Playback Volume",
> "Center Playback Switch",
>
> --
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
On Mon, 2006-02-20 at 01:26 +0100, Pavel Machek wrote:
> ...but if I launch plain old aumix, I should be able to unmute it and
> use normally... and that is not the case :-(.
Do you have a "libasound2"?
Lee
On Sun, 2006-02-19 at 22:44 +0100, Pavel Machek wrote:
> Hi!
>
> > > I tried enabled everything I could in alsamixer, but still could not
> > > get it to produce some sound :-(.
> >
> > Is 2.6.15.4 also broken?
>
> 2.6.15.4 does not have support for my SATA controller, so it would be
> quite complex to test that... I may have something wrong with
> userspace, but alsamixer all to max, then cat /bin/bash > /dev/dsp
> should produce some sound, no?
So this isn't necessarily a regression - it's possible this device never
worked?
Creative has been known in the past to release 2 devices with identical
serial numbers and different AC97 codecs. Stuff like this is why it's
almot impossible to prevent all driver regressions unless you can test
every supported card...
Lee
On Ne 19-02-06 19:33:54, Lee Revell wrote:
> On Sun, 2006-02-19 at 22:44 +0100, Pavel Machek wrote:
> > Hi!
> >
> > > > I tried enabled everything I could in alsamixer, but still could not
> > > > get it to produce some sound :-(.
> > >
> > > Is 2.6.15.4 also broken?
> >
> > 2.6.15.4 does not have support for my SATA controller, so it would be
> > quite complex to test that... I may have something wrong with
> > userspace, but alsamixer all to max, then cat /bin/bash > /dev/dsp
> > should produce some sound, no?
>
> So this isn't necessarily a regression - it's possible this device never
> worked?
>
> Creative has been known in the past to release 2 devices with identical
> serial numbers and different AC97 codecs. Stuff like this is why it's
> almot impossible to prevent all driver regressions unless you can test
> every supported card...
It did work _long_ time ago, and in different machine. Definitely not
in 2.6.15... maybe in 2.6.5.
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
On Ne 19-02-06 19:30:32, Lee Revell wrote:
> On Mon, 2006-02-20 at 01:26 +0100, Pavel Machek wrote:
> > ...but if I launch plain old aumix, I should be able to unmute it and
> > use normally... and that is not the case :-(.
>
> Do you have a "libasound2"?
Yes:
root@hobit:~# apt-cache show libasound2
Package: libasound2
Priority: optional
Section: libs
Installed-Size: 1052
Maintainer: Debian ALSA Maintainers
<[email protected]>
Architecture: i386
Source: alsa-lib
Version: 1.0.10-2
Depends: libc6 (>= 2.3.5-1)
Suggests: libasound2-plugins (>= 1.0.9)
Conflicts: libasound2-plugins (<< 1.0.9)
Filename: pool/main/a/alsa-lib/libasound2_1.0.10-2_i386.deb
Size: 309306
MD5sum: ab533c9ae6537af36652bf7d88a7f129
Description: ALSA library
This package contains the ALSA library and its standard
plugins.
.
ALSA is the Advanced Linux Sound Architecture.
Tag: devel::library, role::sw:shlib, works-with::audio
root@hobit:~# apt-get install libasound2
Reading package lists... Done
Building dependency tree... Done
libasound2 is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 605 not upgraded.
root@hobit:~#
[Lost in the maze of alsa libraries, all alike.]
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
On Mon, 2006-02-20 at 01:42 +0100, Pavel Machek wrote:
> On Ne 19-02-06 19:30:32, Lee Revell wrote:
> > On Mon, 2006-02-20 at 01:26 +0100, Pavel Machek wrote:
> > > ...but if I launch plain old aumix, I should be able to unmute it and
> > > use normally... and that is not the case :-(.
> >
> > Do you have a "libasound2"?
>
> Yes:
> Source: alsa-lib
> Version: 1.0.10-2
Should be fine. And the fact that OSS emulation is broken kind of rules
out the alsa-lib problem.
This does not sound like any problem we know about. Are you sure the
hardware is still OK? Do any of the channels work (try "speaker-test -D
surround51 --channels 6" while plugging your speakers into front, read,
center/lfe jacks).
Any chance of trying it in another machine?
Lee
On 19.02.2006 [19:11:08 -0500], Lee Revell wrote:
> On Sun, 2006-02-19 at 16:04 -0800, Nishanth Aravamudan wrote:
> > root@arkanoid:/home/nacc# aptitude search alsa | grep ^i
> > i alsa-base - ALSA driver configuration files
> > i alsa-utils - ALSA utilities
> > root@arkanoid:/home/nacc# aptitude search alsa | grep lib
> > v alsalib -
> > v alsalib0.1.3 -
> > v alsalib0.3.0 -
> > v alsalib0.3.0-dev -
> > v alsalib0.3.2 -
> > v alsalib0.3.2-dev -
> >
>
> Some distros call it "libasound".
Ah ha! Thanks, Lee.
alsa-lib = 1.0.9-2
Thanks,
Nish
On Monday 20 February 2006 00:39, Pavel Machek wrote:
> On Ne 19-02-06 19:33:54, Lee Revell wrote:
> > On Sun, 2006-02-19 at 22:44 +0100, Pavel Machek wrote:
> > > Hi!
> > >
> > > > > I tried enabled everything I could in alsamixer, but still could
> > > > > not get it to produce some sound :-(.
> > > >
> > > > Is 2.6.15.4 also broken?
> > >
> > > 2.6.15.4 does not have support for my SATA controller, so it would be
> > > quite complex to test that... I may have something wrong with
> > > userspace, but alsamixer all to max, then cat /bin/bash > /dev/dsp
> > > should produce some sound, no?
> >
> > So this isn't necessarily a regression - it's possible this device never
> > worked?
> >
> > Creative has been known in the past to release 2 devices with identical
> > serial numbers and different AC97 codecs. Stuff like this is why it's
> > almot impossible to prevent all driver regressions unless you can test
> > every supported card...
>
> It did work _long_ time ago, and in different machine. Definitely not
> in 2.6.15... maybe in 2.6.5.
With ALSA? Any chance the card is physically damaged? Try using the OSS driver
if it's still around, then you'll have a solid case to take up with Takashi.
--
Cheers,
Alistair.
'No sense being pessimistic, it probably wouldn't work anyway.'
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
At Sun, 19 Feb 2006 23:25:33 +0100,
Pavel Machek wrote:
>
> On Ne 19-02-06 16:54:34, Lee Revell wrote:
> > On Sun, 2006-02-19 at 22:49 +0100, Pavel Machek wrote:
> > > Hi!
> > >
> > > > > I run Ubuntu Breezy, which has:
> > > > >
> > > > > alsa-utils = 1.0.9a-4ubuntu5
> > > >
> > > > The alsa-utils version should not matter, it's alsa-lib that must be
> > > > kept in sync with the ALSA version in the kernel.
> > >
> > > I tried to play with mpg123 using OSS emulation, so that it does not
> > > have anything to do with ALSA. No luck. Trying aplay:
> > >
> > > root@hobit:/dev/snd# aplay
> > > /usr/share/xemacs21/xemacs-packages/etc/sounds/hammer.wav
> > > aplay: main:533: audio open error: No such file or directory
> > >
> > > while stracing:
> > >
> > > open("/dev/snd/pcmC0D0p", O_RDWR) = -1 ENOENT (No such file or
> > > directory)
> > > close(3) = 0
> > > write(2, "aplay: main:533: ", 17aplay: main:533: ) = 17
> > > write(2, "audio open error: No such file o"..., 43audio open error: No
> > > such file or directory) = 43
> > > write(2, "\n", 1
> > >
> > > ... but pcmC0D0p is not described in devices.txt...?
> >
> > Hmm, that's a udev problem or something. If you have a static dev the
> > snddevices script that comes with ALSA will create the device files.
>
> I'm using static /dev... snddevices script indeed fixed that, but it
> still does not work. (Is earphone in green connector enough?)
Likely -EUDEV?
> Ouch and that device should be still listed in devices.txt, no?
The minor numbers can be assigned dyanmically if
CONFIG_SND_DYNAMIC_MINORS is set, so it may be even confusing to list
up there as if static only.
> root@hobit:/dev/snd# aplay
> /usr/share/xemacs21/xemacs-packages/etc/sounds/hammer.wav
> Playing WAVE
> '/usr/share/xemacs21/xemacs-packages/etc/sounds/hammer.wav' : Unsigned
> 8 bit, Rate 8000 Hz, Mono
> root@hobit:/dev/snd#
>
> Actually, in a quiet room I think I can hear *something*. Too faint to
> recognize :-(.
If you hear something, it's definitely a mixer configuration problem,
maybe screwed up by some reason. In such a case, it's easier to
re-initialize from the scratch:
Unload the module first, then remove /etc/asound.state (or whatever
the distro uses) to prevent the automatic "alsactl restore".
Reload the module, then unmute/adjust the volume "PCM" and "Master".
The other volumes should have been initialized to be audible.
Takashi
Hi!
> > Ouch and that device should be still listed in devices.txt, no?
>
> The minor numbers can be assigned dyanmically if
> CONFIG_SND_DYNAMIC_MINORS is set, so it may be even confusing to list
> up there as if static only.
Well, you should list them there, so they are properly allocated to
you... Or just list the numbers for !SND_DYNAMIC_MINORS case, and add
a warning.
> > root@hobit:/dev/snd# aplay
> > /usr/share/xemacs21/xemacs-packages/etc/sounds/hammer.wav
> > Playing WAVE
> > '/usr/share/xemacs21/xemacs-packages/etc/sounds/hammer.wav' : Unsigned
> > 8 bit, Rate 8000 Hz, Mono
> > root@hobit:/dev/snd#
> >
> > Actually, in a quiet room I think I can hear *something*. Too faint to
> > recognize :-(.
>
> If you hear something, it's definitely a mixer configuration problem,
> maybe screwed up by some reason. In such a case, it's easier to
> re-initialize from the scratch:
It may me EMI or something like that. I can hear something but it is
so faint I'm not sure if I'm not hearing power drawn from CPU.
> Unload the module first, then remove /etc/asound.state (or whatever
> the distro uses) to prevent the automatic "alsactl restore".
> Reload the module, then unmute/adjust the volume "PCM" and "Master".
> The other volumes should have been initialized to be audible.
I do not think I have alsactl restore anywhere in the bootup
scripts. I'll play with that, and I'll also try OSS driver to see if
hardware still works properly.
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
On Sunday 19 February 2006 20:31, you wrote:
> On Sun, 2006-02-19 at 20:20 +0000, Nick Warne wrote:
> > On Sunday 19 February 2006 19:29, Lee Revell wrote:
> > > > And now the confusing bit. If I run alsamixer but DO NOT DO
> > > > ANYTHING, exit, then issue 'alsactl store', then 'alsactl restore'
> > > > works again OK - until next reboot...
> > >
> > > Sounds like you have 2 different alsactls installed. The ALSA default
> > > one saves the mixer state in /etc/asound.state but lots of distros hack
> > > it up to save the state somewhere under /var.
> > >
> > > Use "alsactl -f" to force a restore of mixer state even if the mixer
> > > controls have changed (distros should do this by default but don't).
> >
> > Lee,
> >
> > Everybody here keeps saying that to me - I _don't_ have two alsactl's, I
> > _don't_ have 2 asound.states (or more/any other alsactl files).
> >
> > My base is Slackware 10 - a pretty clean distro.
> >
> > Tonight my MIC is not working again from a reboot, and I can't get it
> > going like I did before (??)...
> >
> > Every reboot 'alsactl restore' breaks on one control or another now.
> >
> > You mean -F too? I don't understand why I should have to use --force.
> >
> > It's a mystery?
>
> Sorry, no idea. You'll have to do a binary search with ALSA CVS to find
> out exactly when it broke.
I have a mystery here guys.
Tonight I tested. I set up my system so that both sudo and root could
`alsactl store/restore' using -f to explicitly use /etc/asound.state.
Once both user and root could store/restore with no errors, and all my apps
work (midi, mic, KDE sound etc. etc.) I made /etc/asound.state immutable:
nick@linuxamd:nick$ lsattr /etc/asound.state
----i-------- /etc/asound.state
I then edited /etc/rc.d/rc/alsa to use the -f and expilicity point
to /etc/asound.state
Rebooted...
Loading ALSA mixer settings: /usr/sbin/alsactl restore
/usr/sbin/alsactl: set_control:894: warning: name mismatch (Mic Select/3D
Control Sigmatel - Depth) for control #74
/usr/sbin/alsactl: set_control:896: warning: index mismatch (0/0) for control
#74
/usr/sbin/alsactl: set_control:994: bad control.74.value type
Heh. Every reboot I get a different control error. But why it all works OK
before a reboot with the same very /etc/asound.state file I don't know.
Nick
--
"Person who say it cannot be done should not interrupt person doing it."
-Chinese Proverb
On Monday 20 February 2006 14:18, Nick Warne wrote:
<snip>
> Loading ALSA mixer settings: /usr/sbin/alsactl restore
> /usr/sbin/alsactl: set_control:894: warning: name mismatch (Mic Select/3D
> Control Sigmatel - Depth) for control #74
> /usr/sbin/alsactl: set_control:896: warning: index mismatch (0/0) for
> control #74
> /usr/sbin/alsactl: set_control:994: bad control.74.value type
>
> Heh. Every reboot I get a different control error. But why it all works
> OK before a reboot with the same very /etc/asound.state file I don't know.
I had a similar problem, but solved that with an upgrade of alsa-lib.
I've been following this thread, because apparently my SB Live! isn't
supported by ALSA either. I need to use the gnome mixer to affect any change
in sound levels... Apparently none of the numerous controls offered by
alsamixer and kmix work.
Attached is the lspci output for the card.
0000:00:10.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev
07)
Subsystem: Creative Labs CT4780 SBLive! Value
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 64 (500ns min, 5000ns max)
Interrupt: pin A routed to IRQ 9
Region 0: I/O ports at 1460
Capabilities: [dc] Power Management version 1
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0000:00:10.1 Input device controller: Creative Labs SB Live! MIDI/Game Port
(rev 07)
Subsystem: Creative Labs Gameport Joystick
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 64
Region 0: I/O ports at 14a8
Capabilities: [dc] Power Management version 1
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Alsa reports it as "unknown" but functions well. To my knowledge the card came
as OEM equipment on a Dell XPS-T850r, so I told ALSA to use the "Dell OEM"
driver in the kernel. Before updating alsa-lib I had the problem with the
controls. Now all I have is the fact that it seems nothing allows me to
change the sound level programatically except the gnome mixer.
DRH
On Mon, Feb 20, 2006 at 12:41:29PM +0100, Pavel Machek wrote:
> > If you hear something, it's definitely a mixer configuration problem,
> > maybe screwed up by some reason. In such a case, it's easier to
> > re-initialize from the scratch:
>
> It may me EMI or something like that. I can hear something but it is
> so faint I'm not sure if I'm not hearing power drawn from CPU.
My Live! died some time ago with similar symptoms. I had a second one so
I could verify it's the hardware and not a driver bug.
--
Vojtech Pavlik
Director SuSE Labs
On Po 20-02-06 20:50:36, Vojtech Pavlik wrote:
> On Mon, Feb 20, 2006 at 12:41:29PM +0100, Pavel Machek wrote:
>
> > > If you hear something, it's definitely a mixer configuration problem,
> > > maybe screwed up by some reason. In such a case, it's easier to
> > > re-initialize from the scratch:
> >
> > It may me EMI or something like that. I can hear something but it is
> > so faint I'm not sure if I'm not hearing power drawn from CPU.
>
> My Live! died some time ago with similar symptoms. I had a second one so
> I could verify it's the hardware and not a driver bug.
Warning, there are many similar, but not the same SB Live!s...
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
On Po 20-02-06 01:33:26, Alistair John Strachan wrote:
> On Monday 20 February 2006 00:39, Pavel Machek wrote:
> > On Ne 19-02-06 19:33:54, Lee Revell wrote:
> > > On Sun, 2006-02-19 at 22:44 +0100, Pavel Machek wrote:
> > > > Hi!
> > > >
> > > > > > I tried enabled everything I could in alsamixer, but still could
> > > > > > not get it to produce some sound :-(.
> > > > >
> > > > > Is 2.6.15.4 also broken?
> > > >
> > > > 2.6.15.4 does not have support for my SATA controller, so it would be
> > > > quite complex to test that... I may have something wrong with
> > > > userspace, but alsamixer all to max, then cat /bin/bash > /dev/dsp
> > > > should produce some sound, no?
> > >
> > > So this isn't necessarily a regression - it's possible this device never
> > > worked?
> > >
> > > Creative has been known in the past to release 2 devices with identical
> > > serial numbers and different AC97 codecs. Stuff like this is why it's
> > > almot impossible to prevent all driver regressions unless you can test
> > > every supported card...
> >
> > It did work _long_ time ago, and in different machine. Definitely not
> > in 2.6.15... maybe in 2.6.5.
>
> With ALSA? Any chance the card is physically damaged? Try using the OSS driver
> if it's still around, then you'll have a solid case to take up with Takashi.
I tried OSS driver, no luck. Vojtech reports card from same batch
failed for him.... He still has one more working...
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
Hi!
> > I have SB Live! here. I remember it worked long time ago. Now I can't
> > get it to produce any sound :-(.
> >
> > root@hobit:~# cat /proc/asound/cards
> > 0 [Live ]: EMU10K1 - SBLive! Value [CT4830]
> > SBLive! Value [CT4830] (rev.7,
> > serial:0x80261102) at 0x3000, irq 20
> > 1 [Bt878 ]: Bt87x - Brooktree Bt878
> > Brooktree Bt878 at 0xd0001000, irq 17
> >
> > root@hobit:~# uname -a
> > Linux hobit 2.6.16-rc4 #1 SMP PREEMPT Sat Feb 18 23:53:41 CET 2006
> > i686 GNU/Linux
> >
>
> I've got an SB Live! card here as well. Not exactely the same as yours
> (mine's rev. 10, yours is rev. 7), but mine works just fine with
> 2.6.16-rc4, so whatever is wrong it does not seem to effect all SB
> Live! cards...
Strange... My sb live! did not work with linux: all seemed okay,
but no sound, oss or alsa. My brother moved it on windows PC,
and got same failure, then bluescreens on next boots. He reseated the
card, and it started working. I guess it is flakey hw...
--
Thanks, Sharp!
At Sun, 19 Feb 2006 19:19:07 +0000,
Pavel Machek wrote:
>
> Hi!
>
> > > I have SB Live! here. I remember it worked long time ago. Now I can't
> > > get it to produce any sound :-(.
> > >
> > > root@hobit:~# cat /proc/asound/cards
> > > 0 [Live ]: EMU10K1 - SBLive! Value [CT4830]
> > > SBLive! Value [CT4830] (rev.7,
> > > serial:0x80261102) at 0x3000, irq 20
> > > 1 [Bt878 ]: Bt87x - Brooktree Bt878
> > > Brooktree Bt878 at 0xd0001000, irq 17
> > >
> > > root@hobit:~# uname -a
> > > Linux hobit 2.6.16-rc4 #1 SMP PREEMPT Sat Feb 18 23:53:41 CET 2006
> > > i686 GNU/Linux
> > >
> >
> > I've got an SB Live! card here as well. Not exactely the same as yours
> > (mine's rev. 10, yours is rev. 7), but mine works just fine with
> > 2.6.16-rc4, so whatever is wrong it does not seem to effect all SB
> > Live! cards...
>
> Strange... My sb live! did not work with linux: all seemed okay,
> but no sound, oss or alsa. My brother moved it on windows PC,
> and got same failure, then bluescreens on next boots. He reseated the
> card, and it started working. I guess it is flakey hw...
I remember that I had a sb live which worked only on a certain slot
near a network card. Though, it hanged up instead of noises/silences
in my case.
Takashi