Date: Wed, 25 Jan 95 00:52 EET
From: "Jens Puchert" <jpuchert@mailbox.syr.edu>
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 <cmkoski@THUNDER.LakeheadU.CA>
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 <enrico@max.tiac.net>
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 <g4psycho@cdf.toronto.edu>
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" <jpuchert@mailbox.syr.edu>
Subject: [INERTIA-TALK:1158] Re: [INERTIA- 

In message <Pine.3.05.9501242101.A6848-c100000@thunder> 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 <g4psycho@cdf.toronto.edu> 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 <bijls401@tem.nhl.nl>
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 <g4psycho@cdf.toronto.edu>
> Date: Wed, 25 Jan 95 06:56 EET
> Subject: [INERTIA-TALK:1157] IPLAY V1.21!!!
> To: Multiple recipients of list <inertia-talk@oliver.sun.ac.za>
> 
> 	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 <COCHRAN@NELSON.TAMU.EDU>
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 <lewiar@essex.ac.uk>
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" <KALUPNIE@fs2.ucc.on.ca>
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" <KALUPNIE@fs2.ucc.on.ca>
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 <g4psycho@cdf.toronto.edu>
Subject: [INERTIA-TALK:1169] Re: IPLAY V1.21!!!


On Wed, 25 Jan 1995, Stefan Danes wrote:

> Schitzo <g4psycho@cdf.toronto.edu> 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 <g4psycho@cdf.toronto.edu>
Subject: [INERTIA-TALK:1170] Re: IPLAY V1.21!!!


On Wed, 25 Jan 1995, Stefan Danes wrote:

> Schitzo <g4psycho@cdf.toronto.edu> 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?


-----------------

