Back to home page

DOS ain't dead

Forum index page

Log in | Register

Back to index page

RayeR

CZ,
06.02.2011, 23:37

Scitech SNAP audio (Users)

Please does anybody have a local copy of
snapaudio-dos-1.0.1.exe
or can tell what's inside? I googled but there are only dead links to scitech FTP.

---
DOS gives me freedom to unlimited HW access.

rr

Berlin, Germany,
07.02.2011, 21:43

@ RayeR

Scitech SNAP audio

> Please does anybody have a local copy of
> snapaudio-dos-1.0.1.exe
> or can tell what's inside? I googled but there are only dead links to
> scitech FTP.

Sorry, I can't help, but maybe http://www.visualcv.com/abloo or chrisbrady@altrichmond.ca can.

---
Forum admin

Zyzzle

08.02.2011, 00:15

@ RayeR

Scitech SNAP audio

I do have this file, but the version I have requires a key (serial number) to unlock all functionality, it's useless without that serial. Perhaps the real question should be, does anyone have a working serial number to enable this program to install correectly?

Since Scitech went out of business, all links and information is gone, but my understanding is that the SNAP audio drivers were supposed to be like Univbe for audio cards, ie, a "universal" audio solution for DOS. The concept was extremely promising, but it seems to not have taken off. A pity. I think one of the functions of these drivers is to provide SB support in DOS for many newer PCI-based cards which do not have native PCI drivers for DOS. It seems the interface is built on an API which is proprietary to Scitech, like their SNAP video drivers.

Is it possible to rekindle the interest in providing a universal SB driver / emulator to get DOS games working with sound for newer cards, or is that a lost dream at this point?

RayeR

CZ,
08.02.2011, 13:23

@ Zyzzle

Scitech SNAP audio

> I do have this file, but the version I have requires a key (serial number)

:(

What exactly it do without s/n? You're unable to unpack/install files at all or can install some of them/with time limit or otherway crippled?

I found it by coincidence when googling something different (a SB audigy 2 driver for WNT4). I know about SNAP graphics for DOS/WIN/Linux but didn't know they also did audio drivers (should support SB, AC97, even HDA). I got snapaudio 1.1.2 for WinNT but it seems that SB drivers was not finished there.
I think that SNAP was great idea how to conduct hardware chaos into some platform independent standard but seems that HW manufacturers don't care. They just make drivers for (latest) windows and they're done...

---
DOS gives me freedom to unlimited HW access.

Laaca

Czech republic,
08.02.2011, 18:42

@ RayeR

Scitech SNAP audio

I downloaded it when it was possible but it was quite useless for me. It has support only for few chips. I remember it didn't work nor for SB Live! nor for my VIA 82... chip.
It is some kind of sound library, not TSR emulation drive.
So I deleted it.
Maybe you could send a personal mail to people from former SciTech.

---
DOS-u-akbar!

Zyzzle

09.02.2011, 01:13

@ RayeR

Scitech SNAP audio

See this post:

http://www.computing.net/answers/dos/snap-audio-for-onboard-audio-ali-/16245.html

That is exactly my problem. The archive decompresses but I can't use it to test compatibility.

Here are the chipsets which claim to be supported (pasted from README file):
----------------------------------------------------------------
Supported Audio Chips
---------------------

This is a list of the various audio chipsets that have been tested with
this version of SciTech SNAP Audio. They can be used with any applications
that use SciTech SNAP technology directly.

AC97 Controllers
ATI SB200, SB300, SB400
Intel ICH2, ICH3, ICH4, ICH5, ICH6, ICH7
nVidia nForce, nForce2, nForce3

HDA Controllers
ATI SB450
Intel ICH6, ICH7, ICH8
---------------------------------------------------------------

If you'd like I can send you a copy of the .EXE file, if you think you can get it working or cracked. pm me if you want and I'll scrounge through my old hd and locate the file.

Yes, I agree audio card developers just don't care, most of current ASP is done in software anyway, drivers are only Win and often not even Linux version is released.

RayeR

CZ,
09.02.2011, 16:12

@ Zyzzle

Scitech SNAP audio

> That is exactly my problem. The archive decompresses but I can't use it to
> test compatibility.

Hm, this sounds bad. Maybe there are some experienced hackers but nobody probably have enogh time. I just wanted to know how this SNAP package works - if it's kinda TSR like UNIVBE or it is just a library that allows you to write new programs but it is useless for existing progs.

> Intel ICH6, ICH7, ICH8

I'm little bit confused about HDA chipsets. I have ICH7 but in specification the soundchip is Realtek ACL888. This means that ICH7 audio is disabled and ACL888 i alternative or it cooperates together (ICH7 has HDA core and ACL888 is only DAC/ADC + mixer etc.)?

---
DOS gives me freedom to unlimited HW access.

Rugxulo Usono, 10.02.2011, 07:54 @ RayeR	Scitech SNAP audio Post reply
	Found an old post on comp.os.msdos.djgpp, maybe it helps??? http://groups.google.com/group/comp.os.msdos.djgpp/msg/44f8fc6ba4bb8a01?dmode=source

RayeR

CZ,
10.02.2011, 18:20

@ Rugxulo

Scitech SNAP audio

> Found an old post on comp.os.msdos.djgpp, maybe it helps???
>
> http://groups.google.com/group/comp.os.msdos.djgpp/msg/44f8fc6ba4bb8a01?dmode=source

All links in that post are dead...

It's just backside of the Internet. New informations will spread extremely quick but old fades quick too, not like paper books... What will remains after our computer generation? Just a buch of unreadable discs and silicon dies? :-D

---
DOS gives me freedom to unlimited HW access.

Khusraw

Bucharest, Romania,
10.02.2011, 10:06
(edited by Khusraw, 10.02.2011, 10:34)

@ RayeR

Scitech SNAP audio

> Hm, this sounds bad. Maybe there are some experienced hackers but nobody
> probably have enogh time. I just wanted to know how this SNAP package works
> - if it's kinda TSR like UNIVBE or it is just a library that allows you to
> write new programs but it is useless for existing progs.

It is just a library that allows you to write new programs. The package doesn't document the API, and the drivers are bloated and support a limited number of cards. I had the file (with the R.N.), but like Laaca, finding it useless I deleted it.

---
Glory to God for all things

RayeR

CZ,
10.02.2011, 15:27

@ Khusraw

Scitech SNAP audio

> It is just a library that allows you to write new programs. The package
> doesn't document the API, and the drivers are bloated and support a limited
> number of cards. I had the file (with the R.N.), but like Laaca, finding it
> useless I deleted it.

Aha, thanks for info! Then I'm not further interested. We already have available source of mpxplay with its drivers that may be used with some effort (i'd rather like DJGPP sources than OW but it's my problem).

---
DOS gives me freedom to unlimited HW access.

Khusraw

Bucharest, Romania,
10.02.2011, 15:39

@ RayeR

Scitech SNAP audio

> Aha, thanks for info! Then I'm not further interested. We already have
> available source of mpxplay with its drivers that may be used with some
> effort (i'd rather like DJGPP sources than OW but it's my problem).

Mpxplay's drivers are taken from ALSA and fitted to suit the player needs. My opinion re: DOS sound card drivers is that I prefer modular drivers to statically linked ones, if I would want to port contemporary software from Linux I would port OSS or ALSA, and if I would be strictly interested in DOS, I would write drivers which use an (obviously enhanced, but backward compatible) API like DIGIPAK's.

---
Glory to God for all things

RayeR

CZ,
10.02.2011, 18:32

@ Khusraw

Scitech SNAP audio

> Mpxplay's drivers are taken from ALSA and fitted to suit the player needs.
> My opinion re: DOS sound card drivers is that I prefer modular drivers to
> statically linked ones, if I would want to port contemporary software from
> Linux I would port OSS or ALSA, and if I would be strictly interested in
> DOS, I would write drivers which use an (obviously enhanced, but backward
> compatible) API like DIGIPAK's.

I don't have experiences with sound programming so I don't know this API. I only remember MIDAS library that was widely spreaded in demoscene. About OSS/Alsa - I would expect it heavily depends on linux kernel functions which will be missing under DOS...

---
DOS gives me freedom to unlimited HW access.

Khusraw

Bucharest, Romania,
10.02.2011, 19:51

@ RayeR

Scitech SNAP audio

> I don't have experiences with sound programming so I don't know this API. I
> only remember MIDAS library that was widely spreaded in demoscene. About
> OSS/Alsa - I would expect it heavily depends on linux kernel functions
> which will be missing under DOS...

I didn't have you in mind, like Rugxulo I had in mind the "general" reader. They depend on Linux, but not so heavy, someone with both Linux and DOS programming knowledge could port them in a couple of hours.

---
Glory to God for all things

Mpxplay

11.02.2011, 17:13

@ Khusraw

Scitech SNAP audio

> I didn't have you in mind, like Rugxulo I had in mind the "general" reader.
> They depend on Linux, but not so heavy, someone with both Linux and DOS
> programming knowledge could port them in a couple of hours.

Maybe "in a couple of years"... :-|
I couldn't take out the X-Fi handling neither (because the source is uncommented and calls many Linux/ALSA kernel functions, it made by Creative and doesn't follow the ALSA source conventions/structure)... :-(

But perhaps an SB16 emulator on Intel HDA chips is not impossible (but maybe it fails due to the latest motherboard changes)... Just who will make it? :-D

Khusraw

Bucharest, Romania,
11.02.2011, 19:21
(edited by Khusraw, 11.02.2011, 20:01)

@ Mpxplay

Scitech SNAP audio

> Maybe "in a couple of years"... :-|
> I couldn't take out the X-Fi handling neither (because the source is
> uncommented and calls many Linux/ALSA kernel functions, it made by Creative
> and doesn't follow the ALSA source conventions/structure)... :-(

How many different calls, thousands, hundreds? I assure you that for someone having Linux programming knowledge it is a trivial task, personally I am stranger to Linux, but those which I understand I could easily emulate in my various projects.

> But perhaps an SB16 emulator on Intel HDA chips is not impossible (but
> maybe it fails due to the latest motherboard changes)... Just who will make
> it? :-D

I don't think that SB16 emulation is particularly special on Intel HDA, it is a general problem of port trapping, the approach being dependent on system state(real mode or protected mode).

---
Glory to God for all things

Mpxplay

11.02.2011, 23:13

@ Khusraw

Scitech SNAP audio

> How many different calls, thousands, hundreds? I assure you that for
> someone having Linux programming knowledge it is a trivial task, personally
> I am stranger to Linux, but those which I understand I could easily emulate
> in my various projects.

Probably I'm the only one who converted anything from Linux/ALSA to DOS. The question can be: why ... (the answer can be: I'm the God or I'm a crazy :-D )
btw. my primary problem is rather that, the Watcom compiler cannot compile C99 code, first I always must to rewrite the C99 code to ANSI, and this already can cause a couple of bugs in the code... :-|
(I've built a new ffcodec library to Mpxplay yesterday (to update flac and wma decoders), "of course" it doesn't want to work... :-( )

Rugxulo

Usono,
12.02.2011, 01:28

@ Mpxplay

Scitech SNAP audio

> Probably I'm the only one who converted anything from Linux/ALSA to DOS.

Probably, yes, though Khusraw keeps mentioning how Mik ported OSS for his own use.

> The question can be: why ... (the answer can be: I'm the God or I'm a crazy
> :-D )

Crazy god? ;-) No, seriously, you're just another genius hacker who decided to share his work. Thanks!

> btw. my primary problem is rather that, the Watcom compiler cannot compile
> C99 code, first I always must to rewrite the C99 code to ANSI

-za99 doesn't work (well enough)??

P.S. http://en.wikipedia.org/wiki/SciTech_SNAP

> In December 2008 Alt Richmond Inc. closed the acquisition of
> SciTech Software?s SNAP technology. The plans of SciTech Software
> in 2008 to create OpenSNAP, an open source version of the
> driver technology, are therefore no longer an option unless
> Alt Richmond decides to pick this up.

Mpxplay 12.02.2011, 03:15 @ Rugxulo	Scitech SNAP audio Post reply
	> -za99 doesn't work (well enough)?? Where do you see such option? I don't find... There is only a -za option, which DISABLES the partial C99 support (I think so).

Rugxulo

Usono,
12.02.2011, 03:35

@ Mpxplay

Scitech SNAP audio

> > -za99 doesn't work (well enough)??
>
> Where do you see such option? I don't find... :-|
> There is only a -za option, which DISABLES the partial C99 support (I think
> so).

http://www.openwatcom.org/index.php/C99_Compliance

> C99 Compliance
>
> There is an ongoing effort to improve compliance with the
> ISO/IEC 9899:1999 standard, also known as C99.
>
> C99 compatibility is an undocumented feature, since the implementation
> is not complete. Use the -za99 switch to turn on the C99 extensions
> that are implemented (see below).

Mpxplay

12.02.2011, 12:06
(edited by Mpxplay, 12.02.2011, 12:19)

@ Rugxulo

Scitech SNAP audio

> > > -za99 doesn't work (well enough)??
> >
> > Where do you see such option? I don't find... :-|
> > There is only a -za option, which DISABLES the partial C99 support (I
> think
> > so).
>
> http://www.openwatcom.org/index.php/C99_Compliance

Thnx. I didn't spend too much time on the OW site (and this option is not in the official wcc386 options). :-)
btw. I have to use the -aa option too
btw2. some important C99 things came after OW 1.3 (I used this version till last year), like "mixed declarations and code", but other things are still missing. I will test...

Khusraw

Bucharest, Romania,
12.02.2011, 08:41

@ Mpxplay

Scitech SNAP audio

> (I've built a new ffcodec library to Mpxplay yesterday (to update flac and
> wma decoders), "of course" it doesn't want to work... :-( )

The problem might be caused by some data misalignment, I encountered myself such problems when I built it with DJGPP.

---
Glory to God for all things

Mpxplay

12.02.2011, 12:18

@ Khusraw

Scitech SNAP audio

> > (I've built a new ffcodec library to Mpxplay yesterday (to update flac
> > and wma decoders), "of course" it doesn't want to work... :-( )
>
> The problem might be caused by some data misalignment, I encountered myself
> such problems when I built it with DJGPP.

It have to be problem at SSE(/MMX?) code, I use the C code only...
Or I'm wrong... :-)
I've just compiled the required sources/functions and made some fast tests, I haven't run any debuging yet...

Khusraw

Bucharest, Romania,
12.02.2011, 13:42
(edited by Khusraw, 12.02.2011, 15:16)

@ Mpxplay

Scitech SNAP audio

> It have to be problem at SSE(/MMX?) code, I use the C code only...
> Or I'm wrong... :-)

The problem was with the C code. The COFF used by DJGPP doesn't support section alignment, so using the assembly language code worked only with some ugly hacks of which I was unsatisfied. Did you compile it with SSE enabled?

Edit: I just looked and saw that you don't use even the inline assembly code, and you compile it for 386, so it seems it is a different problem. Ffcodec is not too much tested with 386, even the run-time detection dependent code was broken last time when I checked (it used MMX if the library was built with MMX enabled).

---
Glory to God for all things

Mpxplay

12.02.2011, 20:01

@ Khusraw

Scitech SNAP audio

> Edit: I just looked and saw that you don't use even the inline assembly
> code, and you compile it for 386, so it seems it is a different problem.
> Ffcodec is not too much tested with 386, even the run-time detection
> dependent code was broken last time when I checked (it used MMX if the
> library was built with MMX enabled).

The inline asm syntax is different in Watcom (#pragma aux), maybe I cannot compile the ffmpeg's (gcc style) asm routines with -za99 option nether.
Because the audio decoders don't really need too much CPU power in C neither (I mean my target CPU is not a 486 anymore), I didn't care with the inline asm routines of ffmpeg at all.

I will play some days with my new ffcodec library, if I don't find the problem soon, I will restore my old library, and I will try to update the flac decoder only. (the 24-bit flac decoding is wrong in the old ffmpeg lib, the wma decoder doesn't really need correction)

Rugxulo

Usono,
12.02.2011, 20:54

@ Mpxplay

Scitech SNAP audio

> The inline asm syntax is different in Watcom (#pragma aux), maybe I cannot
> compile the ffmpeg's (gcc style) asm routines with -za99 option nether.
> Because the audio decoders don't really need too much CPU power in C
> neither (I mean my target CPU is not a 486 anymore), I didn't care with the
> inline asm routines of ffmpeg at all.

Since 11.0 (?), Watcom has supported "_asm" also, though it might slow things down a tad due to preserving everything (and the optimizer doesn't cooperate with it, unlike pragma aux). I think?

If you can assemble the code with GCC or GAS, try running "objdump -d -M intel" on the output, then you'll see it as Intel syntax instead of AT&T. I assume that would help you translate it easier.

Mpxplay

15.02.2011, 16:14

@ Rugxulo

Scitech SNAP audio

> Since 11.0 (?), Watcom has supported "_asm" also, though it might slow
> things down a tad due to preserving everything (and the optimizer doesn't
> cooperate with it, unlike pragma aux). I think?
>
> If you can assemble the code with GCC or GAS, try running "objdump -d -M
> intel" on the output, then you'll see it as Intel syntax instead of AT&T. I
> assume that would help you translate it easier.

Because later (this means years) I would like to use an other compiler (probably GCC) for Mpxplay, I don't want to add any asm code, only if it's really needed (nothing needs now)...
btw. -za99 option helped me to compile faster the FFMPEG decoder (I mean I've compiled only a newer flac decoder to Mpxplay, it's solved the 24-bit sound bugs), thnx :-)

DOS386

17.02.2011, 06:28

@ Mpxplay

Scitech SNAP audio | DEATH of WATCOM | Shots

> Because later (this means years) I would like to use an other compiler
> (probably GCC) for Mpxplay

Evil WATCOM :confused:

> > I'll recheck ...
> I think it's not needed after explanation higher...

[image]
[image]

http://ompldr.org/vN2c4NQ/SNAP.ZI7 (6 MiB, useless)

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

DOS386

13.02.2011, 06:04

@ RayeR

Scitech SNAP audio

> Please does anybody have a local copy of snapaudio-dos-1.0.1.exe

YES

> or can tell what's inside?

I'll recheck ...

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

RayeR

CZ,
14.02.2011, 13:27

@ DOS386

Scitech SNAP audio

> > Please does anybody have a local copy of snapaudio-dos-1.0.1.exe
>
> YES
>
> > or can tell what's inside?
>
> I'll recheck ...

I think it's not needed after explanation higher...

---
DOS gives me freedom to unlimited HW access.

Back to index page

22767 Postings in 2122 Threads, 402 registered users (1 online)
DOS ain't dead | Admin contact

powered by my little forum