Date: Wed, 25 Jan 95 00:52 EET From: "Jens Puchert" Subject: [INERTIA-TALK:1154] Re: [INERTIA- In message <9501231719.0OBXL00@t8000.cuc.ab.ca> you write: [Jensi wrote:] >> > The DSP is pretty useless for playing MOD's. For all I know it only >> > helps with h/w (de-)compression and text to speech synthesis and some >> > surround effects. It's the EMU chip that's interesting for module >> > playback as you can upload the samples to onboard RAM and then let the >> > synth chip do the processing and mixing, much like the GUS's GF1 does. > >Can someone explain why soundcards must contain RAM to do this type of .MODule >mixing? What I'm getting at is, it would be nice to have a card that does'nt >require on-card RAM to be able to do non-CPU-intensive sample mixing. Could'nt >this be accomplished by using motherboard RAM and DMA? If you want the sound-coprocessor on your sound card to do the mixing (which is the whole point here because it's so CPU intensive) the co-processor needs full (CPU-independent) access to the samples. The easiest way to do this is by providing the sound-copro with it's own independent RAM which it has the sole access to. Then the sound-copro can do whatever it wants asynchronously from the CPU. Theoretically you could do the same thing with shared RAM on the main board and fast DMA transfers, but this method is not nearly as elegant. For one thing, DMA still requires some CPU intervention, so the sound-copro can't proceed fully asynchronously, but the real problem is that in the worst possible case you would have to transfer 32 channels at 48 kHz real-time, that means 32 * 48000 * 16 * 2 = 49 Mbps = 6.1 MBps, something an ISA bus is simply not capable of, not to mention that it would kill the rest of your system's I/O. With a PCI system it would be theoretically possible, but it still hogs down the bus for no good reason. Independent RAM on the card is just a much better solution. >(side note: I'm sure if this could be done, we would'nt have videocards with >onboard RAM... now would we?) Yeah, basically the same story here, not enough speed and too much CPU intervention if the video RAM was located on the main board. Actually, the problem with video is even more complex since advanced accelerated video processors do a lot of calculations in hardware and need the RAM also for write cycles. The rate at which video data are pumped out of the video card to the monitor approaches that of todays VRAM's capabilities (45 ns access), so go figure, no bus system known to man could even nearly handle that. >I want to know the reasons why this can't be done! (BTW, I've got 16MB 60ns RA >M >on my MB, so you can see why I'm biased! ;-)) Yes, but it's one of the goals in computer architecture design to create as many independent fully functional sub-systems with a unified standard interface as possible. This way your sub-system's h/w can be replaced without worrying about interferring with something else in the system. It's a main pre-requisite for modular, upgradable, interchangable, yet still competitive h/w. >Darryl T. >darryl.teichroeb@t8000.cuc.ab.ca Jensi ----------------- Date: Wed, 25 Jan 95 05:06 EET From: Cory Koski Subject: [INERTIA-TALK:1155] Re: [INERTIA- > >> > The DSP is pretty useless for playing MOD's. For all I know it only > >> > helps with h/w (de-)compression and text to speech synthesis and some > >> > surround effects. It's the EMU chip that's interesting for module > >> > playback as you can upload the samples to onboard RAM and then let the > >> > synth chip do the processing and mixing, much like the GUS's GF1 does. > If you want the sound-coprocessor on your sound card to do the mixing (which > is the whole point here because it's so CPU intensive) the co-processor needs > full (CPU-independent) access to the samples. The easiest way to do this is > by providing the sound-copro with it's own independent RAM which it has the > sole access to. Then the sound-copro can do whatever it wants asynchronously > from the CPU. Theoretically you could do the same thing with shared RAM on > the main board and fast DMA transfers, but this method is not nearly as > elegant. For one thing, DMA still requires some CPU intervention, so the > sound-copro can't proceed fully asynchronously, but the real problem is that > in the worst possible case you would have to transfer 32 channels at 48 kHz > real-time, that means 32 * 48000 * 16 * 2 = 49 Mbps = 6.1 MBps, something an > ISA bus is simply not capable of, not to mention that it would kill the rest > of your system's I/O. With a PCI system it would be theoretically possible, > but it still hogs down the bus for no good reason. Independent RAM on the > card is just a much better solution. Well, I must say that that is a very good answer. I am completely satisfied with that response. I always wondered why the DSP on a SB-16ASP couldn't be used efficiently to do the sample mixing for a MOD. But since the DSP _can_ be used to add real-time effects, why couldn't it do the "oversampling" that IPLAY does, on board? I know that the "oversampling" or noise filtering system takes up CPU time, but couldn't it be tossed off to the DSP, and from the DSP to the sound out jack? Then, for a different effect, like surround, or QSound, just upload another algorithm to the DSP... Is this at all possible? I guess this all boils down to one question... does the DSP on a SB16, for example, take in sample data, process it, dump it back to the MB, and then spew it to the SB16 DAC channel? Or can the DSP on the SB16 process the sound data, and spew it to the DAC channel directly? Cory ----------------- Date: Wed, 25 Jan 95 05:22 EET From: Cuthalion / Sliced Bread Subject: [INERTIA-TALK:1156] Re: [INERTIA- On Tue, 24 Jan 1995 darryl.teichroeb@t8000.cuc.ab.ca wrote: > > > > > The DSP is pretty useless for playing MOD's. For all I know it only > > > helps with h/w (de-)compression and text to speech synthesis and some > > > surround effects. It's the EMU chip that's interesting for module > > > playback as you can upload the samples to onboard RAM and then let the > > > synth chip do the processing and mixing, much like the GUS's GF1 does. > > Can someone explain why soundcards must contain RAM to do this type of .MODule > mixing? What I'm getting at is, it would be nice to have a card that does'nt > require on-card RAM to be able to do non-CPU-intensive sample mixing. Could'nt > this be accomplished by using motherboard RAM and DMA? > > (side note: I'm sure if this could be done, we would'nt have videocards with > onboard RAM... now would we?) > > I want to know the reasons why this can't be done! (BTW, I've got 16MB 60ns RAM > on my MB, so you can see why I'm biased! ;-)) > Well, among other things, it would play hell with the bus. Think about a video card that uses system RAM. Ok. Every refresh, it needs to read in a WHOLE SCREEN FULL of memory. That's 60-70 times a second, the bus needs to send 64K. (More in SVGA modes/undocumented VGA modes). That's a lot of bus bandwidth. Now, throw in 14 channel 16 bit 44.1 kHz sound, and that brings your total up to... close to five megs a second to be moved around your computer, in low resolution graphics modes. In hi res modes, it would be CONSIDERABLY higher. (For instance, in 640x480x4bpp, it would take on the order of 10 meg/second, plus whatever sound you're running._) ----------------- Date: Wed, 25 Jan 95 06:56 EET From: Schitzo Subject: [INERTIA-TALK:1157] IPLAY V1.21!!! hey new version's out!!! with added features & bug fixes and there's talk about version 1.30 coming out soon!!! :) i just got it off a local bbs and i'll ul'd it to archive.epas.toronto.edu tomorrow! any other sites i should ul'd it to? ----------------- Date: Wed, 25 Jan 95 08:59 EET From: "Jens Puchert" Subject: [INERTIA-TALK:1158] Re: [INERTIA- In message you write: >> If you want the sound-coprocessor on your sound card to do the mixing (which > >> is the whole point here because it's so CPU intensive) the co-processor needs >> full (CPU-independent) access to the samples. The easiest way to do this is >> by providing the sound-copro with it's own independent RAM which it has the >> sole access to. Then the sound-copro can do whatever it wants asynchronously >> from the CPU. Theoretically you could do the same thing with shared RAM on >> the main board and fast DMA transfers, but this method is not nearly as >> elegant. For one thing, DMA still requires some CPU intervention, so the >> sound-copro can't proceed fully asynchronously, but the real problem is that >> in the worst possible case you would have to transfer 32 channels at 48 kHz >> real-time, that means 32 * 48000 * 16 * 2 = 49 Mbps = 6.1 MBps, something an >> ISA bus is simply not capable of, not to mention that it would kill the rest >> of your system's I/O. With a PCI system it would be theoretically possible, >> but it still hogs down the bus for no good reason. Independent RAM on the >> card is just a much better solution. > >Well, I must say that that is a very good answer. I am completely >satisfied with that response. I always wondered why the DSP on a SB-16ASP >couldn't be used efficiently to do the sample mixing for a MOD. But since >the DSP _can_ be used to add real-time effects, why couldn't it do the >"oversampling" that IPLAY does, on board? Because unlike reverb and other global effects, oversampling must be applied to every channel seperately before mixing. Since the SB's DSP only sees the final output stream it's too late to apply oversampling algorithms. >I know that the "oversampling" >or noise filtering system takes up CPU time, but couldn't it be tossed off >to the DSP, and from the DSP to the sound out jack? See above. Interpolated oversampling must be applied before mixing, therefore it can't be done on a card that doesn't support h/w mixing. >Then, for a different >effect, like surround, or QSound, just upload another algorithm to the >DSP... Is this at all possible? Surround and QSound can be added by the SB's DSP, because those are global effects, applied to the mixed data stream. >I guess this all boils down to one question... does the DSP on a SB16, >for example, take in sample data, process it, dump it back to the MB, and >then spew it to the SB16 DAC channel? Or can the DSP on the SB16 process the >sound data, and spew it to the DAC channel directly? I'm not an expert on SB h/w, but for all I know the DSP is hardwired into the data path right before the DAC. I don't think you can reroute the DSP's output back to the motherboard to get a hold of it. In any case, it's not possible to use the DSP for oversampling. >Cory Jensi ----------------- Date: Wed, 25 Jan 95 09:24 EET From: sdanes@marvels.hacktic.nl (Stefan Danes) Subject: [INERTIA-TALK:1159] Re: IPLAY V1.21!!! Schitzo writes: > hey new version's out!!! with added features & bug fixes and >there's talk about version 1.30 coming out soon!!! :) > > i just got it off a local bbs and i'll ul'd it to >archive.epas.toronto.edu tomorrow! any other sites i should ul'd it to? Carefully: They copied it from the Assembly '94 CDROM and if ISETUP isn't exactly 8200 bytes it is infected by the TAIPAN virus!!! Only FPROT v2.16 and above will detect it: no other virus scanner will see the virus... I'm currently catching up with my mail [Two weeks ago I had 2000+ unread/unanswered emails, now it's only 500] since I didn't have much time last months. Just for the record: IPLAY v1.21 was not meant to be distributed... It was a special version for the Assembly '94 CD only... We're currently working on version 1.3 which will have many fixes, changes and new stuff... Don't know when it will be available though [When it is finished I guess... :-] Later!, Stefan +----------------------------------------------------------------------------+ | Stefan Danes a.k.a. Prime/Inertia E-Mail : sdanes@marvels.hacktic.nl | | Inertia Player version 1.2 : Do your soundcard a favour and GET IT NOW! | | Send email to listserver@oliver.sun.ac.za to subscribe to one or both of | | the Inertia Mailinglists and write following text in your message: | | To connect to Binary Inertia releases: subscribe inertia-list YourRealName | | To connect to Discussion Mailing list: subscribe inertia-talk YourRealName | +----------------------------------------------------------------------------+ ----------------- Date: Wed, 25 Jan 95 10:41 EET From: Paul Bijlsma Subject: [INERTIA-TALK:1160] Re: IPLAY V1.21!!! Just a question, if you ul'd it to a site, how can I get it??? P.B On Wed, 25 Jan 95 06:56 EET Schitzo wrote: > From: Schitzo > Date: Wed, 25 Jan 95 06:56 EET > Subject: [INERTIA-TALK:1157] IPLAY V1.21!!! > To: Multiple recipients of list > > hey new version's out!!! with added features & bug fixes and > there's talk about version 1.30 coming out soon!!! :) > > i just got it off a local bbs and i'll ul'd it to > archive.epas.toronto.edu tomorrow! any other sites i should ul'd it to? ----------------- Date: Wed, 25 Jan 95 14:02 EET From: b.xu@ic.ac.uk Subject: [INERTIA-TALK:1161] Re:GMIDI output Can anyone explain what is the Gmidi output option in Inertia 1.2 for ? and how to use it ? ----------------- Date: Wed, 25 Jan 95 15:32 EET From: JOHN COCHRAN/COMPUTER DEMI-GOD Subject: [INERTIA-TALK:1162] Re: IPLAY V1.21!!! >Just for the record: IPLAY v1.21 was not meant to be distributed... It was >a special version for the Assembly '94 CD only... We're currently working >on version 1.3 which will have many fixes, changes and new stuff... Don't >know when it will be available though [When it is finished I guess... :-] >Later!, Stefan Is that why I havent seen any demos from Assembly '94?? Were they only released on this CD? I would really like to know where to get this CD. Any help is appreciated. Thanks John ----------------- Date: Wed, 25 Jan 95 15:33 EET From: Lewis A J Subject: [INERTIA-TALK:1163] SB and GUS... Rubbish... What's all this about GUS being wonderfull.... Good, but I think you're missing somthing.... The AWE32 can do EXACTLY what the gus does for mods... and it is hardware SB compatable, its because it's so well SB16 compatable that there are not many/any native players.... If you want to do it properly with the AWE then surely you can upload the MOD samples to the AWE as MIDI patches and play the mod via the MIDI synth.... this sounds odd until you realise that that's almost exactly what the GUS does... alsoo it would give you the chance to mix up to 64 channels and 32note polyphony, if the blurb I saw was correct... also effects could be done on the EMU 8000..... I have an AWE32 and am interested in mods but I've not yet run out of CPU time or any of that tut, so I'm happy for the moment (I can play 29 channel MTM from Iplay with x256 on and in the FFT set to fast... and shell to DOS and use ARJ to compress 11megs to multi volume archive on floppy with none of this ST-t-t-tutter that I keep hearing about..... Just what DOES that sound like ? ;-) Also, if anyone has any examples of DMA coding in assembler for recording and/or playing samples from memory then PLEASE send them to me!!! Cheers de James (lewiar@sx.ac.uk | g7kwo@gb7cos.#34.gbr.eu) ----------------- Date: Wed, 25 Jan 95 21:10 EET From: "Cyber Edge / Syber Dreams" Subject: [INERTIA-TALK:1165] Re: IPLAY V1.21!!! > >Just for the record: IPLAY v1.21 was not meant to be distributed... It was > >a special version for the Assembly '94 CD only... We're currently working > >on version 1.3 which will have many fixes, changes and new stuff... Don't > >know when it will be available though [When it is finished I guess... :-] > > >Later!, Stefan > > > Is that why I havent seen any demos from Assembly '94?? Were they only > released on this CD? I would really like to know where to get this > CD. Any help is appreciated. > Well, if you ftp to ftp.eng.ufl.edu you'll be able to get almost all the entries from ASM '94. Thats the 4k intros, the 64k intros, the demos, the music, and the graphics. There's a list of the winners and runners up, with the names of the song/demo/intro/graphic in the /demos/compos/ASM94/ directory I believe. I don't know exactly, I haven't been through there in a week or so. -- ..Paul..Kalupnieks.. ..kalupnie@fs2.ucc.on.ca.. .Cyber.Edge....Syber.Dreams. .........-1995-........... ----------------- Date: Wed, 25 Jan 95 21:04 EET From: "Cyber Edge / Syber Dreams" Subject: [INERTIA-TALK:1164] Re: IPLAY V1.21!!! > hey new version's out!!! with added features & bug fixes and > there's talk about version 1.30 coming out soon!!! :) > > i just got it off a local bbs and i'll ul'd it to > archive.epas.toronto.edu tomorrow! any other sites i should ul'd it to? I thought there was a list that one could subscribe to, to get the newest releases. But I haven't gotten any yet. Hmm. why is that? -- ..Paul..Kalupnieks.. ..kalupnie@fs2.ucc.on.ca.. .Cyber.Edge....Syber.Dreams. .........-1995-........... ----------------- Date: Wed, 25 Jan 95 23:00 EET From: Schitzo Subject: [INERTIA-TALK:1169] Re: IPLAY V1.21!!! On Wed, 25 Jan 1995, Stefan Danes wrote: > Schitzo writes: > > > hey new version's out!!! with added features & bug fixes and > >there's talk about version 1.30 coming out soon!!! :) > > > > i just got it off a local bbs and i'll ul'd it to > >archive.epas.toronto.edu tomorrow! any other sites i should ul'd it to? > Carefully: They copied it from the Assembly '94 CDROM and if ISETUP isn't > exactly 8200 bytes it is infected by the TAIPAN virus!!! Only FPROT v2.16 > and above will detect it: no other virus scanner will see the virus... > oh oh .. the isetup isn't 8200 so i guess i won't be ul'ing the copy i got. what does this virus do anyway? can i use isetup and then nuke it and then use the virus scan to clean whatever and then i will be safe? if not why not release 1.21 yourself? guess i better go look for that fprot v2.16 *sigh* > I'm currently catching up with my mail [Two weeks ago I had 2000+ > unread/unanswered emails, now it's only 500] since I didn't have much > time last months. > > Just for the record: IPLAY v1.21 was not meant to be distributed... It was > a special version for the Assembly '94 CD only... We're currently working > on version 1.3 which will have many fixes, changes and new stuff... Don't > know when it will be available though [When it is finished I guess... :-] > i want this CD, where may i order this from? ----------------- Date: Wed, 25 Jan 95 21:21 EET From: darryl.teichroeb@t8000.cuc.ab.ca Subject: [INERTIA-TALK:1166] [INERTIA- [drone] > > Can someone explain why soundcards must contain RAM to do this type > > of .MODule mixing? What I'm getting at is, it would be nice to have a > > card that does'nt require on-card RAM to be able to do non-CPU-intensive > > sample mixing. Could'nt this be accomplished by using motherboard RAM and > > DMA? [blah] > from the CPU. Theoretically you could do the same thing with shared > RAM on the main board and fast DMA transfers, but this method is not > nearly as elegant. For one thing, DMA still requires some CPU [whack!] > but it still hogs down the bus for no good reason. Independent RAM > on the card is just a much better solution. [slice] > > (side note: I'm sure if this could be done, we would'nt have > > videocards with onboard RAM... now would we?) > Yeah, basically the same story here, not enough speed and too much [timber!] > > I want to know the reasons why this can't be done! (BTW, I've got > > 16MB 60ns RAM on my MB, so you can see why I'm biased! ;-)) And _broke_... > Yes, but it's one of the goals in computer architecture design to create as > many independent fully functional sub-systems with a unified standard > interface as possible. This way your sub-system's h/w can be replaced > without worrying about interferring with something else in the system. > It's a main pre-requisite for modular, upgradable, interchangable, > yet still competitive h/w. Well put! You've been using computers for what... 1-2 years now?!? B-) TTYL Darryl T. darryl.teichroeb@t8000.cuc.ab.ca ----------------- Date: Wed, 25 Jan 95 21:27 EET From: darryl.teichroeb@t8000.cuc.ab.ca Subject: [INERTIA-TALK:1167] [INERTIA- [...] > > Can someone explain why soundcards must contain RAM to do this > > type of .MODule mixing? What I'm getting at is, it would be nice > > to have a card that does'nt require on-card RAM to be able to do > > non-CPU-intensive sample mixing. Could'nt this be accomplished by > > using motherboard RAM and DMA? [...] > Well, among other things, it would play hell with the bus. > Think about a video card that uses system RAM. Ok. Every refresh, it > needs to read in a WHOLE SCREEN FULL of memory. That's 60-70 times a > second, the bus needs to send 64K. (More in SVGA modes/undocumented VGA > modes). Lets see.. 65 536bytes * 70Hz = 4 587 520bytes or 4.375MB in one second... That's feesable with a 8MHz 16bit buss, but at 1280*1024*16M I start to understand what yer saying... > > That's a lot of bus bandwidth. Now, throw in 14 channel 16 bit 44.1 > kHz sound, and that brings your total up to... close to five megs a > second to be moved around your computer, in low resolution graphics > modes. In hi res modes, it would be CONSIDERABLY higher. (For > instance, in 640x480x4bpp, it would take on the order of 10 meg/second, > plus whatever sound you're running._) Hehe.. I think I can smell the 'ol MB bus smoking already! I suppose I shoulda stayed awake in DMA 101 afterall! Darryl T. darryl.teichroeb@t8000.cuc.ab.ca ----------------- Date: Wed, 25 Jan 95 21:51 EET From: DAVE MCCARTER <50VE3GSO@qstar.fanshawec.on.ca> Subject: [INERTIA-TALK:1168] Inertia Player and Composer Hi, On what ftp site can I find the latest version of Inertia Player and Inertia Composer? Thanks. Peter McCarter ----------------- Date: Wed, 25 Jan 95 23:53 EET From: Schitzo Subject: [INERTIA-TALK:1170] Re: IPLAY V1.21!!! On Wed, 25 Jan 1995, Stefan Danes wrote: > Schitzo writes: > > > hey new version's out!!! with added features & bug fixes and > >there's talk about version 1.30 coming out soon!!! :) > > > > i just got it off a local bbs and i'll ul'd it to > >archive.epas.toronto.edu tomorrow! any other sites i should ul'd it to? > Carefully: They copied it from the Assembly '94 CDROM and if ISETUP isn't > exactly 8200 bytes it is infected by the TAIPAN virus!!! Only FPROT v2.16 > and above will detect it: no other virus scanner will see the virus... ok well i've scanned ALL my files on my hard drive with both f-prot v2.16 AND mcafee scan v2.14e and both came up negative in finding any signs of viruses. should i still be worried? is there newer versions of either virus scans? -----------------