DOS ain't dead

I'am testing mplayer ( from Sherpa) under dosHX
I'have the required DLL, but "error your card doesn't support overlay".
Instead my card and video work with mplr2010 (from Glenn - on freedos
without HX)
You know this problem?
Or is there a problem with the syntax/options in the program?
thanks

> I'am testing mplayer ( from Sherpa) under dosHX
> I'have the required DLL, but "error your card doesn't support overlay".

Again, RTFW

> Instead my card and video work with mplr2010 (from Glenn

??? "Glenn's version" is from 2008


"mplayer.zip" 5'203'892 | Mik | Glennmcc's preferred version "r27185" DGJPP
7F99'C4F7'C576'22ED'092C'B864'5E8E'C024
"http://glennmcc.org/download/mik/"
"mplayer.zip" -- 03/25/10 | 18:36 -- 5203892 bytes

MPD27185.EXE "mplayer.exe" 5'266'124 2008-07-03 10:43
UPX'ed with 3.02 | Mik | Glennmcc's preferred version
D4F3'5AD6'C701'817D'A5D2'4380'0E3C'8856

MPD27185.EXE 13'544'960 | Un-UPX'ed
D1D2'86BD'86CE'6894'668E'0DD9'97FE'50D0

Theora: - "Offset-BUG" : OK (!!!)
        - "OGG-parse-hang-BUG" : present
        - "Sub-other-than-420-BUG" : present (?)

MPlayer SVN-r27185 (C) 2000-2008 MPlayer Team
CPU: Intel ...
CPUflags:  MMX: 1 ...
Compiled with runtime CPU detection.
Usage:   mplayer [options] [url|path/]filename


> - on freedos without HX)



> You know this problem?
> Or is there a problem with the syntax/options in the program?

See above: -vo sdl -really-quiet -YES-I-did-RTFM-and-RTFW

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

Im looking download link for the latest mplayer DGJPP port by Khusraw. All links that I found are down!

> Im looking download link for the latest mplayer DGJPP port by Khusraw. All
> links that I found are down!

I have mirrored one. :)

mplayer.exe -vo vesa -really-quiet -zoom -x 1024 -y 768 -vsync %1 %2 %3 %4 %5 %6 %7 %8 %9

mplayer.exe -vo cvidix -dr -nocolorkey -xy 1024 -quiet -vsync %1 %2 %3 %4 %5 %6 %7 %8 %9

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

> Im looking download link for the latest mplayer DGJPP port by Khusraw. All
> links that I found are down!

Unfortunately I have no more of any of my builds, as I became disappointed with the project. If someone still has the last build I posted, perhaps he may help.

---
Glory to God for all things

> Unfortunately I have no more of any of my builds, as I became disappointed
> with the project. If someone still has the last build I posted, perhaps he
> may help.

oh! a pity.. Im using your player each night to watch movies. I was QV user but mplayer supports every format available today ;)

@RayeR big thanks for the upload. If this is the last version ll conserve it like gold.

Hey maybe any of you can help me.


This version uses Allegro for audio.. so its a bit different from official Mplayer.
There are special command lines to change allegro audio options?

for example I have a SBpro.. and I notice that mplayer is playing at 22050 stereo.. I would want to change playback to 44100 mono.

I know that you can use Stereo=1 inside the mplayer config file to change to mono in the official Mplayer.. but no idea if its working in this allegro version (I have a single speaker in this computer).


what about the samplerate? I know that there are resample comandline options inside mplayer.. but Im not looking for that.. I just need to set allegro to use 44100 samplerate instead 22050

Its possible change playback bits (8/16)?

> > I'am testing mplayer ( from Sherpa) under dosHX
> > I'have the required DLL, but "error your card doesn't support overlay".
>
> Again,
> RTFW
>
>
> > Instead my card and video work with mplr2010 (from Glenn
>
> ??? "Glenn's version" is from 2008
>
>
> "mplayer.zip" 5'203'892 | Mik | Glennmcc's preferred version "r27185"
> DGJPP
> 7F99'C4F7'C576'22ED'092C'B864'5E8E'C024
> "http://glennmcc.org/download/mik/"
> "mplayer.zip" -- 03/25/10 | 18:36 -- 5203892 bytes
>
> MPD27185.EXE "mplayer.exe" 5'266'124 2008-07-03 10:43
> UPX'ed with 3.02 | Mik | Glennmcc's preferred version
> D4F3'5AD6'C701'817D'A5D2'4380'0E3C'8856
>
> MPD27185.EXE 13'544'960 | Un-UPX'ed
> D1D2'86BD'86CE'6894'668E'0DD9'97FE'50D0
>
> Theora: - "Offset-BUG" : OK (!!!)
> - "OGG-parse-hang-BUG" : present
> - "Sub-other-than-420-BUG" : present (?)
>
> MPlayer SVN-r27185 (C) 2000-2008 MPlayer Team
> CPU: Intel ...
> CPUflags:  MMX: 1 ...
> Compiled with runtime CPU detection.
> Usage:   mplayer [options] [url|path/]filename
>
>
> > - on freedos without HX)
>
>
>
> > You know this problem?
> > Or is there a problem with the syntax/options in the program?
>
> See above: -vo sdl -really-quiet -YES-I-did-RTFM-and-RTFW

> thanks,
but about MPLR2010 I downloaded from glennmcc.org/download (mplr2010.zip)
posted from 09-08 2010 5.405.307 bytes
it works fine, except for a line in the screen,
and I can see .vob files from dvd etc.
I don't know other (video)mplayer from Glenn

> Unfortunately I have no more of any of my builds, as I became disappointed
> with the project. If someone still has the last build I posted, perhaps he
> may help.

Before deleting it you could upload somewhere the complete build setup so someone may continue devel. It's messy downloading, configuring and rebuilding all needed libraries, I wasted a day with it doing for MuPDF... I don't mean that I want to continue with devel. mplayer now but maybe, someone... e.g. mighty dos386 ;)

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

> Before deleting it you could upload somewhere the complete build setup so
> someone may continue devel. It's messy downloading, configuring and
> rebuilding all needed libraries, I wasted a day with it doing for MuPDF...
> I don't mean that I want to continue with devel. mplayer now but maybe,
> someone... e.g. mighty dos386 ;)

I still have the source code, when I will find some time perhaps I will create the patch files and put them somewhere. I got disappointed because there is no solution for hardware acceleration in DOS for newer video cards, so mplayer is slow, and on the other hand ffmpeg, which was already a mess, became an even greater mess.

---
Glory to God for all things

> I got disappointed because
> there is no solution for hardware acceleration in DOS for newer video
> cards, so mplayer is slow.

You mean it is technicaly imposible from some reason?
Or just is not available any recent Vidix library or something similar supporting newer cards?

On my computer it is quick enough. Even VESA output is OK and CVidix and SVGA outputs are really fast.

---
DOS-u-akbar!

> I still have the source code, when I will find some time perhaps I will
> create the patch files and put them somewhere. I got disappointed because
> there is no solution for hardware acceleration in DOS for newer video
> cards, so mplayer is slow, and on the other hand ffmpeg, which was already
> a mess, became an even greater mess.

I would prefer if you could upload whole build package. I'm also disappointed because of no sound so I use QuickView (with native SB live driver) anyway...
But maybe...

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

> You mean it is technicaly imposible from some reason?
> Or just is not available any recent Vidix library or something similar
> supporting newer cards?

I think because Vidix is some way crippled on new HW, no future for it...
But VESA works fine for me. Except latest core i5 crap...

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

> You mean it is technicaly imposible from some reason?
> Or just is not available any recent Vidix library or something similar
> supporting newer cards?

There are no open source drivers. I own three systems, having ATI Mach64, NVIDIA GeForce 7600GS and Intel GM945 video cards. The only video card for which there is hardware acceleration support (both in Vidix and svgalib) is the ATI Mach64 one, with the other two mplayer is slow as hell. Strangely enough, mplayer is faster with ATI Mach64 than with NVIDIA GeForce 7600GS even using VESA (with mtrrs set)!

---
Glory to God for all things

> There are no open source drivers. I own three systems, having ATI Mach64,

Maybe something could be exploited from opensource nVidia nouveau drivers... But I don't know how far they get from simple 2D acceleration...

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

> have the source code, when I will find some time perhaps I will create the patch files

or upload the full source

> and put them somewhere

omp

or you could compile a new binary one day ? (see other thread, I continue testing ...)

> I got disappointed because there is no solution for hardware
> acceleration in DOS for newer video cards, so mplayer is slow

NOT critical at all BTW, you even got the sound working

> and on the other hand ffmpeg, which was already a mess, became an even greater mess

Any more exact observations about what's evil ?

> I'm also disappointed because of no sound

It works on Intel ICH

> so I use QuickView (with native SB live driver)

The SDR file ? Just port it ... BTW, QV is lacking many formats (Theora, WeBM, ...)

FYI, I __NEVER__ touch "SB emulation" crap (silence is less bad)

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

> I still have the source code, when I will find some time perhaps I will
> create the patch files and put them somewhere. I got disappointed because
> there is no solution for hardware acceleration in DOS for newer video
> cards, so mplayer is slow, and on the other hand ffmpeg, which was already
> a mess, became an even greater mess.

I agree that the project should be kept alive, at least someone might try recompiling it at a later date. Sound is dicey, bssut who knows?? Maybe Mpxplay code?

Sherpya's binary r32848 seems to support Blu-Ray playback through libbluray. How neat would it be for us stalwart DOS users to get that possibilty through a new DJGPP port? But first we would need a working UDF 2.5 driver, right? Well, I guess Blu-Ray in DOS will be pretty hard to accomplish... We would need an extremely fast PC (no 2D-hardware acceleration exists for newer cards in DOS!), a UDF 2.5 driver, AND libbluray ported to DJGPP in Mplayer! Not to mention the 2 Gb / 4 GB limit would need to be overcome, but UDF does "do away" with it, at least when talking about raw sectors on optical discs.

> But first we would need a working UDF
> 2.5 driver, right? Well, I guess Blu-Ray in DOS will be pretty hard to
> accomplish... We would need an extremely fast PC (no 2D-hardware
> acceleration exists for newer cards in DOS!), a UDF 2.5 driver, AND

Yes. a long time ago I contasted the author of shsucdx and ask him for UDF support for DVD-RAM media. He wrote some short demo that listed rootdir of the UDF disc but later he was not time/interest to continue devel. Some years after I asked him again and for src of his demo but no reply.

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

the Khusraw release is very good, and maybe faster than Sherpya's one.
The only problem is the audio.
I notice that soundcard is autodetected.. and you cannt change or force other settings.

Maybe with some command lines to configure soundcard all problems would be gone.

QV is a decent player but a pity that coder abandoned the project. Its based in ffdshow too.. so he can implement other formats,.. but sadly he sais that he dont have time for it ;/

> Sherpya's binary r32848 seems to support Blu-Ray playback through
> libbluray. How neat would it be for us stalwart DOS users to get that
> possibilty through a new DJGPP port? But first we would need a working UDF
> 2.5 driver, right?

As you noticed, like libdvdread, it is dependent on OS support, which still lacks in DOS. Unfortunately I don't have the knowledge to provide myself such support.

---
Glory to God for all things

> > and on the other hand ffmpeg, which was already a mess, became an even
> greater mess
>
> Any more exact observations about what's evil ?

Most of the code is simply over-complicated. There are too many cross-relations between the data-structures (h files) and functions (c files). So, the whole source is not structured well... (they develop fast, but - it seems - they think twice nothing)
But maybe other people say the same thing about my source too...
Everybody develop for his own requirements...

> Most of the code is simply over-complicated. There are too many
> cross-relations between the data-structures (h files) and functions (c
> files). So, the whole source is not structured well... (they develop fast,
> but - it seems - they think twice nothing)

It is the result of too many hands, and too much Unix oriented. OTOH, last time I checked it, the runtime CPU detection dependent code was broken, and I read on their board that they had no intention to fix this (i.e. defining HAVE_MMX implied that it necessarily used MMX code). This is what they were calling "cleaning" the code.

---
Glory to God for all things

> last time I checked it, the runtime CPU detection dependent code was broken, > and I read on their board that they had no intention to fix this (i.e.
> defining HAVE_MMX implied that it necessarily used MMX code).

But they have implemented a couple of things which (should) depend on the runtime CPU detection, like the dynamic structure of avcodec\dsputil.c
Now I try to move/add the avformats of ffmpeg to Mpxlay in a native way, without using the highest and lowest level APIs of ffmpeg. A lot of work...

> It works on Intel ICH

Unfortunately not on my ICH7/ALC888 HDA.

> > so I use QuickView (with native SB live driver)
>
> The SDR file ? Just port it ...

Even worse, I just found that it doesn't work with Audigy 2 (emu10k2).
I patched EMU10K1.SDR and SBLIVE24.SDR to PCI device ID 0004h but didn't worked :(

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

> > It works on Intel ICH
>
> Unfortunately not on my ICH7/ALC888 HDA.
>
> > > so I use QuickView (with native SB live driver)
> >
> > The SDR file ? Just port it ...
>
> Even worse, I just found that it doesn't work with Audigy 2 (emu10k2).
> I patched EMU10K1.SDR and SBLIVE24.SDR to PCI device ID 0004h but didn't
> worked :(

Maybe it is worth to try to set Audigy 2 mixer by utility from Attila Padar and after then run QuickView.
Anyway, if you want I have the source code for SDR driver from SBLive! and API description for QuickView drivers.

---
DOS-u-akbar!

> Maybe it is worth to try to set Audigy 2 mixer by utility from Attila Padar
> and after then run QuickView.
> Anyway, if you want I have the source code for SDR driver from SBLive! and
> API description for QuickView drivers.

I am interested in the API description of these QuickView's SDR drivers. I contacted in this regard some years ago both QuickView's author and Alex HiNT, but I received no answer.

---
Glory to God for all things

> the Khusraw release is very good, and maybe faster than Sherpya's one.

I could not reproduce any performance diff in decoding.

Mpxplay wrote:

> > > hand ffmpeg, which was already a mess, became an even greater mess
> > Any more exact observations about what's evil ?
> Most of the code is simply over-complicated.

Hmm....

> maybe other people say the same thing about my source too

Every source I have found so far was messy ... except trivial examples ("Hello World Plus") and FASM source. But latter has no comments so it is not understandable either

Mpxplay wrote (other threads):

> btw. my primary problem is rather that, the Watcom
> compiler cannot compile C99 code

http://openwatcom.org/index.php/C99_Compliance :-\

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

Or push WATCOM devels :-\

> runtime CPU detection dependent code was broken, and I read on their board
> that they had no intention to fix this (i.e. defining HAVE_MMX implied that it
> necessarily used MMX code).

See also other thread, MMX code polluted by CMOVNTQ: msg=9466

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

> > the Khusraw release is very good, and maybe faster than Sherpya's one.
>
> I could not reproduce any performance diff in decoding.

Umm maybe I did the wrong test.. cause Im not able to run sherpyas one under pure DOS and some audio problems so I need to test inder win98 :(

Khusraw mplayer: VO: vesa AO: allegro
Sherpya mplayer: VO: sdl AO: win32 (maybe this win32 sound is the cpu killer here)

> Khusraw mplayer: VO: vesa AO: allegro

Only my first build had AO allegro, the rest had AO WSS which should work OK with your SB sound card. What video card do you have, there is no svgalib support for it?

---
Glory to God for all things

> > Even worse, I just found that it doesn't work with Audigy 2 (emu10k2).
> > I patched EMU10K1.SDR and SBLIVE24.SDR to PCI device ID 0004h but didn't
> > worked :(
>
> Maybe it is worth to try to set Audigy 2 mixer by utility from Attila Padar
> and after then run QuickView.

The order is wrong. First you have to start the SDR (with QV) and then my Audigy 2 patch. But it's possible only if QV have an "open DOS shell" function (start QV with the SDR, open DOS shell, start my patch, return to QV). I don't really know QV, but I assume it has no such function...

> Anyway, if you want I have the source code for SDR driver from SBLive! and
> API description for QuickView drivers.

I'm not interested in QV development, but then it's not so complicate to build an SDR, based on my au_cards lib...

> The order is wrong. First you have to start the SDR (with QV) and then my
> Audigy 2 patch. But it's possible only if QV have an "open DOS shell"
> function (start QV with the SDR, open DOS shell, start my patch, return to
> QV). I don't really know QV, but I assume it has no such function...

Aha, I trierd it that I boot, run patch and then run QV but I don't know how to do it reverse order. What the patch exactly do? Is the change permanent?

Can you tell how much differs EMU10k2 from EMU10k1 and what needs to be rewritten in the driver source? I hope you have more experiences with it when you implemented it in mpxplay where audigy 2 works fine (also without that patch) I just changed PCI ID in binary and it probably needs more.

I found EMU10k1.sdr sources on Laaca site - it's combination of one ASM file (probably core) and one C file (io.c) probably some interface. So making changes is possible at source level. But I didn't succeed with compiling. ASM module was fine but C file had some warnings and errors - Laaca, what version of Borland C you used? In the d.bat is a link calling bcc32.exe I tried it with BC 3.1 for DOS and BC 4.0 for windows but same error.

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

> > Khusraw mplayer: VO: vesa AO: allegro
>
> Only my first build had AO allegro, the rest had AO WSS which should work
> OK with your SB sound card. What video card do you have, there is no
> svgalib support for it?

hey... did you implement some command line option in allegro or WSS version to change audio options? here the SBpro is always playing at 22050 stereo but I want to use the 44100 mono mode on SBpro

The videocard is a VESA VBE 2.0 MagicGraph 128XD 40K SVGA BIOS [1984 kB]
I think that I can work in VO:vesa only ... no vidix driver for my card

How can I enable svgalib? Here using DOS/win98.. I though svgalib was only for linux

> hey... did you implement some command line option in allegro or WSS
> version to change audio options? here the SBpro is always playing at 22050
> stereo but I want to use the 44100 mono mode on SBpro

WSS has no such option, in what concerns Allegro - I can't remember, I just used Michael Kostylev's driver.

> The videocard is a VESA VBE 2.0 MagicGraph 128XD 40K SVGA BIOS [1984 kB]
> I think that I can work in VO:vesa only ... no vidix driver for my card
> How can I enable svgalib? Here using DOS/win98.. I though svgalib was only
> for linux

If you have my build supporting svgalib's 1.9.25 video drivers, use mplayer with -vo svga and edit libvga.cfg to use chipset NEOMAGIC. Good luck!

---
Glory to God for all things

> I found EMU10k1.sdr sources on Laaca site - it's combination of one ASM
> file (probably core) and one C file (io.c) probably some interface. So
> making changes is possible at source level. But I didn't succeed with
> compiling. ASM module was fine but C file had some warnings and errors -
> Laaca, what version of Borland C you used? In the d.bat is a link calling
> bcc32.exe I tried it with BC 3.1 for DOS and BC 4.0 for windows but same
> error.

Perhaps you should try with BC++ 5.5, it requires a 32-bit compiler.

---
Glory to God for all things

> > The order is wrong. First you have to start the SDR (with QV) and then
> my
> > Audigy 2 patch. But it's possible only if QV have an "open DOS shell"
> > function (start QV with the SDR, open DOS shell, start my patch, return
> to
> > QV). I don't really know QV, but I assume it has no such function...
>
> Aha, I trierd it that I boot, run patch and then run QV but I don't know
> how to do it reverse order.

Maybe I was wrong, because if that SDR is made for SB Live, my patch will never help. My patch works only at an Audigy 1 driver, using on Audigy 2 cards.

> What the patch exactly do? Is the change permanent?

Modifies the hw DSP config of the soundcard (in the soundcard, not in the driver). So, it's a hardware config patch, not a software one.
The next shutdown/reboot resets the DSP of the soundcard too, losing the settings of my patch.

Well, I have never tried to compile the SDR drivers. I only used it as a inspiration for LiveCD (http://www.laaca.borec.cz/soubory/livecd.zip)

Anyway I wrote an API description too. I don't know how much is it useful but it just Wolfgang Hesseler sent to me:


SOUND_EXT_Detect proc near
;Detects the sound chip and initializes it.
;Note: If you reprogram any register for detection you must restore its
;previous content.

;API Version 0:
;Input: ecx: API version: 0 (for API Version 0)
;Output: eax: 0 if chip wasn't detected, otherwise pointer to
; Null-terminated string with the name of the chip
; ecx: undefined, but not of the form ffffffxxH

;API Version 1:
;Input: eax: address of function that translates linear addresses to
; physical addresses
; ecx: API version: 1: 1 (for API Version 1)
;Output: eax: 0 if chip wasn't detected, otherwise pointer to
; Null-terminated string with the name of the chip
; ecx: API version negated (i.e. -1 for current version)

endp


SOUND_EXT_QueryPlayback proc near
;Check playback capabilities. Return the best possible sound chip parameter
;for the input parameters (in case of AC97 it will usually return sampling
;frequency 48000 and doesn't change sample bits and stereo/mono).
;Input: eax: Sampling frequency
; bl: Sample bits (8 or 16)
; bh: Channels (1 for mono, 2 for stereo)
;
;Output:eax: Sampling frequenxy
; bl: Sample bits (8 or 16)
; bh: Channels (1 for mono, 2 for stereo)

endp


SOUND_EXT_InitPlayback proc near
;Initialize playback with the given parameters but don't start playback.
;Input: eax: sampling frequency
; bl: Sample bits (8 or 16)
; bh: Channels (1 for mono, 2 for stereo)
; ecx: Length of DMA buffer
; edx: Physical Address of DMA buffer start
; edi: Linear Address of DMA buffer start
;
;Output:Carry set on error

endp

;Note: SOUND_EXT_InitPlayback will usually be called with the parameters
; returned by SOUND_EXT_QueryPlayback


SOUND_EXT_StartPlayback proc near
;Start playback of sound that is initialized with SOUND_EXT_InitPlayback.
;Input: ecx: Address of callback routine, call this function with each
; interrupt, i.e. after edx bytes were played.
; edx: Number of bytes after which an interrupt must be generated

endp


SOUND_EXT_StopPlayback proc near
;Stop playback of sound.

endp


SOUND_EXT_SetVolume proc near
;Input: al: Left channel [0..255]
; ah: Right channel [0..255]

endp


SOUND_EXT_Pause proc near
;Pause sound immediately.

endp


SOUND_EXT_Resume proc near
;Start playback of sound again that was paused with SOUND_EXT_Pause

endp


SOUND_EXT_GetPlaybackPosition proc near
;Get sample that is currently played as offset from the address of DMA
;buffer start (in bytes)
;Output:eax: Sample byte position

endp


SOUND_EXT_Deinstall proc near
;Deinstall all external driver support.

endp


;Copy the data from PC memory to the (onboard) sound chip memory. For chips
;that support playback directly from DMA memory this function will just
;return immediately.
;Note: API ver. 1 and later only
;Input: ecx: Length in bytes
; esi: Start of data to be copied
; edi: Offset of Data in onboard memory

SOUND_CopySound proc near
ret
endp


The order of the functions is in
API Version 0:
SOUNDdriverRoutines
SOUND_EXT_Detect
SOUND_EXT_QueryPlayback
SOUND_EXT_InitPlayback
SOUND_EXT_StartPlayback
SOUND_EXT_StopPlayback
SOUND_EXT_SetVolume
SOUND_EXT_Pause
SOUND_EXT_Resume
SOUND_EXT_Deinstall
SOUND_EXT_GetPlaybackPosition
SOUND_EXT_InitRecord
SOUND_EXT_StartRecord

API Version 1:
SOUNDdriverRoutines
SOUND_EXT_Detect
SOUND_EXT_QueryPlayback
SOUND_EXT_InitPlayback
SOUND_EXT_StartPlayback
SOUND_EXT_StopPlayback
SOUND_EXT_SetVolume
SOUND_EXT_Pause
SOUND_EXT_Resume
SOUND_EXT_Deinstall
SOUND_EXT_GetPlaybackPosition
SOUND_EXT_CopySound
SOUND_EXT_InitRecord
SOUND_EXT_StartRecord

---
DOS-u-akbar!

> Well, I have never tried to compile the SDR drivers. I only used it as a
> inspiration for LiveCD (http://www.laaca.borec.cz/soubory/livecd.zip)

If I understand well, your utility only sets mixer volume for analog CD in to enable playback without other drivers - you just press play on drive or in cd player SW? Does it work also for digital CD in? Anyway i don't play CDDA in PC drive more, I have better CDP... I can see you add audigy (device ID 0004) support, is it tested? Seems that code is different. Maybe in my case I just need to set wave in mixer to hear sound...

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

> Perhaps you should try with BC++
> 5.5, it requires a 32-bit compiler.

Only for registered users but I have bc 5.5 somewhere. The BC 4.0 was win32 - bcc32.exe so not much hope it will helps but I'll try.

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

> If I understand well, your utility only sets mixer volume for analog CD in
> to enable playback without other drivers - you just press play on drive or
> in cd player SW?

Yes, it is exactly what my utility does.

> Does it work also for digital CD in?

I do not know, never tried, but I highly doubt about it.

---
DOS-u-akbar!

> Only for registered users but I have bc 5.5 somewhere. The BC 4.0 was win32
> - bcc32.exe so not much hope it will helps but I'll try.

As far as I recalled Borland C++ 4.0 was only for 16-bit Windows and still a 16-bit compiler only, but I tried with bcc32 from BC++ 5.5 and it seems to work.

---
Glory to God for all things

> Well, I have never tried to compile the SDR drivers. I only used it as a
> inspiration for LiveCD (http://www.laaca.borec.cz/soubory/livecd.zip)
>
> Anyway I wrote an API description too. I don't know how much is it useful
> but it just Wolfgang Hesseler sent to me: (...)

Thanks for the information.

---
Glory to God for all things

> As far as I recalled Borland C++ 4.0 was only for 16-bit Windows and still
> a 16-bit compiler only, but I tried with bcc32 from BC++ 5.5 and it seems
> to work.

Thx, I just tried bc 5.5.1 and it works (but still show some warnings):

Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland
IO.C:
Warning W8002 IO.C 36: Restarting compile using assembly in function outl
Warning W8070 IO.C 59: Function should return a value in function inl
Warning W8070 IO.C 66: Function should return a value in function inw
Warning W8070 IO.C 73: Function should return a value in function inb
Warning W8004 IO.C 359: 'sample' is assigned a value that is never used in function snd_emu10k1_pcm_init_voice
Warning W8065 IO.C 673: Call to function 'snd_emu10k1_init_efx' with no prototype in function snd_emu10k1_init

Hm, so now, how to modify it for audigy 2?

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

Slightly offtopic, however:

Why do you bother with Audigy 2. I thought I have SB Live!

---
DOS-u-akbar!

> Slightly offtopic, however:
>
> Why do you bother with Audigy 2. I thought I have SB Live!

I use it on main PC, mostly under windows. Audigy has better sound (I also replaced opamp on front output and mic preamp to be even slightly better) so why not use it. Under dos it still "works" with sbemu drivers - in my case only adlib and midi.

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

> Hm, so now, how to modify it for audigy 2?

Personally I would look on ALSA's emu10k1 driver, which has the updated I/O register defines for EMU10K2.5.

---
Glory to God for all things

> Personally I would look on ALSA's emu10k1 driver, which has the updated I/O
> register defines for EMU10K2.5.

Yes, under Linux it works with emu10k module without any change from previous run with live...

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

> > The videocard is a VESA VBE 2.0 MagicGraph 128XD 40K SVGA BIOS [1984 kB]
> > I think that I can work in VO:vesa only ... no vidix driver for my card
> > How can I enable svgalib? Here using DOS/win98.. I though svgalib was
> only
> > for linux
>
> If you have my build supporting svgalib's 1.9.25 video drivers, use mplayer
> with -vo svga and edit libvga.cfg to use chipset NEOMAGIC. Good luck!

I found your svgalib version and its working.. but at moment VESA continue being faster than svgalib.

I notice that svgalib version load automatically the Scale filter of mplayer to get correct colorspaces.. and that comsume precious cpu cycles ;/


QV has options for hardware scaler and software scaler...

Its posible enable hardware scaler in Mplayer?

If you use mplayer -x -y for ratio correction you need extra cpu... so its not good option for low CPU users

> I found your svgalib version and its working.. but at moment VESA continue
> being faster than svgalib.

I really doubt that VESA is faster than svgalib's accelerated Neomagic driver. Are you sure that you have a rightly configured libvga.cfg? Even svgalib's VESA driver is as fast as -vo VESA, as I could see on all my systems (and in fact it can't be otherwise).

> I notice that svgalib version load automatically the Scale filter of
> mplayer to get correct colorspaces.. and that comsume precious cpu cycles
> ;/

I don't understand at all what you mean.

> QV has options for hardware scaler and software scaler...
> Its posible enable hardware scaler in Mplayer?

The vidix video output supports hardware scaling. Neither -vo vesa, nor -vo svga are real solutions for mplayer. I added svgalib support because it provides hardware accelerated blitting for some older video cards, so it should be faster than -vo vesa with those cards.

---
Glory to God for all things

> > I found your svgalib version and its working.. but at moment VESA
> continue
> > being faster than svgalib.
>
> I really doubt that VESA is faster than svgalib's accelerated Neomagic
> driver. Are you sure that you have a rightly configured libvga.cfg? Even
> svgalib's VESA driver is as fast as -vo VESA, as I could see on all my
> systems (and in fact it can't be otherwise).
Yes its configured OK.. when Mplayer loads it shows that is using vgalib neomagic driver. I can notice more fps in vesa mode. I did lot of test yesterday/today.. my computer 166mmx is not enough to play certain videos.. but using vesa I can get more fps than using vgalib

the reason is that vgalib version load a scale filter before play the video ,... and Vesa mode not..

> > I notice that svgalib version load automatically the Scale filter of
> > mplayer to get correct colorspaces.. and that comsume precious cpu
> cycles
> > ;/
>
> I don't understand at all what you mean.
>
in the console of mplayer the info says that vf scale filter is loaded to find correct colorspace before play the video and do some colorspace transformation. This filter is not loaded when you use vesa.
(vesa is using always yv12 mode here)


> > QV has options for hardware scaler and software scaler...
> > Its posible enable hardware scaler in Mplayer?
>
> The vidix video output supports hardware scaling. Neither -vo vesa, nor -vo
> svga are real solutions for mplayer. I added svgalib support because it
> provides hardware accelerated blitting for some older video cards, so it
> should be faster than -vo vesa with those cards.

oh I see. A pity that vidix is not available for my neomagic card (mine is a rare card)
Well I think that Ill continue using QV for avi and flv/wmv etc with your mplayer vesa.
Thanks for all the help and support pal ;)

> Yes its configured OK.. when Mplayer loads it shows that is using vgalib
> neomagic driver. I can notice more fps in vesa mode. I did lot of test
> yesterday/today.. my computer 166mmx is not enough to play certain videos..
> but using vesa I can get more fps than using vgalib
>
> the reason is that vgalib version load a scale filter before play the video
> ,... and Vesa mode not..

Svgalib doesn't load any scale filter, make sure you don't mess-up with mplayer's options. It is mplayer which applies scale filters, only if told so or required, and it scales by hardware, if the vo driver supports such scaling, if not, it scales by software.

> > > I notice that svgalib version load automatically the Scale filter of
> > > mplayer to get correct colorspaces.. and that comsume precious cpu
> > cycles
> > > ;/
> >
> > I don't understand at all what you mean.
> >
> in the console of mplayer the info says that vf scale filter is loaded to
> find correct colorspace before play the video and do some colorspace
> transformation. This filter is not loaded when you use vesa.
> (vesa is using always yv12 mode here)

Let's be clear: the vo vesa driver uses by necessity software color space conversion to RGB for any YUV frame. It can't use any yv12 mode as you say, so what you wrote above is meaningless.

---
Glory to God for all things