Yet another sound/oss cleanup
PATCH 1/1 Yet another sound/oss cleanup
After I've removed the legacy defines of the old oss code, this is another step towards a clean sound code.
This patch is at this time only for one sound card (ad1816), but if gets accepted I'll patch all sound cards in this way.
It removes the need to put each soundcard in the ugly sound_drivers[] array in dev_table.h and now you don't have to compile the irq/io/dma values into the kernel image. Instead they can be specified on the kernel comandline using soundcard=<io>,<irq>,<dma>,<dma2>.
Christoph
Signature · 1 line
Always remember that you are unique. Just like everyone else.
drivers/sound/Config.in +0 -7
@@ -87,13 +87,6 @@ if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then dep_tristate ' AD1816(A) based cards (EXPERIMENTAL)' CONFIG_SOUND_AD1816 $CONFIG_SOUND - if [ "$CONFIG_SOUND_AD1816" = "y" ]; then - hex 'AD1816 audio I/O base 530, 604, E80 or F40' CONFIG_AD1816_BASE 530 - int 'AD1816 audio IRQ 5, 7, 9, 11, 12 or 15' CONFIG_AD1816_IRQ 7 - int 'AD1816 audio DMA 0, 1 or 3' CONFIG_AD1816_DMA 0 - int 'AD1816 second (duplex) DMA 0, 1 or 3' CONFIG_AD1816_DMA2 3 - int 'AD1816 clock chip frequency' CONFIG_AD1816_CLOCK 33000 - fi fi dep_tristate ' Aztech Sound Galaxy (non-PnP) cards' CONFIG_SOUND_SGALAXY $CONFIG_SOUND_OSS
drivers/sound/ad1816.c +32 -67
148 lines not on this page · raw message
drivers/sound/dev_table.c +27 -1
@@ -15,13 +15,13 @@#include <linux/config.h> #include <linux/init.h> -#define _DEV_TABLE_C_#include "sound_config.h" int softoss_dev =0 ;int sound_started =0 ;int sndtable_get_cardcount (void ); +struct address_info cfg;int snd_find_driver (int type) {
@@ -71,6 +71,10 @@ sound_preinit_lowlevel_drivers(); }#endif +#ifdef CONFIG_SOUND_AD1816 +if (probe_ad1816 (&cfg)) +attach_ad1816 (&cfg); +#endif /* * Check the number of cards actually defined in the table
@@ -620,3 +624,25 @@ sound_timer_devs[dev] =NULL ; } +#ifndef MODULE +void soundcard_setup (char *str) +{ +/* io, irq, dma, dma2 */ +int ints[5 ]; + str =get_options (str,ARRAY_SIZE (ints), ints); + + cfg.io_base = ints[1 ]; + cfg.irq = ints[2 ]; + cfg.dma = ints[3 ]; + cfg.dma2 = ints[4 ]; + +printk ("soundcard: io=%x, irq=%d, dma=%d, dma2=%d\n" , + + cfg.io_base, + cfg.irq, + cfg.dma, + cfg.dma2); +} + +__setup ("soundcard=" , soundcard_setup); +#endif
drivers/sound/dev_table.h +0 -5
@@ -418,11 +418,6 @@ {"SGALAXY", 0, SNDCARD_SGALAXY, "Sound Galaxy WSS", attach_sgalaxy, probe_sgalaxy, unload_sgalaxy}, #endif -#ifdef CONFIG_SOUND_AD1816 - {"AD1816", 0, SNDCARD_AD1816, "AD1816", attach_ad1816, -probe_ad1816, unload_ad1816}, -#endif - #ifdef CONFIG_SOUND_YM3812 {"OPL3", 0, SNDCARD_ADLIB, "OPL-2/OPL-3 FM", attach_adlib_card, probe_adlib, unload_adlib}, #endif
drivers/sound/soundcard.c +0 -4
@@ -484,10 +484,8 @@ } in_use++; -#ifdef CONFIG_MODULES notifier_call_chain (&sound_locker,1 ,0 ); lock_depth++; -#endif return 0 ; }
@@ -522,10 +520,8 @@ } in_use--; -#ifdef CONFIG_MODULES notifier_call_chain (&sound_locker,0 ,0 ); lock_depth--; -#endif return 0 ; }
drivers/sound/soundmodule.h +1 -3
@@ -2,12 +2,11 @@#define _SOUNDMODULE_H#include <linux/notifier.h> +#include <linux/module.h> extern struct notifier_block *sound_locker;extern void sound_notifier_chain_register (struct notifier_block *); -#ifdef MODULE -#define SOUND_LOCK sound_notifier_chain_register(&sound_notifier);#define SOUND_LOCK_END notifier_chain_unregister(&sound_locker, &sound_notifier)
@@ -27,5 +26,4 @@0 }; -#endif #endif
This sounds (no pun ...) great and as you mention "<dma>,<dma2>" it triggered the following question.
By accident I bought a motherboard with a SB Vibra16 on it and that can't be diabled, thinking it was a straightforward SB16 as I have on another machine. It isn't because it doesn't have a 16bit DMA channel, but only two 8bit DMA channels.
Because of that the driver won't take more than one DMA channel (one of the 8bit) and the sound system is now not duplex-able. That seems obvious as the SB driver is always loaded with "dma=N dma16=M" (N=[0,1,2,3], M=[4,5,6,7]).
However, you write it as dma and dma2 with the ad1816 driver so I was wondering if there is anything that hinders an otherwise (it seems) SB16 lookalike to to have the second DMA channel load also as 8bit? Do ad1816 cards have one 8bit and one 16bit as SB16 has it or some other configuration?
I can play .wav and .mp3 files with the SB Vibra16 using the SB driver, so something must be working right. I would also like to use it in duplex mode for IP-phone on my network and would like to know what it takes?
I understand the difference with 8 and 16bit, but don't know what difference it makes on a soundcard, so if anyone could tell me or tell me what article or manual to read I would aprpeciate it. Playing the .wav and .mp3 files doesn't sound any different on this SB Vibra16 than on a SB16, which is why I am wondering what is going on?
Thanks,
Peter
Quoted 7 lines · Christoph Hellwig
After I've removed the legacy defines of the old oss code, this is another step towards a clean sound code.
This patch is at this time only for one sound card (ad1816), but if gets accepted I'll patch all sound cards in this way.
Quoted 9 lines
It removes the need to put each soundcard in the ugly sound_drivers[] array in
dev_table.hand now you don't have to compile the irq/io/dma values into the kernel image. Instead they can be specified on the kernel comandline using soundcard=<io>,<irq>,<dma>,<dma2>.Christoph
--
Always remember that you are unique. Just like everyone else.
I like that .sig :-)