Hi. Andreas Mohr wrote: > Immediately tried playback, and nothing worked properly. > Sound is __EXTREMELY__ silent, about 15 times more silent than the > normal terminal beep. Sorry for the silly question but... do you have the Master volume at maximum? > insmod with nforce_wa=1, no success either. nforce_wa is only needed if your speaker is completely silent otherwise. So you don't need it. > Debug output is (val has astonishingly uniform values): > input: PC Speaker as /class/input/input12 > PCSP: lpj=4012338, min_div=32, res=1 > PCSP: open called > PCSP: prepare called, size=32768 psize=2048 f=16 f1=16 > PCSP: trigger called > PCSP: start_playing called > timer_cnt 32 val 128 CUR_DIV 64 chip->treble 0 chip->max_treble 1 > timer_cnt 27 val 111 CUR_DIV 64 chip->treble 0 chip->max_treble 1 > timer_cnt 35 val 141 CUR_DIV 64 chip->treble 0 chip->max_treble 1 > timer_cnt 28 val 115 CUR_DIV 64 chip->treble 0 chip->max_treble 1 > timer_cnt 27 val 111 CUR_DIV 64 chip->treble 0 chip->max_treble 1 > timer_cnt 32 val 128 CUR_DIV 64 chip->treble 0 chip->max_treble 1 > timer_cnt 36 val 145 CUR_DIV 64 chip->treble 0 chip->max_treble 1 > timer_cnt 32 val 130 CUR_DIV 64 chip->treble 0 chip->max_treble 1 > timer_cnt 30 val 123 CUR_DIV 64 chip->treble 0 chip->max_treble 1 Only timer_cnt and val may change. Others are from the mixer controls. Well, whatever should change, seems changing. :) > BTW, since it has been frequently mentioned that sound device reordering is > an issue: > why not make that hard-coded in the driver itself?? I was thinking about that too - I don't know an answer. Added alsa-devel to CC because of that question. > If this is safe to do (setting it to a "max" value or to e.g. 10, > and all/most ALSA users still evaluate things properly), then one should > probably do it. Hopefully someone else can comment on that. > And mixer controls in gamix are very confusing, too. > E.g. when clicking on the BaseFRQ enum box, I get _two_ 18643 entries listed. I've seen this too, but I think this is a bug in that mixer gui. It doesn't seem to handle the ENUMERATED values right, IIRC. alsamixer works right. > And I'm still not sure (haven't investigated fully) > why that other setting is called "treble". Where? In the GUI or in the code? It shouldn't be called as such in the GUI, and for the code... well, I don't know, that was too long ago. :) > All in all very confusing. > All I'd want is enable playback, enable standard beep, master playback > volume and having the base frequency displayed(/changeable). Could you please see if there are any problems with alsamixer first? If not, then the problems are likely in the mixer you use. > Oh, and maybe oversampling configuration (how many samples to average, > for reduced timer load, see e.g. > http://kerneltrap.org/mailarchive/linux-activists/1993/4/13/29718 ). They seem to be talking about a simple downsampling to reduce the data transfer. I beleive they talk about downsampling in the player, not in the driver. You can't reduce the PWM freq. Making it below 18KHz would just whistle. > Oh, and why does the code order I/O sequence as > outb_p(chip->val61, 0x61); > outb_p(timer_cnt, 0x42); > outb(chip->val61 ^ 1, 0x61); > instead of > outb_p(chip->val61, 0x61); > outb(chip->val61 ^ 1, 0x61); > outb_p(timer_cnt, 0x42); > as mentioned at some other sites? Is there any reason or maybe it just > doesn't matter? I think it doesn't matter, and I did it that way to increase the delays between the port 0x61 writes. I have no proof that it helps or hurts. > Kconfig description should perhaps also be updated to prominently but > shortly display the fact that this driver provides full playback, > not just simple beeps (e.g. mention "digital sound driver" or so). It says something about a "primitive sound card", but I see no problems improving the text. > Thanks a lot for providing a rather important puzzle piece for > Linux usability! :) Ok, the problems should be solved, the texts should be improved, the users should upgrade, etc. And in a mean time, the warning I put there, is hopefully strong enough. :) If not, we can always depend that driver on CONFIG_BROKEN... but I'd like to hear more opinions about that option. Hmm, actually, why not? We can always un-depend it later. Thoughts? _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
