Thank you for your thoughtful reply. > I do not think it is a good idea to add SND_PULSE as it can be easily > implemented by SND_TONE. It isn't that simple. Example: if a tone is playing for any reason the clicks do not interrupt the tone. (It would sound terrible, I've tried it). Clicks and tones are different in spirit and in implementation, almost orthogonal, and my code manages all this. > Also, what if you want clicks to go through sound card and not the speaker But you see, in my world, I precisely don't want that to happen, because sometimes the sound card isn't working. There are lots of reasons a sound card might not work, alsa and modules and pulseaudio are more finicky than you might think, not to mention the speech adapters that sit on top of them. If any link in this chain is broken, I get no speech, period. If I then don't get the clicks or tones either, I'm really lost at sea. Thus the modules that I write, and that other people write as well, specifically send small diagnostics through the pc speaker, because that just might be all the feedback we have. Here is a good example, grub, or maybe it's grub2, can't reasonably be expected to work through a sound card, so it can actually generate morse code at the pc speaker to help us load the desired OS. It's just a different philosophy that we have I guess. So instead of reinventing these routines over and over I thought it might be useful to have some of this common functionality in the pcspkr driver in the kernel. I mean it's already halfway there, this is just the other half. All managed just like tones are managed today. It's just the icing on the cake. Respectfully, Karl Dahlke -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
