Re: [Alsa-devel] question about isapnp (for wavefront update)
On Thu, 17 Jan 2002, Paul Davis wrote: > jaroslav - > > for some time now, i've had a version of the wavefront driver that > doesn't require any module parameters - it just uses isapnp to figure > out the configuration of the card. i would have submitted the changes > to you already, except for one problem. after a reboot (cold or warm), > the first PnP "discovery" phase reports the card at an impossible IRQ > (one thats not supported by the h/w). the driver fails > "gracefully". if you try to insmod again, with no other actions, the > PnP "discovery" phase finds the card at a different IRQ, and > everything works just fine. > > Do you (or anyone else) have any ideas what might be going on here? > Any suggestions for diagnosing the issues? Can you try the attached patch for latest 2.4 and 2.5 kernels? Jaroslav - Jaroslav Kysela <[EMAIL PROTECTED]> SuSE Linuxhttp://www.suse.com ALSA Project http://www.alsa-project.org --- linux/drivers/pnp/isapnp.c.old Sun Jan 13 10:42:36 2002 +++ linux/drivers/pnp/isapnp.c Sun Jan 13 10:42:18 2002 @@ -892,6 +892,7 @@ case _STAG_END: if (size > 0) isapnp_skip_bytes(size); + isapnp_config_prepare(dev); return 1; default: printk(KERN_ERR "isapnp: unexpected or unknown tag type 0x%x for logical device %i (device %i), ignored\n", type, dev->devfn, card->number);
[Alsa-devel] Re: [Alsa-user] Re: 0.9.0-10 SBLive - Can't load driver
Adam,
I made all that and then a depmod -e. I get unresolved symbol errors.
[root@hori misc]# /sbin/depmod -e snd-card-emu10k1
# module id=string
# pci module vendor device subvendor subdevice class
class_mask driver_data
# isapnp module cardvendor carddevice driver_data vendor function
...
# usb module match_flags idVendor idProduct bcdDevice_lo bcdDevice_hi
bDeviceClass bDeviceSubClass bDeviceProtocol bInterfaceClass bInterfaceSubClass
bInterfaceProtocol driver_info
# module pattern
[root@hori misc]# /sbin/depmod -e snd-card-emu10k1.o
depmod: *** Unresolved symbols in snd-card-emu10k1.o
depmod: snd_emu10k1_pcm_Ra233f2bf
depmod: snd_card_free_R80bfcb46
depmod: snd_card_new_Rd33b9794
depmod: snd_seq_device_new_R2f62560d
depmod: snd_emu10k1_pcm_mic_Rbdd43bac
depmod: snd_emu10k1_fx8010_new_R2de06655
depmod: snd_emu10k1_pcm_efx_R634822a2
depmod: snd_card_register_R92c419d9
depmod: snd_emu10k1_fx8010_pcm_Rf1e3a736
depmod: snd_emu10k1_mixer_R2fed7bd1
depmod: snd_emu10k1_midi_Rb621d5f8
depmod: snd_emu10k1_create_R995a055b
snd-card-emu10k1.o:
# module id=string
snd-card-emu10k1.o info_classes={sound}
snd-card-emu10k1.o info_devices={{Creative Labs,SB Live!/PCI512/E-mu APS}}
snd-card-emu10k1.o info_parm_snd_index=enable:(snd_enable),allows:{{0,7}},unique,skill:required,dialog:list
snd-card-emu10k1.o info_parm_snd_id=enable:(snd_enable),unique
snd-card-emu10k1.o info_parm_snd_enable=allows:{{0,Disabled},{1,Enabled}},default:0,dialog:check
snd-card-emu10k1.o info_parm_snd_extin=enable:(snd_enable)allows:{{0,0x0}},base:16
snd-card-emu10k1.o info_parm_snd_extout=enable:(snd_enable)allows:{{0,0x0}},base:16
snd-card-emu10k1.o info_parm_snd_seq_ports=enable:(snd_enable)allows:{{0,32}}
snd-card-emu10k1.o info_parm_snd_max_synth_voices=enable:(snd_enable)
snd-card-emu10k1.o info_parm_snd_max_buffer_size=enable:(snd_enable)
snd-card-emu10k1.o info_parm_snd_enable_ir=allows:{{0,Disabled},{1,Enabled}},default:0,dialog:check
# pci module vendor device subvendor subdevice class
class_mask driver_data
snd-card-emu10k1.o 0x1102 0x0002 0x 0x 0x
0x 0x
# isapnp module cardvendor carddevice driver_data vendor function
...
# usb module match_flags idVendor idProduct bcdDevice_lo bcdDevice_hi
bDeviceClass bDeviceSubClass bDeviceProtocol bInterfaceClass bInterfaceSubClass
bInterfaceProtocol driver_info
# module pattern
What do you think the reason is? Do you think I should try to upgrade my
gcc compiler?
It's 2.96 currently.
Emre
Adam Jones wrote:
Is there anybody who managed to load ALSA drivers for Sound BlasterLive on Red Hat 7.2.
Not personally on RH7.2, no, but certainly with a whole range of 2.4.xkernels.First thing to try (apologies if you've done this):Check your kernel configuration, and make sure that you've got soundsupport enabled, but no cards configured. If that's not the case,rebuild and install your new kernel.rmmod all the ALSA modules if they're loaded.Do a "make distclean" in the alsa-driver directory.Do a "./configure" with appropriate options (I tend to use--with-oss=yes --with-sequencer=yes --with-isapnp=no--with-cards=emu10k1 )"make install"A "depmod -ae" should now tell you whether there are unresolved symbolsin any of the modules.Try modprobing things...I (and others) have had a bit of fun getting the SB Live! configuredcorrectly - if you can get the modules to load then I'll be happy tosupply a working /etc/asound.state from my machine.H
ope this helps...
[Alsa-devel] SOME ITEMS THAT YOU MAY BE INTERESTED IN OR BE ABLE TO ADVISE ME ON
These are the items that iam interested in selling.. Could you help me with some details on the goods, history, origin etc. are these worth anything and if so who would i contact with regards to selling them? and the best way to sell them ie auction etc APOLOGISE IF YOU HAVE ALREADY RECEIVED THIS E-MAIL JPEGS ARE AVAILABLE AT YOUR REQUEST MANY THANX kriss rolo tel: 0044 182760393 office (uk) 0044 1216864211 home (uk) 0044 7814294018 mobile (uk) return e-mail address [EMAIL PROTECTED] UK ONLY VEHICLE REGISTRATION NUMBER N64 CON NINTENDO 64 CONSOLE item 1 hand carved round table with metal chain link in the middle item 2 magnum laurent perrier vintage 1988 champagne item 3 miniture football on stand from euro96 signed by pele and bobby charlton item 4 is a bit more interesting. its a protana minifon attache, as u will see ive enclosed notes from a web site regarding this and you will see back in the 50's it cost $340.00 so i could imagine this to be worth a bit. it also has an original tape inside i do not know what is on this tape, but judging by who made it and the cost of the machine, the tape could have some important information on it. heres the note. The Minifon, developed in the early 1950s by Monske GMBH of Hanover(or by Protona GMBH- I'm not certain), was an ultra-miniaturized, battery operated magnetic recording device. It could not (initially at least) record the full range of sounds and was thus limited to voice recording, but it did offer easy portability in a very small package. The idea of offering a pocket dictating machine was novel, since dictation had previously been done in the office. However, it was thought that people like salesmen could take the machine "on the road" with them. Once on the market, the Minifon's promoters discovered that many people took advantage of the recorder's small size to make secret recordings to be used as evidence, as in court. The "legitimate" use of the Minifon, as a dictating machine, was somewhat problematical. Recordings made on regular dictating equipment were usually letters, and thus were normally sent almost immediately to a typist. The Minifon offered no obvious advantages over standard dictation equipment for office use, but its developers hoped to cultivate new uses for dictation equipment, such as stock taking in warehouses, or the use of the machine as a substitute for note-taking by reporters, insurance adjusters, salesmen, and others. In its original form, the Minifon was a wire recorder, using a type of wire medium developed by the Armour Research Foundation of Chicago and employed in many similar devices since the late 1940s. The machine at its introduction in 1952 had a recording time of one hour, which was remarkably long, and weighed only about 3 pounds at a time when a typical office dictating machine weighed upwards of 10 pounds. It accomplished this small size and light weight in part through the use of miniature tubes and clever mechanical design. The basic machine cost $289.50-- a price that sounds high today but was very much in line with competing office dictating machines. The parent company attempted to set up distribution, sales and service networks in the United States. It established a business office called the Minifon Export Corp in New York, and an existing company, Harvey Radio in New York City became the main distributor. Although smaller tape recorders appeared at about the same time, the main competition in the voice recording field was from an American company, Mohawk, which made a small, battery-operated cartridge tape recorder called the Migetape. Both products sold less than 10,000 units per year in the U.S. After a few years, the Minifon was modified to use transistors and magnetic tape, further lowering its weight and cost. By 1962 the basic machine weighed in at only 1.5 pounds. Competition by this time had helped bring the cost down to $249.50. The Minifon after about 1962 was distributed by the international conglomerate ITT through its subsidiary in the U.S., Federal Electric Corp. A little later, distribution was taken over by the ITT Distributor Products Division in Lodi, New Jersey. (I don't know whether these were the same company with different names) By the time ITT became associated with this product, it had taken on the name of Minifon "Attache," and a new line of models and options appeared. These included a hi-fi model, the 978H, which sold for $330.50.Usinga two-track, 1/4 inch tape cartridge operating at 1 7/8 inches per second, the machine claimed a frequency response of up to 12,000 Hz, plus or minus 3db. The coming of magnetic tape did not completely displace wire. The Model 240 series of recorders introduced in the early 1960s were probably the last wire recorders in regular production. The 240L, at a price of $269.50 used a special long-playing wire cartridge that held 4 hours of wire. Otherwise it looked like both the tape model and the 240S, which
[Alsa-devel] SOME ITEMS THAT YOU MAY BE INTERESTED IN OR BE ABLE TO ADVISE ME ON
These are the items that iam interested in selling.. Could you help me with some details on the goods, history, origin etc. are these worth anything and if so who would i contact with regards to selling them? and the best way to sell them ie auction etc APOLOGISE IF YOU HAVE ALREADY RECEIVED THIS E-MAIL JPEGS ARE AVAILABLE AT YOUR REQUEST MANY THANX kriss rolo tel: 0044 182760393 office (uk) 0044 1216864211 home (uk) 0044 7814294018 mobile (uk) return e-mail address [EMAIL PROTECTED] UK ONLY VEHICLE REGISTRATION NUMBER N64 CON NINTENDO 64 CONSOLE item 1 hand carved round table with metal chain link in the middle item 2 magnum laurent perrier vintage 1988 champagne item 3 miniture football on stand from euro96 signed by pele and bobby charlton item 4 is a bit more interesting. its a protana minifon attache, as u will see ive enclosed notes from a web site regarding this and you will see back in the 50's it cost $340.00 so i could imagine this to be worth a bit. it also has an original tape inside i do not know what is on this tape, but judging by who made it and the cost of the machine, the tape could have some important information on it. heres the note. The Minifon, developed in the early 1950s by Monske GMBH of Hanover(or by Protona GMBH- I'm not certain), was an ultra-miniaturized, battery operated magnetic recording device. It could not (initially at least) record the full range of sounds and was thus limited to voice recording, but it did offer easy portability in a very small package. The idea of offering a pocket dictating machine was novel, since dictation had previously been done in the office. However, it was thought that people like salesmen could take the machine "on the road" with them. Once on the market, the Minifon's promoters discovered that many people took advantage of the recorder's small size to make secret recordings to be used as evidence, as in court. The "legitimate" use of the Minifon, as a dictating machine, was somewhat problematical. Recordings made on regular dictating equipment were usually letters, and thus were normally sent almost immediately to a typist. The Minifon offered no obvious advantages over standard dictation equipment for office use, but its developers hoped to cultivate new uses for dictation equipment, such as stock taking in warehouses, or the use of the machine as a substitute for note-taking by reporters, insurance adjusters, salesmen, and others. In its original form, the Minifon was a wire recorder, using a type of wire medium developed by the Armour Research Foundation of Chicago and employed in many similar devices since the late 1940s. The machine at its introduction in 1952 had a recording time of one hour, which was remarkably long, and weighed only about 3 pounds at a time when a typical office dictating machine weighed upwards of 10 pounds. It accomplished this small size and light weight in part through the use of miniature tubes and clever mechanical design. The basic machine cost $289.50-- a price that sounds high today but was very much in line with competing office dictating machines. The parent company attempted to set up distribution, sales and service networks in the United States. It established a business office called the Minifon Export Corp in New York, and an existing company, Harvey Radio in New York City became the main distributor. Although smaller tape recorders appeared at about the same time, the main competition in the voice recording field was from an American company, Mohawk, which made a small, battery-operated cartridge tape recorder called the Migetape. Both products sold less than 10,000 units per year in the U.S. After a few years, the Minifon was modified to use transistors and magnetic tape, further lowering its weight and cost. By 1962 the basic machine weighed in at only 1.5 pounds. Competition by this time had helped bring the cost down to $249.50. The Minifon after about 1962 was distributed by the international conglomerate ITT through its subsidiary in the U.S., Federal Electric Corp. A little later, distribution was taken over by the ITT Distributor Products Division in Lodi, New Jersey. (I don't know whether these were the same company with different names) By the time ITT became associated with this product, it had taken on the name of Minifon "Attache," and a new line of models and options appeared. These included a hi-fi model, the 978H, which sold for $330.50.Usinga two-track, 1/4 inch tape cartridge operating at 1 7/8 inches per second, the machine claimed a frequency response of up to 12,000 Hz, plus or minus 3db. The coming of magnetic tape did not completely displace wire. The Model 240 series of recorders introduced in the early 1960s were probably the last wire recorders in regular production. The 240L, at a price of $269.50 used a special long-playing wire cartridge that held 4 hours of wire. Otherwise it looked like both the tape model and the 240S, which
Re: [Alsa-devel] Lexicon Core2
Just so people know (if people care), I wrote to Lexicon again, and they basically said that Core2 had been canned, but they weren't going to release the specs anyway. I said, "Huh, seems odd that they will neither write a driver that works nor let somebody else do it", and they said, "Yeah, return it and buy one of our newer products". Heh. Sigh. Ptbtbtd. What do they think they have to lose by releasing the specs? Like somebody else said, it's just silly. -Josiah On 16 Jan 2002, Allan Klinbail wrote: > Agreed > > I have an M-Audio(Midiman) Delta66, the drivers worked on first attempt, > no problems. TO compare this with the MOTU MTP AV (multiport midi > device) would concur with everything Paul has siad. The MTP-aV is > reverse engineered to my knowledge and some people seem to be able to > get the driver to work..others like myself... not. > > cheers > > Allan Klinbail > > > > On Wed, 2002-01-16 at 01:59, Paul Davis wrote: > > >On Tue, Jan 15, 2002 at 08:06:43 -0500, Wm. Josiah Erikson wrote: > > >> Shucks. I was afraid of that. I'll bug them some more, and if I get really > > >> ambitious (I know nothing about it), perhaps try and reverse engineer > > >> something. Is this technically possible? > > >> On another note, are there multitrack sound cards out there that DO have > > >> open source drivers? > > > > > >Some (most?) Midiman and RME cards have opensource drivers. I have the > > >RME 2i2o ADAT + spdif card and I'm very happy with it. > > ^ > > "hammerfall lite" > > > > there are also reports of various Hoontech multichannel cards working, > > and i think i've heard of some people even getting the terratech > > series, or some of them, operational - they use the same chipset as > > some explicitly supported h/w. > > > > --p > > > > ___ > > Alsa-devel mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/alsa-devel > > > > ___ > Alsa-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/alsa-devel > ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Re: [linux-audio-dev] alsa/usb
>>> But it does register itself to the OSS subsystem (to >>> drivers/sound/sound_core.c) like all other sound drivers, so it _is_ >>> part of OSS. >> no. sound_core is NOT part of OSS. ALSA attaches to it as well. Alan >> Cox wrote that so that OSS and ALSA could (theoretically) co-exist. > >Now I'm nitpicking, but actually only part of ALSA registering to >soundcore is the OSS-emulation layer. thats true. but it still means that sound_core.c is not part of OSS. its funny. looking over that code again, its amazing how much of a flashback it gives me to when i first started tinkering with audio on linux, and how utterly out-of-date and absurd it looks now. DSP16? bwahahaha! And wasn't soundcore written to >allow OSS/kernel and OSS/commercial coexists (OSS/commercial drivers >register to soundcore)...? alan explicitly wrote soundcore to support distinct, incompatible sound driver APIs. both OSS/Free and OSS/commercial use the same major device numbers the last time i looked, and so they cannot be used together. the source says: * Top level handler for the sound subsystem. Various devices can * plug into this. The fact they dont all go via OSS doesn't mean * they don't have to implement the OSS API. There is a lot of logic * to keeping much of the OSS weight out of the code in a compatibility * module, but its up to the driver to rember to load it... * * The code provides a set of functions for registration of devices * by type. This is done rather than providing a single call so that * we can hide any future changes in the internals (eg when we go to * 32bit dev_t) from the modules and their interface. * even so, its still totally out of date. --p ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Re: [linux-audio-dev] alsa/usb
On Thu, 17 Jan 2002, Paul Davis wrote: >> But it does register itself to the OSS subsystem (to >> drivers/sound/sound_core.c) like all other sound drivers, so it _is_ >> part of OSS. > no. sound_core is NOT part of OSS. ALSA attaches to it as well. Alan > Cox wrote that so that OSS and ALSA could (theoretically) co-exist. Now I'm nitpicking, but actually only part of ALSA registering to soundcore is the OSS-emulation layer. And wasn't soundcore written to allow OSS/kernel and OSS/commercial coexists (OSS/commercial drivers register to soundcore)...? -- http://www.eca.cx Audio software for Linux! ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Re: [linux-audio-dev] alsa/usb
>At least the driver handling the standard USB Audio Device Class is >located in the USB kernel directory, ie. linux/drivers/usb. All code is in >the big (~4000loc) audio.c file. It implements the OSS ioctls, plus >OSS-style mmap() (and of course read()/write()). > >But it does register itself to the OSS subsystem (to >drivers/sound/sound_core.c) like all other sound drivers, so it _is_ part >of OSS. no. sound_core is NOT part of OSS. ALSA attaches to it as well. Alan Cox wrote that so that OSS and ALSA could (theoretically) co-exist. that's clear then: these drivers are not part of OSS, but they do support OSS ioctl's so that enforce an OSS-style API. I wonder what device inodes they use? But basicly if ALSA provides (does it?) the soundcore services >(combined with ALSA's own OSS-emulation layer) you should be able to >continue to use the USB drivers. yes, i think you will be quite free to do so. they won't work with ALSA API software, but thats OK for now. --p ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Re: [linux-audio-dev] alsa/usb
On Thu, 17 Jan 2002, Kai Vehmanen wrote: [ ... w/ ALSA going to 2.5 kernel] >>> What's going to happen with usb audio/midi support ? > But it does register itself to the OSS subsystem (to > drivers/sound/sound_core.c) like all other sound drivers, so it _is_ part > of OSS. But basicly if ALSA provides (does it?) the soundcore services .. and yes it does, alsa-driver/alsa-kernel/sound_core.c. So based on this, I'd say USB audio will continue to work even after the ALSA merge. Don't take my word on it though, as I'm not a ALSA/OSS developer nor have I ever used USB-audio under Linux. :) -- http://www.eca.cx Audio software for Linux! ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Re: [linux-audio-dev] alsa/usb
On Thu, 17 Jan 2002, Paul Davis wrote: >> What's going to happen with usb audio/midi support ? >> Since alsa should become the kernel standard driver for audio/midi/seq >> devices and all the work the usb people have done to support the audio >> class is based on the oss-api does that mean with 2.5 or 2.6 I'll no > since the POSIX API is used, there's no way to route around this > (without LD_PRELOAD anyway). so my question is: are these drivers > actually part of OSS/Free (i.e. .../src/linux/drivers/char/sound), or At least the driver handling the standard USB Audio Device Class is located in the USB kernel directory, ie. linux/drivers/usb. All code is in the big (~4000loc) audio.c file. It implements the OSS ioctls, plus OSS-style mmap() (and of course read()/write()). But it does register itself to the OSS subsystem (to drivers/sound/sound_core.c) like all other sound drivers, so it _is_ part of OSS. But basicly if ALSA provides (does it?) the soundcore services (combined with ALSA's own OSS-emulation layer) you should be able to continue to use the USB drivers. Oh well, let's cc this to alsa-devel.. -- http://www.eca.cx Audio software for Linux! ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] question about isapnp (for wavefront update)
At Thu, 17 Jan 2002 09:23:26 -0500, Paul Davis wrote: > > jaroslav - > > for some time now, i've had a version of the wavefront driver that > doesn't require any module parameters - it just uses isapnp to figure > out the configuration of the card. i would have submitted the changes > to you already, except for one problem. after a reboot (cold or warm), > the first PnP "discovery" phase reports the card at an impossible IRQ > (one thats not supported by the h/w). the driver fails > "gracefully". if you try to insmod again, with no other actions, the > PnP "discovery" phase finds the card at a different IRQ, and > everything works just fine. > > Do you (or anyone else) have any ideas what might be going on here? > Any suggestions for diagnosing the issues? how about to compare /proc/isapnp before and after the first try? (of course isa-pnp module needs to be loaded before the alsa modules.) Takashi ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] question about isapnp (for wavefront update)
jaroslav - for some time now, i've had a version of the wavefront driver that doesn't require any module parameters - it just uses isapnp to figure out the configuration of the card. i would have submitted the changes to you already, except for one problem. after a reboot (cold or warm), the first PnP "discovery" phase reports the card at an impossible IRQ (one thats not supported by the h/w). the driver fails "gracefully". if you try to insmod again, with no other actions, the PnP "discovery" phase finds the card at a different IRQ, and everything works just fine. Do you (or anyone else) have any ideas what might be going on here? Any suggestions for diagnosing the issues? --p ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] SB Live rev 6 cards and AC3 SPDIF passthru finally works! Patch attached.
Hello! > Hello > I enclose a patch to alsa09, which fixes the problems I have been having > regarding no AC3 output from the SPDIF out. > I don't know if anyone remembers, but I have been having problems with > > my SB Live card and AC3 out for a long time. I could get AC3 passthru > working with the opensource.creative.com > emu10k1 driver, but it never > worked with the alsa09 driver. > > I had a free moment, so I tried hacking the alsa09 code a bit, to see > what was happening. > > This patch finally fixes it for me at last. :-) > > Can someone please add this to the alsa 09 CVS ? Just wanted to say, that it doesn't work for me unfortunately. Are there any other places which I could try to change. I have a rev 07 SB Live! Player. Of course it works for the oss drivers. Oh and another question: Does the snd_extout parameter in modules.conf matter at all? I also saw commented out define in emufx about AC3 passthrough. What does this do? Regards Markus ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Alsa 0.9.0beta10 doesn't compile with linux 2.5.2
On Wed, 16 Jan 2002, Helge Hafting wrote:
> I use alsa 0.9.0beta10 for sound. It used to work fine, but
> don't compile with linux kernel 2.5.2. This seems to
> be a problem with the kdev_t type that have changed lately.
>
> Is there a patch for this?
>
> Helge Hafting
Here is a patch to get 0.9.0beta10 working under 2.5.x. Enjoy it :)
(2HH : sorry, first I forgot to CC the list)
Bye
--
Tomas Kasparek (sioux, xkaspa06)
[EMAIL PROTECTED]
[EMAIL PROTECTED]
student UIVT FEI VUT Brno
diff -N -r -u alsa-driver-0.9.0beta10/Makefile alsa-driver-own/Makefile
--- alsa-driver-0.9.0beta10/MakefileMon Oct 1 09:26:48 2001
+++ alsa-driver-own/MakefileWed Jan 16 11:40:25 2002
@@ -30,8 +30,9 @@
all: compile
-sound:
+symlinks:
ln -sf include sound
+ cd include && ln -sf /usr/include/linux/major.h majors.h
include/sndversions.h:
make dep
@@ -44,7 +45,7 @@
cp utils/patches/byteswap.h /usr/include ; \
fi
-compile: /usr/include/byteswap.h sound include/sndversions.h include/isapnp.h
cards.config
+compile: /usr/include/byteswap.h symlinks include/sndversions.h include/isapnp.h
+cards.config
@for d in $(SUBDIRS); do if ! $(MAKE) -C $$d; then exit 1; fi; done
@echo
@echo "ALSA modules were successfully compiled."
@@ -109,14 +110,15 @@
rm -f doc/*~
mrproper: clean
+ $(MAKE) -C utils mrproper
+ $(MAKE) -C include mrproper
rm -f config.cache config.log config.status Makefile.conf
- rm -f utils/alsa-driver.spec
+ rm -f snddevices version cards.config sound
cvsclean: mrproper
- rm -f configure snddevices aclocal.m4 include/config.h include/isapnp.h
+ rm -f configure aclocal.m4 include/isapnp.h
pack: mrproper
- chmod 755 utils/alsasound
mv ../alsa-driver ../alsa-driver-$(CONFIG_SND_VERSION)
tar --exclude=CVS --owner=root --group=root -cvI -C .. -f
../alsa-driver-$(CONFIG_SND_VERSION).tar.bz2 alsa-driver-$(CONFIG_SND_VERSION)
mv ../alsa-driver-$(CONFIG_SND_VERSION) ../alsa-driver
diff -N -r -u alsa-driver-0.9.0beta10/configure.in alsa-driver-own/configure.in
--- alsa-driver-0.9.0beta10/configure.inWed Jan 16 11:22:45 2002
+++ alsa-driver-own/configure.inWed Jan 16 11:24:48 2002
@@ -634,7 +634,8 @@
AC_SUBST(GENKSYMS)
dnl Output files...
-AC_OUTPUT(version Makefile.conf snddevices utils/alsa-driver.spec utils/buildrpm
cards.config)
+AC_OUTPUT(version Makefile.conf snddevices utils/alsa-driver.spec utils/buildrpm
+cards.config utils/alsasound)
dnl Make right rights for scripts
chmod 755 $srcdir/snddevices
+chmod 755 $srcdir/utils/alsasound
diff -N -r -u alsa-driver-0.9.0beta10/include/Makefile
alsa-driver-own/include/Makefile
--- alsa-driver-0.9.0beta10/include/MakefileWed May 12 00:07:17 1999
+++ alsa-driver-own/include/MakefileWed Jan 16 11:40:38 2002
@@ -11,3 +11,5 @@
clean:
rm -f core .depend *.o *.orig *~ modules/*.ver
+mrproper:
+ rm -f config.h config1.h version.h majors.h
diff -N -r -u alsa-driver-0.9.0beta10/kernel/control.c
alsa-driver-own/kernel/control.c
--- alsa-driver-0.9.0beta10/kernel/control.cFri Oct 12 12:51:53 2001
+++ alsa-driver-own/kernel/control.cWed Jan 16 10:19:37 2002
@@ -36,7 +36,7 @@
static int snd_ctl_open(struct inode *inode, struct file *file)
{
- int cardnum = SNDRV_MINOR_CARD(MINOR(inode->i_rdev));
+ int cardnum = SNDRV_MINOR_CARD(minor(inode->i_rdev));
unsigned long flags;
snd_card_t *card;
snd_ctl_file_t *ctl;
diff -N -r -u alsa-driver-0.9.0beta10/kernel/hwdep.c alsa-driver-own/kernel/hwdep.c
--- alsa-driver-0.9.0beta10/kernel/hwdep.c Sat Oct 13 12:44:14 2001
+++ alsa-driver-own/kernel/hwdep.c Wed Jan 16 10:34:03 2002
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
@@ -69,7 +70,7 @@
static int snd_hwdep_open(struct inode *inode, struct file * file)
{
- int major = MAJOR(inode->i_rdev);
+ int major = major(inode->i_rdev);
int cardnum;
int device;
snd_hwdep_t *hw;
@@ -78,12 +79,12 @@
switch (major) {
case CONFIG_SND_MAJOR:
- cardnum = SNDRV_MINOR_CARD(MINOR(inode->i_rdev));
- device = SNDRV_MINOR_DEVICE(MINOR(inode->i_rdev)) - SNDRV_MINOR_HWDEP;
+ cardnum = SNDRV_MINOR_CARD(minor(inode->i_rdev));
+ device = SNDRV_MINOR_DEVICE(minor(inode->i_rdev)) - SNDRV_MINOR_HWDEP;
break;
#ifdef CONFIG_SND_OSSEMUL
case SOUND_MAJOR:
- cardnum = SNDRV_MINOR_OSS_CARD(MINOR(inode->i_rdev));
+ cardnum = SNDRV_MINOR_OSS_CARD(minor(inode->i_rdev));
device = 0;
break;
#endif
diff -N -r -u alsa-driver-0.9.0beta10/kernel/info.c alsa-driver-own/kernel/info.c
---
