1 Aug
2007
1 Aug
'07
4:07 p.m.
Greetings!
I've a very annoying problem with ALSA on my new Toshiba P205: I can not
mute speakers when headphones are connected via a jack. There is an
option in alsamixer called 'headphone' that just enables the sound in
the jack, but does NOT mute the speakers.
Can anybody help? lsmod and lspci output attached.
Ubuntu Gusty tribe 2, kernel 2.6.22
Other 'strange' things:
1) option 'caller id'. No idea what it is.
2) option 'off-hook'. No idea what it is.
3) channel called 'speakers' does not control sound level or mute the
speakers!
Thanks!!!
--
Michael Baranov
Module Size Used by
i915 25472 2
drm 83348 3 i915
acpi_cpufreq 10568 1
cpufreq_stats 7232 0
cpufreq_ondemand 9228 1
freq_table 5792 3 acpi_cpufreq,cpufreq_stats,cpufreq_ondemand
cpufreq_userspace 5280 0
cpufreq_powersave 2688 0
cpufreq_conservative 8072 0
container 5504 0
video 17544 0
sbs 19592 0
button 8848 0
asus_acpi 17308 0
dock 10528 0
battery 11012 0
ac 6148 0
sbp2 24200 0
parport_pc 37412 0
lp 12580 0
parport 37448 2 parport_pc,lp
fuse 47124 0
af_packet 24840 4
snd_hda_intel 256024 1
pcmcia 41388 0
snd_pcm_oss 44672 0
snd_mixer_oss 17664 1 snd_pcm_oss
snd_pcm 80388 2 snd_hda_intel,snd_pcm_oss
snd_seq_dummy 4740 0
snd_seq_oss 33152 0
snd_seq_midi 9600 0
joydev 11328 0
snd_rawmidi 25728 1 snd_seq_midi
wlan_scan_sta 15104 1
snd_seq_midi_event 8448 2 snd_seq_oss,snd_seq_midi
uvcvideo 43012 0
ath_rate_sample 14208 1
tifm_7xx1 8576 0
iTCO_wdt 11940 0
videodev 29312 1 uvcvideo
v4l1_compat 15364 2 uvcvideo,videodev
v4l2_common 18432 2 uvcvideo,videodev
iTCO_vendor_support 4868 1 iTCO_wdt
tifm_core 11268 1 tifm_7xx1
snd_seq 53232 6 snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_seq_midi_event
yenta_socket 27532 1
sdhci 18700 0
mmc_core 28420 1 sdhci
ath_pci 97824 0
wlan 205252 4 wlan_scan_sta,ath_rate_sample,ath_pci
snd_timer 24324 2 snd_pcm,snd_seq
snd_seq_device 9228 5
snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_rawmidi,snd_seq
rsrc_nonstatic 14080 1 yenta_socket
ath_hal 192720 3 ath_rate_sample,ath_pci
pcmcia_core 40980 3 pcmcia,yenta_socket,rsrc_nonstatic
serio_raw 8068 0
psmouse 39952 0
snd 54660 11
snd_hda_intel,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_seq_oss,snd_rawmidi,snd_seq,snd_timer,snd_seq_device
soundcore 8800 1 snd
snd_page_alloc 10888 2 snd_hda_intel,snd_pcm
intel_agp 25364 1
agpgart 35016 3 drm,intel_agp
shpchp 34580 0
pci_hotplug 32704 1 shpchp
evdev 11136 5
ipv6 273892 16
ext3 133768 1
jbd 60456 1 ext3
mbcache 9732 1 ext3
sg 36764 0
sr_mod 17828 0
cdrom 37536 1 sr_mod
sd_mod 30336 3
usbhid 29536 0
hid 28928 1 usbhid
ata_piix 15748 2
ohci1394 36528 0
ehci_hcd 36108 0
ieee1394 96312 2 sbp2,ohci1394
ata_generic 8452 0
libata 127856 2 ata_piix,ata_generic
scsi_mod 147084 5 sbp2,sg,sr_mod,sd_mod,libata
uhci_hcd 26640 0
r8169 32392 0
usbcore 137480 5 uvcvideo,usbhid,ehci_hcd,uhci_hcd
thermal 14344 0
processor 31944 2 acpi_cpufreq,thermal
fan 5764 0
capability 5896 0
commoncap 8320 1 capability
00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT Express Memory
Controller Hub (rev 03)
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS/940GML Express
Integrated Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/940GML Express Integrated
Graphics Controller (rev 03)
00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio
Controller (rev 02)
00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 02)
00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 02)
00:1c.2 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 3 (rev 02)
00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #3 (rev 02)
00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #4 (rev 02)
00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev
02)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2)
00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 02)
00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) Serial ATA Storage
Controller IDE (rev 02)
00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 02)
04:00.0 Ethernet controller: Atheros Communications, Inc. Unknown device 001c (rev 01)
05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8101E PCI Express Fast
Ethernet controller (rev 01)
06:04.0 CardBus bridge: Texas Instruments PCIxx12 Cardbus Controller
06:04.1 FireWire (IEEE 1394): Texas Instruments PCIxx12 OHCI Compliant IEEE 1394 Host
Controller
06:04.2 Mass storage controller: Texas Instruments 5-in-1 Multimedia Card Reader
(SD/MMC/MS/MS PRO/xD)
06:04.3 Generic system peripheral [0805]: Texas Instruments PCIxx12 SDA Standard Compliant
SD Host Controller
1 Aug
1 Aug
7:34 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, Aug 01, 2007 at 08:54:46PM +0300, Michael Baranov wrote:
Greetings!
I've a very annoying problem with ALSA on my new Toshiba P205: I can not
mute speakers when headphones are connected via a jack. There is an
option in alsamixer called 'headphone' that just enables the sound in
the jack, but does NOT mute the speakers.
Can anybody help? lsmod and lspci output attached.
Ubuntu Gusty tribe 2, kernel 2.6.22
Other 'strange' things:
1) option 'caller id'. No idea what it is.
2) option 'off-hook'. No idea what it is.
3) channel called 'speakers' does not control sound level or mute the
speakers!
Ask on ALSA list, but, last I checked, hda-intel == useless peice of shit.
I gave up after being told that there was no hope of hda-intel ever working properly on
linux. I use an external sound device (M-Audio FastTrack Pro USB) and it works
beautifully.
Even a cheap US$8 USB audio dongle worked well, and much better than the hda-intel.
- -ken
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFGsPxSe8HF+6xeOIcRAgKVAJ9k0CEdFyGmO7ki8L9H1AwH7f9GmwCeNqb4
kDPtSvz8bWwnRGtHP4Z8J98=
=Tjw1
-----END PGP SIGNATURE-----
7:58 p.m.
The reason you see the options for "caller ID" and "off hook" is that
the Intel HDA chipset also includes a modem. My laptop uses Intel HDA,
and I'm used to the modem part showing up as if it were an audio device.
The audio works on my laptop except for an inability to record from the
mic input. Last I heard, ALSA was blaming the kernel, and kernel
developers were blaming ALSA. Although I haven't tried it since my most
recent kernel update.
$8 USB audio dongle? Where did you find such a thing? Tell me more.
David
gnome(a)hawaii.rr.com
authenticity, honesty, community
----- Original Message -----
From: Ken Restivo <ken(a)restivo.org>
Date: Wednesday, August 1, 2007 11:34 am
Subject: Re: [LAU] mute laptop speakers with Intel HDA
To: A list for linux audio users <linux-audio-user(a)lists.linuxaudio.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, Aug 01, 2007 at 08:54:46PM +0300, Michael Baranov wrote:
Greetings!
I've a very annoying problem with ALSA on my new Toshiba P205: I
can not
mute speakers when headphones are connected via a
jack. There is an
option in alsamixer called 'headphone' that just enables the
sound in
the jack, but does NOT mute the speakers.
Can anybody help? lsmod and lspci output attached.
Ubuntu Gusty tribe 2, kernel 2.6.22
Other 'strange' things:
1) option 'caller id'. No idea what it is.
2) option 'off-hook'. No idea what it is.
3) channel called 'speakers' does not control sound level or
mute the
speakers!
Ask on ALSA list, but, last I checked, hda-intel == useless peice
of shit.
I gave up after being told that there was no hope of hda-intel
ever working properly on linux. I use an external sound device (M-
Audio FastTrack Pro USB) and it works beautifully.
Even a cheap US$8 USB audio dongle worked well, and much better
than the hda-intel.
- -ken
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFGsPxSe8HF+6xeOIcRAgKVAJ9k0CEdFyGmO7ki8L9H1AwH7f9GmwCeNqb4
kDPtSvz8bWwnRGtHP4Z8J98=
=Tjw1
-----END PGP SIGNATURE-----
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-user
10:54 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, Aug 01, 2007 at 11:58:41AM -1000, gnome(a)hawaii.rr.com wrote:
The reason you see the options for "caller
ID" and "off hook" is that
the Intel HDA chipset also includes a modem. My laptop uses Intel HDA,
and I'm used to the modem part showing up as if it were an audio device.
The audio works on my laptop except for an inability to record from the
mic input. Last I heard, ALSA was blaming the kernel, and kernel
developers were blaming ALSA. Although I haven't tried it since my most
recent kernel update.
The culprit is, as it often is, neither the kernel nor the ALSA.
The bad actor the hardware manufacturer. Apparently the chip is not well-specified, and
hardware manufacturers just do their own thing, without documenting it, and write
proprietary drivers "which make it work" in Windoze and OSX.
$8 USB audio dongle? Where did you find such a thing? Tell me more.
Ebay, about a year ago.
- -ken
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFGsSs7e8HF+6xeOIcRAm4FAJ4uffiRz8QNN21WomyT1pY0OuGVDwCfYDQE
zH0IDY9IHFBViiLdHgiLV2k=
=N7B9
-----END PGP SIGNATURE-----
2 Aug
2 Aug
12:11 a.m.
On 8/1/07, Ken Restivo <ken(a)restivo.org> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, Aug 01, 2007 at 11:58:41AM -1000, gnome(a)hawaii.rr.com wrote:
Actually the HDA intel situation is getting better - apparently, the
correct initializations needed to make a given device work can be
extracted from the .inf file of the windows driver. Not sure exactly
how it's done, but it's definitely possible...
Lee
The reason you see the options for "caller
ID" and "off hook" is that
the Intel HDA chipset also includes a modem. My laptop uses Intel HDA,
and I'm used to the modem part showing up as if it were an audio device.
The audio works on my laptop except for an inability to record from the
mic input. Last I heard, ALSA was blaming the kernel, and kernel
developers were blaming ALSA. Although I haven't tried it since my most
recent kernel update.
The culprit is, as it often is, neither the kernel nor the ALSA.
The bad actor the hardware manufacturer. Apparently the chip is not well-specified, and
hardware manufacturers just do their own thing, without documenting it, and write
proprietary drivers "which make it work" in Windoze and OSX.
7:16 a.m.
Ken Restivo wrote:
Hmmm ... manufacturer, name, etc?
--
David
gnome(a)hawaii.rr.com
authenticity, honesty, community
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, Aug 01, 2007 at 11:58:41AM -1000, gnome(a)hawaii.rr.com wrote:
That's not the way ALSA folk are acting. I periodically hear from them
asking if I could try updating ALSA and seeing if it works. Especially
since I now seem to be running a kernel they consider acceptable.
The reason you see the options for "caller
ID" and "off hook" is that
the Intel HDA chipset also includes a modem. My laptop uses Intel HDA,
and I'm used to the modem part showing up as if it were an audio device.
The audio works on my laptop except for an inability to record from the
mic input. Last I heard, ALSA was blaming the kernel, and kernel
developers were blaming ALSA. Although I haven't tried it since my most
recent kernel update.
The culprit is, as it often is, neither the kernel nor the ALSA.
The bad actor the hardware manufacturer. Apparently the chip is not well-specified, and
hardware manufacturers just do their own thing, without documenting it, and write
proprietary drivers "which make it work" in Windoze and OSX. $8 USB audio
dongle? Where did you find such a thing? Tell me more.
Ebay, about a year ago.
1 Aug
1 Aug
11:02 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, Aug 01, 2007 at 11:58:41AM -1000, gnome(a)hawaii.rr.com wrote:
The reason you see the options for "caller
ID" and "off hook" is that
the Intel HDA chipset also includes a modem. My laptop uses Intel HDA,
and I'm used to the modem part showing up as if it were an audio device.
The audio works on my laptop except for an inability to record from the
mic input. Last I heard, ALSA was blaming the kernel, and kernel
developers were blaming ALSA. Although I haven't tried it since my most
recent kernel update.
$8 USB audio dongle? Where did you find such a thing? Tell me more.
This says it all:
http://cgi.ebay.com/USB-Virtual-5-1-Channel-3D-Audio-Sound-Card-Adapter_W0Q…
- -ken
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFGsSzqe8HF+6xeOIcRAifdAKCJE26v+rc9+SBhPySNqf43Ss+m5wCeMuqP
SdiiVFFeBrtR5Jnxj3zPQdc=
=9Qig
-----END PGP SIGNATURE-----
2 Aug
2 Aug
7:19 a.m.
Ken Restivo wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, Aug 01, 2007 at 11:58:41AM -1000, gnome(a)hawaii.rr.com wrote:
Thanks, even though that one's closed. I'll look around for some more -
cool!
--
David
gnome(a)hawaii.rr.com
authenticity, honesty, community
The reason you see the options for "caller
ID" and "off hook" is that
the Intel HDA chipset also includes a modem. My laptop uses Intel HDA,
and I'm used to the modem part showing up as if it were an audio device.
The audio works on my laptop except for an inability to record from the
mic input. Last I heard, ALSA was blaming the kernel, and kernel
developers were blaming ALSA. Although I haven't tried it since my most
recent kernel update.
$8 USB audio dongle? Where did you find such a thing? Tell me more.
This says it all:
http://cgi.ebay.com/USB-Virtual-5-1-Channel-3D-Audio-Sound-Card-Adapter_W0Q…
12:34 p.m.
At Wed, 01 Aug 2007 11:58:41 -1000,
gnome(a)hawaii.rr.com wrote:
The reason you see the options for "caller ID" and "off hook" is that
the Intel HDA chipset also includes a modem. My laptop uses Intel HDA,
and I'm used to the modem part showing up as if it were an audio device.
The audio works on my laptop except for an inability to record from the
mic input. Last I heard, ALSA was blaming the kernel, and kernel
developers were blaming ALSA. Although I haven't tried it since my most
recent kernel update.
An interesting rumor. Where did you hear such a thing?
Takashi
4 Aug
4 Aug
2:08 a.m.
Takashi Iwai wrote:
At Wed, 01 Aug 2007 11:58:41 -1000,
gnome(a)hawaii.rr.com wrote:
IIRC, it's my slightly-dramatized rendering of what one of the ALSA
developers said when he responded to my bug report about not being able
to record from the mic input on my Intel chipset. He basically said that
the ALSA driver was not being notified *by the kernel* that the audio
input buffer was full and ready to be read. He advised me to try again
with a more recent kernel. Now the part about the kernel people blaming
it on ALSA developers may have come from this list.
But all that was a couple of years ago. I've not taken the time to try
recording via the laptop mic, because I'm planning to equip one of my
desk systems (with much more disk space and a real sound card!) to serve
that function.
--
David
gnome(a)hawaii.rr.com
authenticity, honesty, community
The reason you see the options for "caller
ID" and "off hook" is that
the Intel HDA chipset also includes a modem. My laptop uses Intel HDA,
and I'm used to the modem part showing up as if it were an audio device.
The audio works on my laptop except for an inability to record from the
mic input. Last I heard, ALSA was blaming the kernel, and kernel
developers were blaming ALSA. Although I haven't tried it since my most
recent kernel update.
An interesting rumor. Where did you hear such a thing?
6 Aug
6 Aug
3:14 p.m.
At Fri, 03 Aug 2007 18:08:11 -1000,
david wrote:
Takashi Iwai wrote:
Then, well, you made it really too dramatic. Requesting the update to
the latest kernel is a very standard procedure. Otherwise, the
developer cannot start real debugging at all.
The most important thing is to level the environment of both
development and testing. Thus this has nothing to with blaming
whomever. It's the stage even before blaming someone else.
Takashi
At Wed, 01 Aug 2007 11:58:41 -1000,
gnome(a)hawaii.rr.com wrote:
IIRC, it's my slightly-dramatized rendering of what one of the ALSA
developers said when he responded to my bug report about not being able
to record from the mic input on my Intel chipset. He basically said that
the ALSA driver was not being notified *by the kernel* that the audio
input buffer was full and ready to be read. He advised me to try again
with a more recent kernel. Now the part about the kernel people blaming
it on ALSA developers may have come from this list. The reason you see the options for "caller
ID" and "off hook" is that
the Intel HDA chipset also includes a modem. My laptop uses Intel HDA,
and I'm used to the modem part showing up as if it were an audio device.
The audio works on my laptop except for an inability to record from the
mic input. Last I heard, ALSA was blaming the kernel, and kernel
developers were blaming ALSA. Although I haven't tried it since my most
recent kernel update.
An interesting rumor. Where did you hear such a thing? 
5:51 p.m.
On Mon, Aug 06, 2007 at 07:13:12PM +0200, Takashi Iwai wrote:
Then, well, you made it really too dramatic.
Requesting the update to
the latest kernel is a very standard procedure. Otherwise, the
developer cannot start real debugging at all.
Not being a kernel/driver specialist at all, I do have some
difficulty in believing this.
The kernel has to call some routines in the driver, and provide
some services to it. I find it difficult to imagine
- how a kernel bug could affect just one driver and have no
impact on all the others.
- that if there's anything wrong with these interfaces a system
could work at all,
I assume most drivers are using the same interfaces to the
kernel, and the same services, and that these are relatively
stable.
But I could be completely wrong...
--
FA
Follie! Follie! Delirio vano è questo !
7:03 p.m.
Am Montag, 6. August 2007 schrieb Fons Adriaensen:
I assume most drivers are using the same interfaces to
the
kernel, and the same services, and that these are relatively
stable.
But I could be completely wrong...
Well, the kernel devs seem to change some interfaces rather often in binary
incompatible ways. And sometimes even on purpose (to drive away blob-drivers
like nvidia)...
So it can be that one of these changes introduced a bug hard to find and
affecting only very few drivers. And as the developers will probably all have
the lastest kernels, they don't want to wast time by debugging a problem
fixed two kernel versions ago just because the user has 2.6.4 installed and
doesn't use a half decent distro...
I can understand that policy.
Arnold
--
visit http://www.arnoldarts.de/
---
Hi, I am a .signature virus. Please copy me into your ~/.signature and send me
to all your contacts.
After a month or so log in as root and do a rm / -rf. Or ask your
administrator to do so...
7 Aug
7 Aug
7:10 a.m.
Arnold Krille wrote:
Am Montag, 6. August 2007 schrieb Fons Adriaensen:
Note: a decent distro (I've used several) doesn't necessarily have the
"latest" kernel - cuz the latest may still be in the very unstable realm.
I know I've switched to newer kernels in the past and had whole bunches
of devices quit working - for instance, had USB quit working completely.
On one, networking quit working entirely, too. So when some developer
tells me to "test again using the latest kernel," perhaps you understand
why I'm not exactly eager to go do that?
--
David
gnome(a)hawaii.rr.com
authenticity, honesty, community
I assume most drivers are using the same
interfaces to the
kernel, and the same services, and that these are relatively
stable.
But I could be completely wrong...
Well, the kernel devs seem to change some interfaces rather often in binary
incompatible ways. And sometimes even on purpose (to drive away blob-drivers
like nvidia)...
So it can be that one of these changes introduced a bug hard to find and
affecting only very few drivers. And as the developers will probably all have
the lastest kernels, they don't want to wast time by debugging a problem
fixed two kernel versions ago just because the user has 2.6.4 installed and
doesn't use a half decent distro...
11:08 a.m.
At Mon, 06 Aug 2007 23:10:00 -1000,
david wrote:
Arnold Krille wrote:
No more true. Distros nowadays try to pick up the latest one as much
as possible. Take a look at recent openSUSE, Ubuntu, etc.
Of course, it's adventurous to switch to early -rc kernel. But the
released kernel is supposed to be stable. This reduces the
maintenance a lot.
However, distros stick with the older kernel version for their
"business" products, mainly for keeping the 100% binary and source
compatibility, which many ISVs prefer.
IOW, it's just the matter of money :)
Am Montag, 6. August 2007 schrieb Fons
Adriaensen:
Note: a decent distro (I've used several) doesn't necessarily have the
"latest" kernel - cuz the latest may still be in the very unstable realm.
I assume most drivers are using the same
interfaces to the
kernel, and the same services, and that these are relatively
stable.
But I could be completely wrong...
Well, the kernel devs seem to change some interfaces rather often in binary
incompatible ways. And sometimes even on purpose (to drive away blob-drivers
like nvidia)...
So it can be that one of these changes introduced a bug hard to find and
affecting only very few drivers. And as the developers will probably all have
the lastest kernels, they don't want to wast time by debugging a problem
fixed two kernel versions ago just because the user has 2.6.4 installed and
doesn't use a half decent distro... I know I've switched to newer kernels in the past
and had whole bunches
of devices quit working - for instance, had USB quit working completely.
On one, networking quit working entirely, too. So when some developer
tells me to "test again using the latest kernel," perhaps you understand
why I'm not exactly eager to go do that?
Yeah, I can understand it, of course. I have a bunch of machines with
older kernels, too. But, you understand that if no report back from
the tester, the bug will be left simply broken? Testing is a part of
development cycle, and testing on the same environment is the
important factor, as I mentioned.
Takashi
8 Aug
8 Aug
4:32 a.m.
Takashi Iwai wrote:
It effects the developer's ability to duplicate the bug. I think it
behooves the developer to test on the environment the person reports the
bug on.
--
David
gnome(a)hawaii.rr.com
authenticity, honesty, community
At Mon, 06 Aug 2007 23:10:00 -1000,
david wrote:
Well, I don't run any business distros.
Arnold Krille wrote:
No more true. Distros nowadays try to pick up the latest one as much
as possible. Take a look at recent openSUSE, Ubuntu, etc.
Of course, it's adventurous to switch to early -rc kernel. But the
released kernel is supposed to be stable. This reduces the
maintenance a lot.
However, distros stick with the older kernel version for their
"business" products, mainly for keeping the 100% binary and source
compatibility, which many ISVs prefer.
IOW, it's just the matter of money :) Am Montag, 6. August 2007 schrieb Fons
Adriaensen:
Note: a decent distro (I've used
several) doesn't necessarily have the
"latest" kernel - cuz the latest may still be in the very unstable realm.
I assume most drivers are using the same
interfaces to the
kernel, and the same services, and that these are relatively
stable.
But I could be completely wrong...
Well, the kernel devs seem to change some
interfaces rather often in binary
incompatible ways. And sometimes even on purpose (to drive away blob-drivers
like nvidia)...
So it can be that one of these changes introduced a bug hard to find and
affecting only very few drivers. And as the developers will probably all have
the lastest kernels, they don't want to wast time by debugging a problem
fixed two kernel versions ago just because the user has 2.6.4 installed and
doesn't use a half decent distro... I know
I've switched to newer kernels in the past and had whole bunches
of devices quit working - for instance, had USB quit working completely.
On one, networking quit working entirely, too. So when some developer
tells me to "test again using the latest kernel," perhaps you understand
why I'm not exactly eager to go do that?
Yeah, I can understand it, of course. I have a bunch of machines with
older kernels, too. But, you understand that if no report back from
the tester, the bug will be left simply broken? Testing is a part of
development cycle, and testing on the same environment is the
important factor, as I mentioned.
7:55 a.m.
At Tue, 07 Aug 2007 20:31:55 -1000,
david wrote:
It effects the developer's ability to duplicate the bug.
You seem to forget the damn primary thing: the developers don't have
_your_ hardware. The bug, at least the one related with the kernel
driver, cannot be reproduced without the exact hardware.
Takashi Iwai wrote:
Then the situation gets better (unless you're using Debian stable :)
At Mon, 06 Aug 2007 23:10:00 -1000,
david wrote:
Well, I don't run any business distros. Arnold Krille wrote:
No more true. Distros nowadays try to pick up the latest one as much
as possible. Take a look at recent openSUSE, Ubuntu, etc.
Of course, it's adventurous to switch to early -rc kernel. But the
released kernel is supposed to be stable. This reduces the
maintenance a lot.
However, distros stick with the older kernel version for their
"business" products, mainly for keeping the 100% binary and source
compatibility, which many ISVs prefer.
IOW, it's just the matter of money :) Am Montag, 6. August 2007 schrieb Fons
Adriaensen:
> I assume most drivers are using the same interfaces to the
> kernel, and the same services, and that these are relatively
> stable.
> But I could be completely wrong...
Well, the kernel devs seem to change some interfaces rather often in binary
incompatible ways. And sometimes even on purpose (to drive away blob-drivers
like nvidia)...
So it can be that one of these changes introduced a bug hard to find and
affecting only very few drivers. And as the developers will probably all have
the lastest kernels, they don't want to wast time by debugging a problem
fixed two kernel versions ago just because the user has 2.6.4 installed and
doesn't use a half decent distro...
Note: a decent distro (I've used
several) doesn't necessarily have the
"latest" kernel - cuz the latest may still be in the very unstable realm.
I know I've switched to newer kernels in the past
and had whole bunches
of devices quit working - for instance, had USB quit working completely.
On one, networking quit working entirely, too. So when some developer
tells me to "test again using the latest kernel," perhaps you understand
why I'm not exactly eager to go do that?
Yeah, I can understand it, of course. I have a bunch of machines with
older kernels, too. But, you understand that if no report back from
the tester, the bug will be left simply broken? Testing is a part of
development cycle, and testing on the same environment is the
important factor, as I mentioned. I think it
behooves the developer to test on the environment the person reports the
bug on.
Could you explain more logically the reason, except for laziness?
Debugging consists of the following:
1. reproduce the bug
2. spot the bug
3. fix the bug
The developer cannot do 1 in many cases. So, what he could is only 2
and 3, as a guess work. Usually, the debugging seesion go through the
loop of 1 -> 2 -> 3 -> 1 -> 2 -> 3. Note, here, 1 is not done by the
developer but solely by you!
As the bug is often related with other components, you may have a good
chance to skip to 3 by updating to the newer version, even before
identifying the culprit. If the bug happens to be fixed, with luck,
then it beocmes much easier to spot the bug by bi-sect. So the step
goes from 3 to 2. Even if it's still not fixed, the update action
often narrows the area to focus on.
Now you resist testing the newer version and claims the developer to
downgrade the version instead. How can it help?
Takashi
7 Aug
7 Aug
10:45 a.m.
At Mon, 6 Aug 2007 21:58:29 +0200,
Fons Adriaensen wrote:
On Mon, Aug 06, 2007 at 07:13:12PM +0200, Takashi Iwai wrote:
A "kernel bug" is too generic wording. In most cases, it's a bug in
other components that a driver depends on. For example, the kernel
memory management, scheduler, ACPI, IRQ handler, etc. are involved
with the sound driver. If one of them is broken, the driver doesn't
work.
Then, well, you made it really too dramatic.
Requesting the update to
the latest kernel is a very standard procedure. Otherwise, the
developer cannot start real debugging at all.
Not being a kernel/driver specialist at all, I do have some
difficulty in believing this.
The kernel has to call some routines in the driver, and provide
some services to it. I find it difficult to imagine
- how a kernel bug could affect just one driver and have no
impact on all the others. - that if there's anything wrong with these
interfaces a system
could work at all,
The kernel-internal inteface has been _always_ changed from kernel
version to version.
I assume most drivers are using the same interfaces to
the
kernel, and the same services, and that these are relatively
stable.
That's not true at all :) It's one of the reasons you get thousands
of patches at each kernel version up.
Don't get me wrong: the kernel <-> user-space API is (mostly) stable
over all versions. But the kernel internal is different.
Takashi
11:23 a.m.
At Tue, 07 Aug 2007 14:45:12 +0200,
I wrote:
At Mon, 6 Aug 2007 21:58:29 +0200,
Fons Adriaensen wrote:
... well, to be a bit more specific, suppose the case of a wrong IRQ
assignment. ACPI has many built-in quirks as workaround of broken
BIOS. It might be your device. It might be fixed in the later
release.
The PCI core code change may influence. Possibly the default IRQ
routing is changed for your device, which you needed a special boot
option.
Or, the driver using MSI may behave utterly differently depending on
the kernel version because of the core MSI implementation.
It's more or less a same problem from the user-space, "wrong IRQ".
But, the cause can vary indeed.
Takashi
On Mon, Aug 06, 2007 at 07:13:12PM +0200, Takashi Iwai wrote:
A "kernel bug" is too generic wording. In most cases, it's a bug in
other components that a driver depends on. For example, the kernel
memory management, scheduler, ACPI, IRQ handler, etc. are involved
with the sound driver. If one of them is broken, the driver doesn't
work. Then, well, you made it really too dramatic.
Requesting the update to
the latest kernel is a very standard procedure. Otherwise, the
developer cannot start real debugging at all.
Not being a kernel/driver specialist at all, I do have some
difficulty in believing this.
The kernel has to call some routines in the driver, and provide
some services to it. I find it difficult to imagine
- how a kernel bug could affect just one driver and have no
impact on all the others.
2 Aug
2 Aug
1:21 p.m.
gnome(a)hawaii.rr.com wrote:
The reason you see the options for "caller
ID" and "off hook" is that
the Intel HDA chipset also includes a modem. My laptop uses Intel HDA,
and I'm used to the modem part showing up as if it were an audio device.
Yes,
looks like you are right. But do those options have any real-life
purpose?
The audio works on my laptop except for an inability
to record from the
mic input. Last I heard, ALSA was blaming the kernel, and kernel
developers were blaming ALSA. Although I haven't tried it since my most
recent kernel update.
How con the kernel be a problem since Alsa includes its own
kernel modules?
I guess the kernel does not restrict the modules in working with the
hardware the way they need to.
And one more question: does anybody have speaker mute feature working on
ANY hardware? I never had it working neither on my laptops nor my
desktops. Maybe it's a missing feature, not a bug?
Michael Baranov
2:59 p.m.
On Thu, Aug 02, 2007 at 06:08:36PM +0300, Michael Baranov wrote:
And one more question: does anybody have speaker mute
feature working on
ANY hardware? I never had it working neither on my laptops nor my
desktops. Maybe it's a missing feature, not a bug?
I can do it with alsamixer on a dell D810.
/proc/asound/cards idenfifies it as:
0 [ICH6 ]: ICH4 - Intel ICH6
Intel ICH6 with STAC9750,51 at irq 16
I use the snd_intel8x0 driver, and with alsamixer it Just Works: the
Master control mutes the speaker, the Headphone control mutes the
headphone jack.
--
Paul Winkler
http://www.slinkp.com
7:05 p.m.
Paul Winkler wrote:
I can do it with alsamixer on a dell D810.
/proc/asound/cards idenfifies it as:
0 [ICH6 ]: ICH4 - Intel ICH6
Intel ICH6 with STAC9750,51 at irq 16
I use the snd_intel8x0 driver, and with alsamixer it Just Works: the
Master control mutes the speaker, the Headphone control mutes the
headphone jack.
Are there any chances I'm using the wrong kernel module: snd_hda_intel
instead of some other?
However, my codec is ALC861-VD and snd_hda_intel claims to support it...
It's ICH7 however...
--
Michael Baranov
5:54 a.m.
New subject: FastTrack Pro (Was: mute laptop speakers with Intel HDA)
Ken Restivo wrote:>
I use an external sound device (M-Audio
FastTrack Pro USB) and it works beautifully.
I had purchased the FastTrack Pro - I REALLY liked it, but it would only
work in Linux with USB compliant mode - 16-bit, 44.1 kHz. Is that how
you are using it? To use any other samplerate or to use 24-bit samples
you need the MAudio drivers and special tool, which only work with
Windows and Mac.
(I looked into trying to sniff the USB port to figure out what's going
on, but USB protocols seem to be a whole lot more complex than I ever
imagined.)
I finally gave it to my Mac-loving brother and bought the Edirol UA-25
which has all such controls as switches and works great with Linux.
Is there any progress on having the device fully supported? How come
MAudio isn't any help here?
vic
6:10 a.m.
New subject: FastTrack Pro (Was: mute laptop speakers with Intel HDA)
I had purchased the FastTrack Pro - I REALLY liked it,
but it would only
work in Linux with USB compliant mode - 16-bit, 44.1 kHz. Is that how
you are using it? To use any other samplerate or to use 24-bit samples
you need the MAudio drivers and special tool, which only work with
Windows and Mac.
Well, if you want to use 96kHz you have to either disable the inputs or the
outputs, then it works (despite the fact that this is rather pointless).
6:39 a.m.
New subject: FastTrack Pro (Was: mute laptop speakers with Intel HDA)
Matthias Schönborn wrote:
Well, if you want to use 96kHz you have to either
disable the inputs or the
outputs, then it works (despite the fact that this is rather pointless).
That's because it's USB1 and not USB2 and the USB1 bandwidth won't
handle full duplex stereo 96kHz/24-bit audio. And it's not pointless if
you are only recording. But I can't even get into that mode with Linux.
(And I'm much more interested in 24-bit audio than I am in 96kHz, and
can't do that either.)
vic
4:14 p.m.
New subject: FastTrack Pro (Was: mute laptop speakers with Intel HDA)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thu, Aug 02, 2007 at 03:54:20PM +0800, Victor Roetman wrote:
Ken Restivo wrote:>
It only works in 44.1/16 mode under Linux. But that's fine for me.
UA-25's also tend to be pricey. If I can find one for under US$100 I'll get one
and sell the FastTrack.
I haven't thought of asking M-Audio to tell me what magick bits to flip on the
FastTrack Pro, because I'm expecting they won't.
- -ken
I use an external sound device (M-Audio
FastTrack Pro USB) and it works beautifully.
I had purchased the FastTrack Pro - I REALLY liked it, but it would only
work in Linux with USB compliant mode - 16-bit, 44.1 kHz. Is that how
you are using it? To use any other samplerate or to use 24-bit samples
you need the MAudio drivers and special tool, which only work with
Windows and Mac.
(I looked into trying to sniff the USB port to figure out what's going
on, but USB protocols seem to be a whole lot more complex than I ever
imagined.)
I finally gave it to my Mac-loving brother and bought the Edirol UA-25
which has all such controls as switches and works great with Linux.
Is there any progress on having the device fully supported? How come
MAudio isn't any help here?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFGsh6/e8HF+6xeOIcRAskOAKCQ03VP1XcM0lFrD3ozU9C5tgolrwCgzFfV
Zi6y4X94lXwqBB9ufDm/SYs=
=pynV
-----END PGP SIGNATURE-----
8:28 a.m.
Ken Restivo wrote:
Ask on ALSA list, but, last I checked, hda-intel == useless peice of shit.
I gave up after being told that there was no hope of hda-intel ever
working properly on linux. I use an external sound device (M-Audio
FastTrack Pro USB) and it works beautifully.
Even a cheap US$8 USB audio dongle worked well, and much better than
the hda-intel.
I've spent the whole yesterday evening to find this:
https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3179
Exactly my problem with my chip. What could I do? Just appended my info...
So you suggest picking up an USB dongle? Will I be able to use it instead of the main
audio card? (I mean will I be able to completely disable it in order no to interfere with
USB dongle)
Thanks.
8:26 p.m.
Hallo,
Michael Baranov hat gesagt: // Michael Baranov wrote: i
So you suggest picking up an USB dongle? Will I be
able to use it
instead of the main audio card? (I mean will I be able to completely
disable it in order no to interfere with USB dongle)
You can either disable the builtin card by not loading and
blacklisting the module for that card, or just enable both and select
which card you want to use by name and number, for example in jackd it
could be "jackd -d alsa -d hw:1" or so.
I generally do this on my laptop: When I don't have the USB card
connected, I use the internal card, otherwise I just start jackd on
the USB card.
Ciao
--
Frank Barknecht _ ______footils.org_ __goto10.org__
5:55 a.m.
Hi,
Am Mittwoch, 1. August 2007 schrieb Michael Baranov:
I've a very annoying problem with ALSA on my new
Toshiba P205: I can not
mute speakers when headphones are connected via a jack. There is an
option in alsamixer called 'headphone' that just enables the sound in
the jack, but does NOT mute the speakers.
Other 'strange' things:
1) option 'caller id'. No idea what it is.
2) option 'off-hook'. No idea what it is.
3) channel called 'speakers' does not control sound level or mute the
speakers!
I think you are looking at the mixer of the modem (win-modem aka another
sound-device). Try to make the real soundcard your default-device for sound
and also for the mixer...
And maybe blacklist the modem-module (i will do that now).
Arnold
--
visit http://www.arnoldarts.de/
---
Hi, I am a .signature virus. Please copy me into your ~/.signature and send me
to all your contacts.
After a month or so log in as root and do a rm / -rf. Or ask your
administrator to do so...
6359
days inactive
6366
days old
linux-audio-user@lists.linuxaudio.org
29 comments
12 participants
participants (12)
-
Arnold Krille -
david -
Fons Adriaensen -
Frank Barknecht -
gnome＠hawaii.rr.com
-
Ken Restivo -
Lee Revell -
Matthias Schönborn -
Michael Baranov -
Paul Winkler -
Takashi Iwai -
Victor Roetman