Hi all,
maybe this topic is a bit outdated, but still, when using the current hg code of the kernel module together with 2.6.24 (stable), I can't get any sound :( Do I have also to upgrade the ALSA libs and programs?
Marco
Hi Marco
maybe this topic is a bit outdated, but still, when using the current hg code of the kernel module together with 2.6.24 (stable), I can't get any sound :(
Interesting. I've had another user report getting sound out of the latest hg tree with an ALC268 both with test mode and the "auto" mode. Our continued failure to get anything out of your laptop over the last few months makes me suspect that there's some other non-standard thing (external to the ALC268 codec) linked to the sound system in your laptop which prevents audio unless activated. Takashi, what's your take on this?
Do I have also to upgrade the ALSA libs and programs?
This is strictly a driver-level issue; unless your libs are *really* ancient (and from memory they aren't) it shouldn't matter.
Just to confirm, when attempting to use aplay, aplay appears to be working but you get no sound - right?
Regards jonathan
At Fri, 1 Feb 2008 18:12:32 +1030 (CST), Jonathan Woithe wrote:
Hi Marco
maybe this topic is a bit outdated, but still, when using the current hg code of the kernel module together with 2.6.24 (stable), I can't get any sound :(
Interesting. I've had another user report getting sound out of the latest hg tree with an ALC268 both with test mode and the "auto" mode. Our continued failure to get anything out of your laptop over the last few months makes me suspect that there's some other non-standard thing (external to the ALC268 codec) linked to the sound system in your laptop which prevents audio unless activated. Takashi, what's your take on this?
Hard to say... I still think it's either GPIO or EAPD except for very stupid things like the hardware-volume control via laptop keys (e.g. Thinkpad has independent volume controls and you have to unmute it via a button properly). Marco, did you test all combinations of GPIO and EAPD?
On other earlier ALC codecs, some device require COEF setups. This might be worth to try for ALC268 if the above is all checked.
Takashi
Takashi Iwai schrieb:
At Fri, 1 Feb 2008 18:12:32 +1030 (CST), Jonathan Woithe wrote:
Hi Marco
maybe this topic is a bit outdated, but still, when using the current hg code of the kernel module together with 2.6.24 (stable), I can't get any sound :(
Interesting. I've had another user report getting sound out of the latest hg tree with an ALC268 both with test mode and the "auto" mode. Our continued failure to get anything out of your laptop over the last few months makes me suspect that there's some other non-standard thing (external to the ALC268 codec) linked to the sound system in your laptop which prevents audio unless activated. Takashi, what's your take on this?
Hard to say... I still think it's either GPIO or EAPD except for very stupid things like the hardware-volume control via laptop keys (e.g. Thinkpad has independent volume controls and you have to unmute it via a button properly). Marco, did you test all combinations of GPIO and EAPD?
Well, there are softkeys on the machine, but they don't have any effect (for example the LED for mute doesn't change when pressing the button). What's that stuff with GPIO/EAPD?
On other earlier ALC codecs, some device require COEF setups. This might be worth to try for ALC268 if the above is all checked.
Another thing I don't understand :(
Marco
PS: If you want, I can upload the Windoze drivers somewhere so that you can take a look at them and find out what is going on here...
Hi Marco
Interesting. I've had another user report getting sound out of the latest hg tree with an ALC268 both with test mode and the "auto" mode. Our continued failure to get anything out of your laptop over the last few months makes me suspect that there's some other non-standard thing (external to the ALC268 codec) linked to the sound system in your laptop which prevents audio unless activated. Takashi, what's your take on this?
Hard to say... I still think it's either GPIO or EAPD except for very stupid things like the hardware-volume control via laptop keys (e.g. Thinkpad has independent volume controls and you have to unmute it via a button properly). Marco, did you test all combinations of GPIO and EAPD?
Well, there are softkeys on the machine, but they don't have any effect (for example the LED for mute doesn't change when pressing the button). What's that stuff with GPIO/EAPD?
GPIO stands for "General Purpose IO". They are digital inputs/outputs provided by the audio codec chip which are not committed to any particular function within the chip. They can be used by a board manufacturer to control "extra" things they have added. For example, there are some Acer laptops around which use one of the GPIO lines from the codec to switch an external audio amplifier (ie: an amplifier not on the codec chip) on and off. Without that particular GPIO line turned on no audio is heard from the machine.
The EAPD line is a digital output provided by the codec chip. Again, a board vendor can choose what they like to do with this line but the convention is that if used it switches an amplifier/buffer.
Note that manufacturers don't *have* to use these lines, and indeed many vendors leave them completely unused.
The point here is if your machine is one which requires some combination of the GPIO and/or EAPD lines to be set before audio is emitted then this may explain the ongoing lack of sound. However, if I recall correctly you have already done extensive testing of all possible GPIO/EAPD setting combinations with all alsamixer controls set to maximum without success. Is my recollection correct here?
On other earlier ALC codecs, some device require COEF setups. This might be worth to try for ALC268 if the above is all checked.
Another thing I don't understand :(
COEF is, I believe, short for coefficients and refers to filter/DSP coefficients used by processors on the codec chip. It may be that your particular implementation of the ALC268 requires particular COEF settings in order to pass audio. Having said that I don't think this is the *general* case with the ALC268 because as I have mentioned a user has reported success with the ALC268 under Linux and a recent hg snapshot with both the "test" and "auto" models.
Regards jonathan
Jonathan Woithe schrieb:
Having said that I don't think this is the *general* case with the ALC268 because as I have mentioned a user has reported success with the ALC268 under Linux and a recent hg snapshot with both the "test" and "auto" models.
Strange. I have uploaded the driver to http://rapidshare.com/files/89478591/ALC268_Compal.rar (but I left out the Vista stuff). Do you think it's possible to find out _what_ makes the problem with this?
Thanks, Marco
Hi Marco
Having said that I don't think this is the *general* case with the ALC268 because as I have mentioned a user has reported success with the ALC268 under Linux and a recent hg snapshot with both the "test" and "auto" models.
Strange.
Not really. There's very strong evidence that the silicon may be different and this sort of thing occurs from time to time. While you may have an actual ALC-268 chip on your mainboard, someone else may have an ALC268 core integrated into some other chip vendor's jungle chip. The other issue is that different vendors choose to integrate the codec chips in different ways - different pin-to-jack mappings, use of GPIOs etc etc. With this sort of thing going on it's really no surprise to me that one ALC268-based system works while another does not.
I have uploaded the driver to http://rapidshare.com/files/89478591/ALC268_Compal.rar (but I left out the Vista stuff). Do you think it's possible to find out _what_ makes the problem with this?
I've had a quick look at the contents and nothing jumps out at me. Others with more experience with the windoze driver structure and knowledge of how various files are used may have more success.
My past experience has shown that in cases like this the best approach is to poke at the hardware until you find something that works. Admittedly that's becoming less feasible as time goes on and the hardware gets more complex and the fragility of hardware increases the likelihood of permanent damage.
Regards jonathan
Jonathan Woithe schrieb:
I have uploaded the driver to http://rapidshare.com/files/89478591/ALC268_Compal.rar (but I left out the Vista stuff). Do you think it's possible to find out _what_ makes the problem with this?
I've had a quick look at the contents and nothing jumps out at me. Others with more experience with the windoze driver structure and knowledge of how various files are used may have more success.
My past experience has shown that in cases like this the best approach is to poke at the hardware until you find something that works. Admittedly that's becoming less feasible as time goes on and the hardware gets more complex and the fragility of hardware increases the likelihood of permanent damage.
Do you think that
participants (3)
-
Jonathan Woithe -
Marco Schuster -
Takashi Iwai