Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to index page
Thread view  Board view
Khusraw

E-mail

Bucharest, Romania,
23.01.2012, 18:42
 

New DJGPP Mplayer build from SVN (Announce)

Post reply

What's new:
+ added HDA sound card support in ao wss.
+ added networking support with libwatt (untested).
+ added preliminary and minimal support for external binary codecs. Sometimes it works, but sometimes it crashes. I don't recommend the use of external codecs, mplayer has internal support for most of the codecs you will need.
- removed support for svgalib video drivers.

The binaries are available here, and the source code here.

You may modify the configuration files from "mplayer" subfolder according to your needs and preferences. Please read mplayer's manual before anything else.

---
Glory to God for all things
ron

Homepage E-mail

Australia,
23.01.2012, 21:21

@ Khusraw
 

New DJGPP Mplayer build from SVN

Post reply

> The binaries are available
> here,
Got it. Will test. :)

Ron
ron

Homepage E-mail

Australia,
23.01.2012, 22:39

@ ron
 

New DJGPP Mplayer build from SVN

Post reply

> > The binaries are available
> > here,
>
> Got it. Will test. :)
Cannot get this mplayer to play ANY video.

Starts OK with vid details showing, then:

"DVB Card must be between 1 and 4"

very long pause, then:

"AO_WSS: detected Ultrasound"

then total lockup requiring several Ctrl+C to get out.

I have an SB16 sound card, NOT a Gravis Ultrasound.


With the AO=WSS REM'd out in CONFIG, I get the partial first frame of a vid
and then a total lock-up again.

My system: AMD K6, 600 MHz, 256 MB RAM, Soundblaster 16.

Ron
glennmcc

Homepage E-mail

North Jackson, Ohio (USA),
24.01.2012, 00:24

@ ron
 

New DJGPP Mplayer build from SVN

Post reply

> > > The binaries are available
> > > here,
> >
> > Got it. Will test. :)
>
> Cannot get this mplayer to play ANY video.
>
> Starts OK with vid details showing, then:
>
> "DVB Card must be between 1 and 4"
>
> very long pause, then:
>
> "AO_WSS: detected Ultrasound"
>
> then total lockup requiring several Ctrl+C to get out.
>
> I have an SB16 sound card, NOT a Gravis Ultrasound.
>
>
> With the AO=WSS REM'd out in CONFIG, I get the partial first frame of a vid
>
> and then a total lock-up again.
>
> My system: AMD K6, 600 MHz, 256 MB RAM, Soundblaster 16.
>
> Ron

I get similar problems to Ron's

I was able to play a video without audio via -ao null

But ... it complains that my system is too slow to play the video

I would think that this P4-2.6ghz machine _should_ be fast enough.

Your build from Sep of 2010 works perfectly on this same machine
for both video & audio.

--
glennmcc
ron

Homepage E-mail

Australia,
24.01.2012, 00:46

@ glennmcc
 

New DJGPP Mplayer build from SVN

Post reply

> I was able to play a video without audio via -ao null
Confirmed !

> But ... it complains that my system is too slow to play the video
> I would think that this P4-2.6ghz machine _should_ be fast enough.
No such complaint on my 600 MHz machine. But still no sound.

> Your build from Sep of 2010 works perfectly on this same machine
> for both video & audio.
For me, too.

Ron
Khusraw

E-mail

Bucharest, Romania,
24.01.2012, 09:24
(edited by Khusraw, 24.01.2012, 09:44)

@ glennmcc
 

New DJGPP Mplayer build from SVN

Post reply

> I get similar problems to Ron's
>
> I was able to play a video without audio via -ao null
>
> But ... it complains that my system is too slow to play the video
>
> I would think that this P4-2.6ghz machine _should_ be fast enough.
>
> Your build from Sep of 2010 works perfectly on this same machine
> for both video & audio.
Please see my answer to Ron. How it is possible that you see the system too slow message when the config file has "really-quiet" set? Put a correct config file where it should be, or use the command line options.

---
Glory to God for all things
Khusraw

E-mail

Bucharest, Romania,
24.01.2012, 09:22
(edited by Khusraw, 24.01.2012, 12:39)

@ ron
 

New DJGPP Mplayer build from SVN

Post reply

> Cannot get this mplayer to play ANY video.
>
> Starts OK with vid details showing, then:
>
> "DVB Card must be between 1 and 4"
If it shows the message it means that you don't have any correct config file in the "mplayer" subfolder, and it tries to play using ao mpegpes.

> very long pause, then:
>
> "AO_WSS: detected Ultrasound"
>
> then total lockup requiring several Ctrl+C to get out.
>
> I have an SB16 sound card, NOT a Gravis Ultrasound.
WSS can't detect GUS except if you have ULTRASND environment variable set, as you can see looking at the source code.
For the present remove it before running mplayer (I will add later the option to specify soundcard and volume as ao wss parameters) and put a correct config file in the "mplayer" subfolder. Or if you don't know how/don't want to use a config file, run mplayer with:

mplayer -really-quiet -ao wss -vo vesa -double -zoom -fs -framedrop

---
Glory to God for all things
Doug

E-mail

24.01.2012, 04:58

@ Khusraw
 

New DJGPP Mplayer build from SVN

Post reply

All right! Much appreciated....

My (limited) testing results:

* Video plays (AVI, MPG, MOV, WMV, FLV, WEBM).

* There is sound, but it is *barely* audible... with the speaker's physical volume knob maxed and MPlayer's volume (* key) maxed. (Still promising, as no other build had any!)

From MPlayer:

  Intel_ICH: Intel ICH4 integrated AC97 audio found.
  Intel_ICH: PCI BASE0 at I/O 1C00
  Intel_ICH: PCI BASE1 at I/O 18C0
  AO_WSS: detected Intel ICH4 integrated AC97 audio.

Running on: IBM ThinkCentre M51 (system), Intel P4 2g4hz (cpu), 845 (north), 801DB ICH4 (south), ATI Rage 128 Pro Ultra (video).

- Doug B.
RayeR

Homepage

CZ,
24.01.2012, 10:26

@ Doug
 

New DJGPP Mplayer build from SVN

Post reply

> * There is sound, but it is *barely* audible... with the speaker's physical
> volume knob maxed and MPlayer's volume (* key) maxed. (Still promising, as
> no other build had any!)

Funny, on my HDA (intel ICH7+ALC888) the MPlayer and Judas player are very loud. I had to add option -volume 15 to decrease at normal level. I'm not sure it this options touch mixer (wave or master volume) or does it software volume control (that is losing low bits)?

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

E-mail

Bucharest, Romania,
24.01.2012, 13:54

@ Khusraw
 

Mplayer with fixed ao wss problems

Post reply

You may download it from here. I hope that the ao wss problems which some of you had are fixed. Now ao wss may take the device id and the hardware volume as parameters. Please read "README.WSS" for usage. The volume setting accuracy depends on the number of steps your codec's amplifiers have, a value of 0 means minimum volume and a value of 31 means maximum volume.

---
Glory to God for all things
ron

Homepage E-mail

Australia,
24.01.2012, 22:41

@ Khusraw
 

Mplayer with fixed ao wss problems

Post reply

> You may download it from
> here. I hope that the
> ao wss problems which some of you had are fixed.
Yep ! That fixed it, and sound works just fine.

Ron
ron

Homepage E-mail

Australia,
25.01.2012, 03:51

@ ron
 

Mplayer with fixed ao wss problems

Post reply

> > You may download it from
> > here. I hope that
> the
> > ao wss problems which some of you had are fixed.
>
> Yep ! That fixed it, and sound works just fine.
I have also successfully used it to stream from a remote site, getting full screen with sound (and a few necessary framedrops) running in Arachne.

I am impressed !

Ron
ron

Homepage E-mail

Australia,
25.01.2012, 21:49

@ ron
 

Mplayer with fixed ao wss problems

Post reply

> I have also successfully used it to stream from a remote site, getting
> full screen with sound (and a few necessary framedrops) running in
> Arachne.
And I confirm that -dumpstream also works OK.

Ron
glennmcc

Homepage E-mail

North Jackson, Ohio (USA),
25.01.2012, 01:34
(edited by glennmcc, 25.01.2012, 02:41)

@ Khusraw
 

Mplayer with fixed ao wss problems

Post reply

> You may download it from
> here. I hope that the
> ao wss problems which some of you had are fixed. Now ao wss may take the
> device id and the hardware volume as parameters. Please read "README.WSS"
> for usage. The volume setting accuracy depends on the number of steps your
> codec's amplifiers have, a value of 0 means minimum volume and a value of
> 31 means maximum volume.
Same problem here with the 'fixed' version as with the last.

Can only get it to play silent video via -ao null

Without -ao null .... blank black screen.... no sound

The sound card I have is a PCI CMI8738

Your build of mplayer.exe from Sep of 2010 plays audio perfectly
thru this card with no 'tweaking' of the -ao settings needed.

From that Sep 2010 build with no config file in-place
(everything autodetected or via compiled-in defaults)

Command line.... mplayer.exe g:\graphics\mpg\courtne1.mpg

Creating config file: C:/!/MPLAYER_/mplayer/config
MPlayer SVN-r31981-snapshot-`gcc (C) 2000-2010 MPlayer Team

Playing g:\graphics\mpg\courtne1.mpg.
MPEG-PS file format detected.
VIDEO: MPEG1 384x288 (aspect 1) 25.000 fps 0.0 kbps ( 0.0 kbyte/s)
svgalib: Assuming low end SVGA/8514 monitor (35.5 KHz).
Using nvidia driver, 16384KB, Type: RivaTNT (NV 6).
svgalib 1.9.25
==========================================================================
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
Selected video codec: [ffmpeg1] vfm: ffmpeg (FFmpeg MPEG-1)
==========================================================================
==========================================================================
Opening audio decoder: [mp3lib] MPEG layer-2, layer-3
AUDIO: 22050 Hz, 2 ch, s16le, 64.0 kbit/9.07% (ratio: 8000->88200)
Selected audio codec: [mp3] afm: mp3lib (mp3lib MPEG layer-2, layer-3)
==========================================================================
AO_WSS: detected Sound Blaster Pro for WDM SBPro emulation
AO: [wss] 21739Hz 2ch s16le (2 bytes per sample)
Starting playback...
Could not find matching colorspace - retrying with -vf scale...
Opening video filter: [scale]
Movie-Aspect is 1.33:1 - prescaling to correct movie aspect.
[swscaler @ 932270]using unscaled yuv420p -> bgra special converter
VO: [svga] 384x288 => 384x288 BGRA
[VO_SVGA] Vid_mode: 59, 400x300 32bpp.
[VO_SVGA] Video mode is linear and memcpy could be used for image transfer.
[VO_SVGA] Video mode has 16 page(s).
[VO_SVGA] Centering image. Starting at (0,6)
New_Face failed. Maybe the font path is wrong.
Please supply the text font file (~/.mplayer/subfont.ttf).
subtitle font: load_sub_face failed.
New_Face failed. Maybe the font path is wrong.
Please supply the text font file (~/.mplayer/subfont.ttf).
subtitle font: load_sub_face failed.
A: 0.0 V: 0.5 A-V: -0.492 ct: 0.000 2/ 2 ??% ??% ??,?% 0 0
A: 0.0 V: 0.5 A-V: -0.516 ct: 0.000 2/ 2 ??% ??% ??,?% 0 0

Exiting... (Quit)

____________

And now from today's fixed build

Creating config file: C:/MPLAYERK//mplayer/config
MPlayer Khusraw-SVN-r34587 (C) 2000-2012 MPlayer Team

Playing g:\graphics\mpg\courtne1.mpg.
libavformat version 53.24.2 (internal)
MPEG-PS file format detected.
VIDEO: MPEG1 384x288 (aspect 1) 25.000 fps 0.0 kbps ( 0.0 kbyte/s)
Load subtitles in g:\graphics\mpg\
==========================================================================
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
libavcodec version 53.42.4 (internal)
Selected video codec: [ffmpeg1] vfm: ffmpeg (FFmpeg MPEG-1)
==========================================================================
==========================================================================
Requested audio codec family [mpg123] (afm=mpg123) not available.
Enable it at compilation.
Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders
AUDIO: 22050 Hz, 2 ch, floatle, 64.0 kbit/4.54% (ratio: 8000->176400)
Selected audio codec: [ffmp2float] afm: ffmpeg (FFmpeg MPEG layer-1 and layer-2 audio)
==========================================================================
DVB card number must be between 1 and 4
AO_WSS: detected Sound Blaster Pro.
AO: [wss] 21739Hz 2ch s16le (2 bytes per sample)
Starting playback...
[mp2float @ 439e70]Header missing
Movie-Aspect is 1.33:1 - prescaling to correct movie aspect.
VO: [vesa] 384x288 => 384x288 Planar YV12
[VO_VESA] Found VESA VBE BIOS Version 3.0 Revision: 305.
[VO_VESA] Video memory: 16384 Kb.
[VO_VESA] VESA Capabilities: 8-bit DAC, VGA CRTC, normal RAMDAC, no stereoscopic, no stereo.
[VO_VESA] !!! OEM info will be printed below !!!
[VO_VESA] You should see 5 OEM related lines below; If not, you've broken vm86.
[VO_VESA] OEM info: NVidia.
[VO_VESA] OEM Revision: 305.
[VO_VESA] OEM vendor: NVidia Corporation.
[VO_VESA] OEM Product Name: Riva TNT.
[VO_VESA] OEM Product Rev: Chip Rev B1.
[VO_VESA] Hint: For working TV-Out you should have plugged in the TV connector
[VO_VESA] before booting since VESA BIOS initializes itself only during POST.
[VO_VESA] Using VESA mode (29) = 13d [640x400@16]
[swscaler @ 339150]using unscaled yuv420p -> rgb565le special converter
[VO_VESA] Using DGA (physical resources: FC000000h, 01000000h)[VO_VESA]
You have to specify the capabilities of the monitor. Not changing refresh rate.
New_Face failed. Maybe the font path is wrong.
Please supply the text font file (~/.mplayer/subfont.ttf).
subtitle font: load_sub_face failed.
New_Face failed. Maybe the font path is wrong.
Please supply the text font file (~/.mplayer/subfont.ttf).
subtitle font: load_sub_face failed.

A: 0.3 V: 0.5 A-V: -0.226 ct: 0.000 2/ 2 ??% ??% ??,?% 0 0
A: 0.3 V: 0.5 A-V: -0.266 ct: 0.000 3/ 3 ??% ??% ??,?% 0 0

Exiting... (Quit)
___________________
Khusraw

E-mail

Bucharest, Romania,
25.01.2012, 09:03

@ glennmcc
 

Mplayer with fixed ao wss problems

Post reply

> Same problem here with the 'fixed' version as with the last.
>
> Can only get it to play silent video via -ao null
It still doesn't find the config file. Try better to set MPLAYER_HOME or HOME environment variables pointing to mplayer's full path.

---
Glory to God for all things
glennmcc

Homepage E-mail

North Jackson, Ohio (USA),
25.01.2012, 17:32

@ Khusraw
 

Mplayer with fixed ao wss problems

Post reply

> > Same problem here with the 'fixed' version as with the last.
> >
> > Can only get it to play silent video via -ao null
>
> It still doesn't find the config file. Try better to set MPLAYER_HOME or
> HOME environment variables pointing to mplayer's full path.

Those posted test results were without a config file.

The same thing happens with the included config file which is being found
and which had the setting for autodetect of dev=-1

I then tried all possible dev settings.

The only setting that allowed anything to happen other than a blank black
screen & no audio was dev=0 which finally resulted in the video playing
but of-course without audio.

This new build simply does not work with my PCI CMI8783 sound card.

Since your build from Sep of 2010 works perfectly with this card...
something has apparently gotten broken in the AO code
Khusraw

E-mail

Bucharest, Romania,
25.01.2012, 21:40
(edited by Khusraw, 25.01.2012, 21:54)

@ glennmcc
 

Mplayer with fixed ao wss problems

Post reply

> This new build simply does not work with my PCI CMI8783 sound card.
>
> Since your build from Sep of 2010 works perfectly with this card...
> something has apparently gotten broken in the AO code
I assure you that there is nothing broken in the ao code. Try to read all the available documentation. Run a simple audio file with mplayer -ao:wss:dev=15 file.ext.

---
Glory to God for all things
glennmcc

Homepage E-mail

North Jackson, Ohio (USA),
26.01.2012, 02:19

@ Khusraw
 

Mplayer with fixed ao wss problems

Post reply

> > This new build simply does not work with my PCI CMI8783 sound card.
> >
> > Since your build from Sep of 2010 works perfectly with this card...
> > something has apparently gotten broken in the AO code
>
> I assure you that there is nothing broken in the ao code. Try to read all
> the available documentation. Run a simple audio file with mplayer
> -ao:wss:dev=15 file.ext.
Already tried that to no avail :(
glennmcc

Homepage E-mail

North Jackson, Ohio (USA),
26.01.2012, 03:03
(edited by glennmcc, 26.01.2012, 04:56)

@ glennmcc
 

Mplayer with fixed ao wss problems

Post reply

> > > This new build simply does not work with my PCI CMI8783 sound card.
> > >
> > > Since your build from Sep of 2010 works perfectly with this card...
> > > something has apparently gotten broken in the AO code
> >
> > I assure you that there is nothing broken in the ao code. Try to read
> all
> > the available documentation. Run a simple audio file with mplayer
> > -ao:wss:dev=15 file.ext.
>
> Already tried that to no avail :(
Ah ha....
finally some very limited success with the test build in Mpac97fix.7z

mplayer -ao wss:dev=-1 filename.wav

The 1st 1/2 second of audio plays over and over again in a loop
never stopping till 'q' or Ctrl+C are pressed.

mplayer -ao wss:dev=-1 filename.mpg

No video showing on screen but... same as above...
the 1st 1/2 second of audio plays over and over again in a loop
never stopping till 'q' or Ctrl+C are pressed.

Same method required as with the 1st 2 builds
to get the video to play correctly but without audio

mplayer -ao wss:dev=0 filename.mpg

or

mplayer -ao null filename.mpg


----

But, as stated before, your build of mplayer from Sep 2010 works pefectly
on this same machine for both video & audio via simply....

mplayer filename.mpg
RayeR

Homepage

CZ,
26.01.2012, 10:31

@ glennmcc
 

Mplayer with fixed ao wss problems

Post reply

It looks like some IRQ/DMA problem when sound buffer doesn't update and loop endlessly...

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

E-mail

Bucharest, Romania,
26.01.2012, 10:43

@ glennmcc
 

Mplayer with fixed ao wss problems

Post reply

Do you use it in Windows98? The only change I made to ao wss comparing to my 2010 build is that I removed Windows SBPRO emulation from autodetection. If you use it in Windows98, you should run it with -ao wss:dev=9.

---
Glory to God for all things
glennmcc

Homepage E-mail

North Jackson, Ohio (USA),
26.01.2012, 23:32
(edited by glennmcc, 27.01.2012, 00:34)

@ Khusraw
 

Mplayer with fixed ao wss problems

Post reply

> Do you use it in Windows98? The only change I made to ao wss comparing to
> my 2010 build is that I removed Windows SBPRO emulation from autodetection.
> If you use it in Windows98, you should run it with -ao wss:dev=9.

No windows of any kind here... not even MSDOS from any version of windows.

I'm booting to Caldera OpenDos v7.01
and using QEMM v9.0 for memory managment.

Just in-case... I'll try dev=9

BRB

____

No good with the 1st build.... no video... no audio.... just sits there
doing nothing till I press Ctrl+C

Will now try the latest test build from mpac97fix.7z

BRB
____

OK... a small amount of additional progress.

The audio now plays a little bit more (about 5sec), and then loops for a
second, and then continues to play the audio.

But.... the video is 'frozen' at frame number 1
and does not progress past that point.

in config ... ao=wss:dev=9

command line..... mplayer g:\graphics\mpg\courtne1.mpg


Will now try a WAV file

BRB

___

Just now played a 48sec WAV with no problems at-all.

Will now try some different video/audio files

___

BRB

FANTASTIC !!!

100% success !!!

Fixed the frozen video via....

framedrop = no

_____

Thank you !!!


_________ current enabled settings in config _________

really-quiet=yes
vo=vesa
fs=yes
double=yes
vsync=yes
framedrop = no
zoom=yes
ao=wss:dev=9
_______________________________
Zyzzle

26.01.2012, 23:52

@ glennmcc
 

Mplayer with fixed ao wss problems

Post reply

> OK... a small amount of additional prgress.
>
> The audio now plays a little bit more (about 5sec), and then loops for a
> second, and then continues to play the audio.
>
> But.... the video is 'frozen' at frame number 1
> and does not progress past that point.
Get rid of QEMM and try it with no EMS... I had so many problems with QEMM in the past that I gave it up for good & use regular HIMEM.SYS from DOS 7.1
RayeR

Homepage

CZ,
27.01.2012, 03:06

@ Zyzzle
 

Mplayer with fixed ao wss problems

Post reply

> Get rid of QEMM and try it with no EMS... I had so many problems with QEMM
> in the past that I gave it up for good & use regular HIMEM.SYS from DOS 7.1
Yes, on modern machines is QEMM little bit unstable (buit in old days it was perfect memory manager, used on my 1st 486 15 years ago...) and supports only 256MB XMS. JEMMEX rulez :)

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

Homepage

CZ,
25.01.2012, 03:44

@ Khusraw
 

Mplayer with fixed ao wss problems

Post reply

> Now ao wss may take the device id and the hardware volume as parameters.
> Please read "README.WSS" for usage.
Thanks, the volume control works for me. BTW for sure, dev=-1 means autodetect?

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

E-mail

Bucharest, Romania,
25.01.2012, 09:05

@ RayeR
 

Mplayer with fixed ao wss problems

Post reply

> Thanks, the volume control works for me. BTW for sure, dev=-1 means
> autodetect?
Yes, dev=-1 means autodetect.

---
Glory to God for all things
Doug

E-mail

25.01.2012, 05:59

@ Khusraw
 

Mplayer with fixed ao wss problems

Post reply

> I hope that the ao wss problems which some of you had are fixed.

Tested fixed version, but same issue -- sound barely audible, with speaker volume and MPlayer volume both maxed. Tried it with dev=2:vol=31, dev=3:vol=31, dev=26:vol=31, dev=27:vol=31 -- all the same result.

Just to be sure, i tried playing the test file (.mpg) with MPXPlay -- played fine, normal good volume.

IBM P4 system with Intel 801DB ICH4 AC'97.

- Doug B.
Khusraw

E-mail

Bucharest, Romania,
25.01.2012, 09:07
(edited by Khusraw, 25.01.2012, 10:32)

@ Doug
 

Mplayer with fixed ao wss problems

Post reply

> Tested fixed version, but same issue -- sound barely audible, with speaker
> volume and MPlayer volume both maxed. Tried it with dev=2:vol=31,
> dev=3:vol=31, dev=26:vol=31, dev=27:vol=31 -- all the same result.
>
> Just to be sure, i tried playing the test file (.mpg) with MPXPlay --
> played fine, normal good volume.
>
> IBM P4 system with Intel 801DB ICH4 AC'97.
The AC97 support is not written by me. I will look at it during the next days.

EDIT: BTW, do you use headphones or mono output?

---
Glory to God for all things
Doug

E-mail

25.01.2012, 17:48

@ Khusraw
 

Mplayer with fixed ao wss problems

Post reply

> BTW, do you use headphones or mono output?
Nope. Stereo speakers + subwoofer.

- Doug B.
RayeR

Homepage

CZ,
25.01.2012, 16:05

@ Doug
 

Mplayer with fixed ao wss problems

Post reply

You can try to set sound output to WAV file and then check in wave editor if it is properly modulated (using full dynamic range) to be sure if it's not caused by anything else than soundcard.

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

E-mail

25.01.2012, 17:45

@ RayeR
 

Mplayer with fixed ao wss problems

Post reply

> You can try to set sound output to WAV file and then check in wave editor
> if it is properly modulated (using full dynamic range) to be sure if it's
> not caused by anything else than soundcard.
Ahh, good idea!

Ok, did it: -ao pwm. The resulting WAV file looked and played fine in MPXPlay. So it must be a soundcard/hardware issue.

- Doug B.
RayeR

Homepage

CZ,
25.01.2012, 17:53

@ Doug
 

Mplayer with fixed ao wss problems

Post reply

> Ok, did it: -ao pwm. The resulting WAV file looked and played fine in
> MPXPlay. So it must be a soundcard/hardware issue.

I'm not sure if MPXplay doesn't have some normalizer, rather chech the waveform in GoldWave/CoolEdit/Audacity/etc...

Ou, I missed your second post, problem fixed, congrat.

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

E-mail

Bucharest, Romania,
25.01.2012, 17:12

@ Doug
 

Mplayer with fixed ao wss problems

Post reply

Doug, you may download a new test build from here, which I hope that finally fixes the ICH AC97 volume problem, now it may be set to the loudest possible.

---
Glory to God for all things
Doug

E-mail

25.01.2012, 17:54

@ Khusraw
 

Mplayer with fixed ao wss problems

Post reply

> Doug, you may download a new test build from
> here, which I hope
> that finally fixes the ICH AC97 volume problem, now it may be set to the
> loudest possible.
It works! And very loudly! :-)

Last night, before i downloaded this newest "fixed" build, i actually found a kludgey "solution" for your previous MPlayer "fix" -- it might be of interest, so i'm posting it momentarily.

Thanks for *all* your work!

- Doug B.
Doug

E-mail

25.01.2012, 18:06

@ Doug
 

Mplayer with fixed ao wss problems - my "kludgy" solution

Post reply

Please note: This post refers to Khusraw's first "fix"... not the most-recent one in the post immediately above.

Ok, i found a "kludgy" solution. The issue seems similar to those i had in the recent "SOUND support in DOS | Piotr | HDA" thread.

I got the (first) MPlayer fix to play sound by independently enabling audio using ICHINIT.COM (not ICHINIT.EXE -- please see my "important note" below) and then running MPlayer with*out* ICH initialization:

mplayer -ao wss:dev=27 [filename]

27 was the only dev= value that worked. All others (including dev=26) disabled sound, even if the sound was previously working. And using dev=27 after that did nothing. The only way to get sound back was to run ICHINIT.COM again, then use dev=27 with MPlayer.

Also, the vol= parameter had no effect whatsoever -- whether maxed (vol=31) or mined (vol=0), the audio level was the same. Volume was only dependent on two ICHINIT.COM switches (/mo:#, /wo:#). In particular, setting /wo:1 gave similar results to my previous reporting (sound barely audible).

But i'm happy -- i can initialize audio using ICHINIT.COM in AUTOEXEC.BAT and set ao=wss:dev=27 in MPlayer's CONFIG file.

Important note: The ICHINIT.COM i'm referring to is the .ASM-source version from the Judas Player site. The ICHINIT.EXE C-source version does *not* initialize my system correctly! (This bug/regression was reported near the end of the previous "SOUND support in DOS | Piotr | HDA" thread by the Judas/ICHInit author.)

Dex's AC97CD.COM / TEST.COM programs also initialize my system audio properly... and even more loudly than using ICHINIT /MO:31 /WO:31! Dex kindly released the FASM source for the initialization-only code in the "SOUND support in DOS | Piotr | HDA" thread.

The ICHINIT.COM and asm source can be found at the bottom of this page in the .ZIP file:

http://www.piotrkn22.republika.pl/judas/index.html

Computer: IBM, P4, i801DB ICH4.

- Doug B.
Zyzzle

26.01.2012, 04:52

@ Khusraw
 

New DJGPP Mplayer build from SVN

Post reply

WOW! It is looking like a good year for DOS. Now, in 2012 we are able to finally play our videos with the "modern" Intel HDA sound in all its glory! Many thanks to you and the fine folks of this forum for making the synthesis happen.

TESTED! It works well on my little Acer Aspire one netbook (Intel 945GCM onboard video and Intel HDA audio). The caveat was I had to get around the pixel aspect problem of the stretching which occurs. All 4x3 content displays streched in VESA modes, which are 4:3 like 640x480, and 800x600. I believe this problem will also occur on all fixed-pixel 16:10 LCD monitors (which these days is VIRTUALLY all LCD monitors sold). Unless you have native 1:1 display drivers for DOS for your video card. On my netbook, only 640x480 and 800x600 are available VBE 2.0 modes). The native resolution of the display is 1024x600 pixels.

Using these options put the 4x3 material in proper aspect ratio:

Mplayer -vo vesa -monitorpixelaspect 1.200 -zoom -fs -x 800 -y 600 -really-quiet

Did I calculate the monitorpixelaspect ratio correctly? I used this (16/10) / (4/3) to get 1.20. Or, have I misunderstood that option and should it just be (1024/600) / (800/600) = 1.280? Yes, I did RTFM!!

Audio works very well. Occasionally it would get stuck and / or out of sync when FF or REW videos, but overall, it is exceptional.

Insurmountable problems remain: The DOS 2 GB limit! (or is this version 'patched' to allow up to 4 GB - 1 file sizes?)

One REQUEST: Is it possible to provide a binary WITHOUT networking or support for external codecs? These options add to bloat & I feel very few will use them. It would be very much appreciated!
Khusraw

E-mail

Bucharest, Romania,
26.01.2012, 09:29

@ Zyzzle
 

New DJGPP Mplayer build from SVN

Post reply

> Insurmountable problems remain: The DOS 2 GB limit! (or is this version
> 'patched' to allow up to 4 GB - 1 file sizes?)
When DJGPP headers will define off_t as off64_t and fseek as fseeko64 in case _FILE_OFFSET_BITS=64 or _LARGEFILE_SOURCE are defined, it will work. Until then, no.

> One REQUEST: Is it possible to provide a binary WITHOUT networking or
> support for external codecs? These options add to bloat & I feel very few
> will use them. It would be very much appreciated!
The source code is provided and you can build whatever custom mplayer you want by simply editing the config.h file and typing make.

---
Glory to God for all things
Zyzzle

26.01.2012, 22:13

@ Khusraw
 

New DJGPP Mplayer build from SVN

Post reply

> When DJGPP headers will define off_t as off64_t and fseek as fseeko64 in
> case _FILE_OFFSET_BITS=64 or _LARGEFILE_SOURCE are defined, it will work.
> Until then, no.

yea, I know it's a DJGPP limit... eonder if doing this alone would fix it, as the DOS I/O code also probably needs to be patched for 64-bit fileseeks as well.


> The source code is provided and you can build whatever custom mplayer you
> want by simply editing the config.h file and typing make.
If it's really that easy, I'll have a go at it. What compiler did you use or recommend? Can you cross-compile from within (*evil*) Windows?

MORE TESTING completed... Works well in my other two boxes, one with Intel HDA7 Audio, onboard Intel graphics, and c2d E8400. My newest box, with Intel HDA10 and 2600k processor, with onchip Intel graphics will work, but I can't get sound playing in that one. That one screams at 5.5 Ghz stable, so it would be possible to play 1080p 24 fps material in DOS alone, but perhaps my variant of Intel HDA is too new.
Khusraw

E-mail

Bucharest, Romania,
26.01.2012, 23:14

@ Zyzzle
 

New DJGPP Mplayer build from SVN

Post reply

> yea, I know it's a DJGPP limit... eonder if doing this alone would fix it,
> as the DOS I/O code also probably needs to be patched for 64-bit fileseeks
> as well.
DJGPP has both off64_t and fseeko64.

> If it's really that easy, I'll have a go at it. What compiler did you use
> or recommend? Can you cross-compile from within (*evil*) Windows?
I use DJGPP 2.04 with he latest ports of GNU packages, in Windows XP. Anyway, removing support for the external binary codecs may be an option for my final build in this "season", as it still doesn't work as it should. But this won't mean too much re: the bloat.

> MORE TESTING completed... Works well in my other two boxes, one with Intel
> HDA7 Audio, onboard Intel graphics, and c2d E8400. My newest box, with
> Intel HDA10 and 2600k processor, with onchip Intel graphics will work, but
> I can't get sound playing in that one. That one screams at 5.5 Ghz stable,
> so it would be possible to play 1080p 24 fps material in DOS alone, but
> perhaps my variant of Intel HDA is too new.
It doesn't detect your card, or it detects it but there is no sound?

---
Glory to God for all things
RayeR

Homepage

CZ,
27.01.2012, 03:12

@ Zyzzle
 

New DJGPP Mplayer build from SVN

Post reply

> MORE TESTING completed... Works well in my other two boxes, one with Intel
> HDA7 Audio, onboard Intel graphics, and c2d E8400. My newest box, with
> Intel HDA10 and 2600k processor, with onchip Intel graphics will work, but
> I can't get sound playing in that one. That one screams at 5.5 Ghz stable,
> so it would be possible to play 1080p 24 fps material in DOS alone, but
> perhaps my variant of Intel HDA is too new.
What chipset? It should recognize intel 5, 6, 7 series. I tested succ. on H57.

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

E-mail

Bucharest, Romania,
27.01.2012, 10:25

@ Zyzzle
 

New DJGPP Mplayer build from SVN

Post reply

Can you provide your ICH10 HDA vendor and device id?

---
Glory to God for all things
Zyzzle

28.01.2012, 01:54

@ Khusraw
 

New DJGPP Mplayer build from SVN

Post reply

> Can you provide your ICH10 HDA vendor and device id?
I was mistaken, the system in which I get no Audio has ICH7 sound. These are the specifics:

IDH DeviceID = 27D8h = Intel 82801GB ICH7 Audio (Azalia?)

Intel G41 Chipset

The symptoms are the same as others had. The sound is initialized OK, HDA audio detected, and it seems to play OK, but no sound is output.

Mplayer reports: HD_WSS: detected N10 (ICH7), and a bunch of ports (4 ports dectected, etc).

The same system works well, with volume in MPXPLAY.

Tried various options like -ao wss:dev=28:vol=32 and -ao wss:dev=29 and -ao wss:dev=-1.

The volume output is definitely a LINE-OUT (ie, standard green 1/8 stereo mini-dsub plug)

I tried both 'fixed' binaries without success...

Also, for my I7 2600k system, I got it working WONDERFULLY by using your *first* fix binary (it wouldn't work with the 2nd fix) and the option -ao wss:dev=28:vol=32.
Khusraw

E-mail

Bucharest, Romania,
28.01.2012, 09:23

@ Zyzzle
 

New DJGPP Mplayer build from SVN

Post reply

> The symptoms are the same as others had. The sound is initialized OK, HDA
> audio detected, and it seems to play OK, but no sound is output.
>
> Mplayer reports: HD_WSS: detected N10 (ICH7), and a bunch of ports (4 ports
> dectected, etc).
> The same system works well, with volume in MPXPLAY.
>
> Tried various options like -ao wss:dev=28:vol=32 and -ao wss:dev=29 and -ao
> wss:dev=-1.
>
> The volume output is definitely a LINE-OUT (ie, standard green 1/8 stereo
> mini-dsub plug)
The max volume is 31 (any value greater will be reduced to 31). Also, HDA doesn't use ports, but memory mapped registers. Can you post the full ao wss message, like Deniska did?

> I tried both 'fixed' binaries without success...
> Also, for my I7 2600k system, I got it working WONDERFULLY by using your
> *first* fix binary (it wouldn't work with the 2nd fix) and the option -ao
> wss:dev=28:vol=32.
The second fix concerns only the ICH AC97 volume, I can't understand how it works with the first fix but not with the second, as long as there is no change in the HDA code.

---
Glory to God for all things
Zyzzle

28.01.2012, 13:51

@ Khusraw
 

New DJGPP Mplayer build from SVN

Post reply

> Can you post the full ao wss message,
Yes, of course:

MPlayer Khusraw-SVN-r34600 (C) 2000-2012 MPlayer Team

Playing a.wav.
libavformat version 53.24.2 (internal)
Audio only file format detected.
Load subtitles in ./
==========================================================================
Opening audio decoder: [pcm] Uncompressed PCM audio decoder
AUDIO: 44100 Hz, 2 ch, s16le, 1411.2 kbit/100.00% (ratio: 176400->176400)
Selected audio codec: [pcm] afm: pcm (Uncompressed PCM)
==========================================================================
HDA: N10 (ICH7 Family) HD Audio Controller found.
HDA: i/o base found at FE7F8000.
HDA: i/o base mapped to FE7F8000, selector 00C4.
HDA: reset was succesful, codec mask: 0006, osd base 0100.
HDA: codec found, address 0001, vendor id 8086, device id 2803.
HDA: starting node id 0001, total number of nodes 1.
HDA: node id 0001 supports audio functions.
HDA: starting function/widget id 0002, total number of functions/widgets 2.
HDA: parsing node id 0002.
HDA: parsing node id 0003.
AO_WSS: detected N10 (ICH7 Family) HD Audio Controller.
AO: [wss] 48000Hz 2ch s16le (2 bytes per sample)
Video: no video
Starting playback...
-----------------------------------------------------------------------

Seems like it could be trying to initialize a nonexistant 'node id'


Also, as suggested, I tried -vo vesa:nodga on my i7 system to disable Linear Frame Buffer, but get only a black screen, no video. However, MPLAYER does not freeze, and can be exited gracefully. Any other ideas?

Thanks for all your prompt feedback so far, it has been helpful.
RayeR

Homepage

CZ,
28.01.2012, 14:46

@ Zyzzle
 

New DJGPP Mplayer build from SVN

Post reply

Hm, this is very short log, it must stopped iregullary.
What codec you have beside ICH7? Mine is Realtek ALC888. This is also proof for me that HDA is not fully standardized and even with the same core the codec chips does matter...

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

E-mail

Bucharest, Romania,
28.01.2012, 14:47
(edited by Khusraw, 28.01.2012, 15:22)

@ Zyzzle
 

New DJGPP Mplayer build from SVN

Post reply

> Seems like it could be trying to initialize a nonexistant 'node id'
No, it chooses the wrong codec. It is a bug in libwss, which will be fixed in my final build.

> Also, as suggested, I tried -vo vesa:nodga on my i7 system to disable
> Linear Frame Buffer, but get only a black screen, no video. However,
> MPLAYER does not freeze, and can be exited gracefully. Any other ideas?
This will be fixed in my final build. Until then you may use NOLFB from
http://www.sierrahelp.com/Utilities/DisplayUtilities/NOLFB.html.

---
Glory to God for all things
Zyzzle

29.01.2012, 04:40

@ Khusraw
 

New DJGPP Mplayer build from SVN

Post reply

> > Seems like it could be trying to initialize a nonexistant 'node id'
>
> No, it chooses the wrong codec. It is a bug in libwss, which will be fixed
> in my final build.
> er f
Ah, now I know I'm not insane, as I tried every which option to make it work!

Of couse I have NOLFB by Ken Silverman, for years, but I forgot about it! Thanks for the reminder. Will try it.

Glad to see -vo vesa:nodga will be fixed eventually, too.

@RayeR

Yes, I had two systems based on IDH7, one works one doesn't, they have different chipsets...

RE: enabling LFB writecombining on i5/ i7, your post on the other site is exactly what I was referring to. I referenced in my search in finding a way to enable LFB WC on i7 in DOS... i thought you may have found a solution by now. Sad that so few DOS users are left. This MPLAYER build is exactly the type of program which eill utilize ALL the CPU power in the latest SandyBridge processors... Except for pthreads, which I do not even know if it is possible to utilize the extra CPU cores with DOS.
RayeR

Homepage

CZ,
30.01.2012, 15:03
(edited by RayeR, 31.01.2012, 02:39)

@ Zyzzle
 

MTRR mystery

Post reply

> @RayeR
> >
> RE: enabling LFB writecombining on i5/ i7, your post on the other site is
> exactly what I was referring to. I referenced in my search in finding a way
> to enable LFB WC on i7 in DOS... i thought you may have found a solution by
> now. Sad that so few DOS users are left. This MPLAYER build is exactly the
> type of program which eill utilize ALL the CPU power in the latest
> SandyBridge processors...

Damn! Yesterday I tried my VESATEST under pure DOS again and suddenly I found that WC for LFB stopped working! First I though this was caused by last changes to my MTRR code but when I tried older versions that was surely working but now not. Now I'm getting only abou 160MB/s instead of 2700MB/s. Under Win98 it still works. I tried CMOS reset, BIOS reflash and still don't works! Getting headache of it... I was trying to remember what else I changed on my HW and few months ago I was upgrading RAM from 2GB to 4GB. When I come at home I'll try pull one DIMM out.
Maybe there rise a problem when LFB on VGA overlaps system memory and some additional process is needed. My i5 machine at work has 8GB in 2 modules so I cannot test it only with 2GB... But there must be a way how Win98 did it. Or maybe I'm completly wrong and it's caused by something else...

> Except for pthreads, which I do not even know if
> it is possible to utilize the extra CPU cores with DOS.
This would require to write a low-level APIC code that starts other CPU cores. Firts it's needed to acquire APIC IDs of all cores and then send them some enable signal. They start to execute prepared code from given address.

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

Homepage

CZ,
31.01.2012, 02:38
(edited by RayeR, 31.01.2012, 02:59)

@ RayeR
 

MTRR mystery

Post reply

> When I come at home I'll try pull one DIMM out.
Yes, I was right! I pulled 1 DIMM out and got back my VESA hyper speed. But why? I did some comparison. First here's output of Japhet's memstat.
for 2GB:

Int 15h, ah=88h, extended memory: 0 kB
Int 15h, ax=E801h:
ext. memory below 16 MB: 15360 (0x3c00) KB
ext. memory above 16 MB: 32494 64 KB blocks = 2030 MB [1000000-7fedffff]
Int 15h, eax=E820h:
addr 000000000, size 00009f800, type 1 (available)
addr 0000f0000, size 000010000, type 2 (reserved)
addr 0fec00000, size 001400000, type 2 (reserved)
addr 0f0000000, size 004000000, type 2 (reserved)
addr 00009f800, size 000000800, type 2 (reserved)
addr 07fef0000, size 000010000, type 2 (reserved)
addr 000100000, size 07fde0000, type 1 (available)
addr 07fee3000, size 00000d000, type 3 (ACPI)

for 4GB:

Int 15h, ah=88h, extended memory: 0 kB
Int 15h, ax=E801h:
ext. memory below 16 MB: 15360 (0x3c00) KB
ext. memory above 16 MB: 57070 64 KB blocks = 3566 MB [1000000-dfedffff]
Int 15h, eax=E820h:
addr 000000000, size 00009f800, type 1 (available)
addr 0000f0000, size 000010000, type 2 (reserved)
addr 0fec00000, size 001400000, type 2 (reserved)
addr 0f0000000, size 004000000, type 2 (reserved)
addr 00009f800, size 000000800, type 2 (reserved)
addr 0dfef0000, size 000010000, type 2 (reserved)
addr 000100000, size 0dfde0000, type 1 (available)
addr 0dfee3000, size 00000d000, type 3 (ACPI)
addr 0dfee0000, size 000003000, type 4 (ACPI)

Then I checked how MTRRs are set with 2GB.
before:

VESA 3.0 NVIDIA [262144 kB]
LFB address: E0000000h
MTRR #0 = 000000000, 06; 080000000, 1
MTRR #1 = 07FF00000, 00; 0FFF00000, 1
MTRR #2 = 000000000, 00; 000000000, 0
MTRR #3 = 000000000, 00; 000000000, 0
MTRR #4 = 000000000, 00; 000000000, 0
MTRR #5 = 000000000, 00; 000000000, 0
MTRR #6 = 000000000, 00; 000000000, 0
MTRR #7 = 000000000, 00; 000000000, 0
MTRR area E0000000-EFFFFFFFh was set to mode: WC

after:

VESA 3.0 NVIDIA [262144 kB]
LFB address: E0000000h
MTRR #0 = 000000000, 06; 080000000, 1
MTRR #1 = 07FF00000, 00; 0FFF00000, 1
MTRR #2 = 0E0000000, 01; 0F0000000, 1
MTRR area E0000000-EFFFFFFFh was set to mode: WC

And now with 4GB.
before:

VESA 3.0 NVIDIA [262144 kB]
LFB address: E0000000h
MTRR #0 = 000000000, 06; 000000000, used
MTRR #1 = 0E0000000, 00; 0E0000000, used
MTRR #2 = 000000000, 06; 0E0000000, used
MTRR #3 = 0DFF00000, 00; 0FFF00000, used
MTRR #4 = 000000000, 00; 000000000, unused
MTRR #5 = 000000000, 00; 000000000, unused
MTRR #6 = 000000000, 00; 000000000, unused
MTRR #7 = 000000000, 00; 000000000, unused
MTRR area E0000000-EFFFFFFFh was set to mode: WC

after:

VESA 3.0 NVIDIA [262144 kB]
LFB address: E0000000h
MTRR #0 = 000000000, 06; 000000000, used
MTRR #1 = 0E0000000, 01; 0F0000000, used
MTRR #2 = 000000000, 06; 0E0000000, used
MTRR #3 = 0DFF00000, 00; 0FFF00000, used
MTRR #4 = 000000000, 00; 000000000, unused
MTRR #5 = 000000000, 00; 000000000, unused
MTRR #6 = 000000000, 00; 000000000, unused
MTRR #7 = 000000000, 00; 000000000, unused
MTRR area E0000000-EFFFFFFFh was set to mode: WC

I also tested Windows NT 4.0 with VBEMP driver and they was not affected (run fast as usual). So I dumped MTRRs with my CPUID utility and hardcoded to MTRRLFBE:

This is how WinNT 4.0 + VBEMP set MTRRs:

MTRR RAW values
MSR [00000200h] = 0000000000000006h MSR [00000201h] = 0000000F80000800h
MSR [00000202h] = 0000000080000006h MSR [00000203h] = 0000000FC0000800h
MSR [00000204h] = 00000000C0000006h MSR [00000205h] = 0000000FE0000800h
MSR [00000206h] = 00000000DFF00000h MSR [00000207h] = 0000000FFFF00800h
MSR [00000208h] = 00000000E0000001h MSR [00000209h] = 0000000FF0000800h
MSR [0000020Ah] = 00000000F0000006h MSR [0000020Bh] = 0000000FF0000800h
MSR [0000020Ch] = 0000000100000006h MSR [0000020Dh] = 0000000FE0000800h
MSR [0000020Eh] = 0000000000000000h MSR [0000020Fh] = 0000000000000000h

MTRR parsed values
VESA 3.0 NVIDIA [262144 kB]
LFB address: E0000000h
MTRR #0 = 000000000, 06; 080000000, used
MTRR #1 = 080000000, 06; 0C0000000, used
MTRR #2 = 0C0000000, 06; 0E0000000, used
MTRR #3 = 0DFF00000, 00; 0FFF00000, used
MTRR #4 = 0E0000000, 01; 0F0000000, used
MTRR #5 = 0F0000000, 06; 0F0000000, used
MTRR #6 = 000000000, 06; 0E0000000, used
MTRR #7 = 000000000, 00; 000000000, unused
MTRR area E0000000-EFFFFFFFh was set to mode: WC

And gues what? I got fast LFB even in pure DOS. So as you can see my tool set the MTRR for LFB properly (MTRR #4 = 0E0000000, 01; 0F0000000, used). But it seems to interfere with other MTRRs that was set by silly BIOS. I tried to clear them out 1 by 1 but didn't helped. Do you see the problem? Please help.

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

Homepage

CZ,
31.01.2012, 02:39

@ RayeR
 

MTRR mystery

Post reply

del

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

31.01.2012, 05:38

@ RayeR
 

MTRR mystery

Post reply

> > When I come at home I'll try pull one DIMM out.
>
> Yes, I was right! I pulled 1 DIMM out and got back my VESA hyper speed. But
> why? I did some comparison. First here's output of Japhet's memstat.
> for 2GB:
>
> Int 15h, ah=88h, extended memory: 0 kB
> Int 15h, ax=E801h:
> ext. memory below 16 MB: 15360 (0x3c00) KB
> ext. memory above 16 MB: 32494 64 KB blocks = 2030 MB [1000000-7fedffff]
> Int 15h, eax=E820h:
> addr 000000000, size 00009f800, type 1 (available)
> addr 0000f0000, size 000010000, type 2 (reserved)
> addr 0fec00000, size 001400000, type 2 (reserved)
> addr 0f0000000, size 004000000, type 2 (reserved)
> addr 00009f800, size 000000800, type 2 (reserved)
> addr 07fef0000, size 000010000, type 2 (reserved)
> addr 000100000, size 07fde0000, type 1 (available)
> addr 07fee3000, size 00000d000, type 3 (ACPI)
>
> for 4GB:
>
> Int 15h, ah=88h, extended memory: 0 kB
> Int 15h, ax=E801h:
> ext. memory below 16 MB: 15360 (0x3c00) KB
> ext. memory above 16 MB: 57070 64 KB blocks = 3566 MB [1000000-dfedffff]
> Int 15h, eax=E820h:
> addr 000000000, size 00009f800, type 1 (available)
> addr 0000f0000, size 000010000, type 2 (reserved)
> addr 0fec00000, size 001400000, type 2 (reserved)
> addr 0f0000000, size 004000000, type 2 (reserved)
> addr 00009f800, size 000000800, type 2 (reserved)
> addr 0dfef0000, size 000010000, type 2 (reserved)
> addr 000100000, size 0dfde0000, type 1 (available)
> addr 0dfee3000, size 00000d000, type 3 (ACPI)
> addr 0dfee0000, size 000003000, type 4 (ACPI)
>
> Then I checked how MTRRs are set with 2GB.
> before:
>
> VESA 3.0 NVIDIA [262144 kB]
> LFB address: E0000000h
> MTRR #0 = 000000000, 06; 080000000, 1
> MTRR #1 = 07FF00000, 00; 0FFF00000, 1
> MTRR #2 = 000000000, 00; 000000000, 0
> MTRR #3 = 000000000, 00; 000000000, 0
> MTRR #4 = 000000000, 00; 000000000, 0
> MTRR #5 = 000000000, 00; 000000000, 0
> MTRR #6 = 000000000, 00; 000000000, 0
> MTRR #7 = 000000000, 00; 000000000, 0
> MTRR area E0000000-EFFFFFFFh was set to mode: WC
>
> after:
>
> VESA 3.0 NVIDIA [262144 kB]
> LFB address: E0000000h
> MTRR #0 = 000000000, 06; 080000000, 1
> MTRR #1 = 07FF00000, 00; 0FFF00000, 1
> MTRR #2 = 0E0000000, 01; 0F0000000, 1
> MTRR area E0000000-EFFFFFFFh was set to mode: WC
>
> And now with 4GB.
> before:
>
> VESA 3.0 NVIDIA [262144 kB]
> LFB address: E0000000h
> MTRR #0 = 000000000, 06; 000000000, used
> MTRR #1 = 0E0000000, 00; 0E0000000, used
> MTRR #2 = 000000000, 06; 0E0000000, used
> MTRR #3 = 0DFF00000, 00; 0FFF00000, used
> MTRR #4 = 000000000, 00; 000000000, unused
> MTRR #5 = 000000000, 00; 000000000, unused
> MTRR #6 = 000000000, 00; 000000000, unused
> MTRR #7 = 000000000, 00; 000000000, unused
> MTRR area E0000000-EFFFFFFFh was set to mode: WC
>
> after:
>
> VESA 3.0 NVIDIA [262144 kB]
> LFB address: E0000000h
> MTRR #0 = 000000000, 06; 000000000, used
> MTRR #1 = 0E0000000, 01; 0F0000000, used
> MTRR #2 = 000000000, 06; 0E0000000, used
> MTRR #3 = 0DFF00000, 00; 0FFF00000, used
> MTRR #4 = 000000000, 00; 000000000, unused
> MTRR #5 = 000000000, 00; 000000000, unused
> MTRR #6 = 000000000, 00; 000000000, unused
> MTRR #7 = 000000000, 00; 000000000, unused
> MTRR area E0000000-EFFFFFFFh was set to mode: WC
>
> I also tested Windows NT 4.0 with VBEMP driver and they was not affected
> (run fast as usual). So I dumped MTRRs with my CPUID utility and hardcoded
> to MTRRLFBE:
>
> This is how WinNT 4.0 + VBEMP set MTRRs:
>
> MTRR RAW values
> MSR [00000200h] = 0000000000000006h MSR [00000201h] = 0000000F80000800h
> MSR [00000202h] = 0000000080000006h MSR [00000203h] = 0000000FC0000800h
> MSR [00000204h] = 00000000C0000006h MSR [00000205h] = 0000000FE0000800h
> MSR [00000206h] = 00000000DFF00000h MSR [00000207h] = 0000000FFFF00800h
> MSR [00000208h] = 00000000E0000001h MSR [00000209h] = 0000000FF0000800h
> MSR [0000020Ah] = 00000000F0000006h MSR [0000020Bh] = 0000000FF0000800h
> MSR [0000020Ch] = 0000000100000006h MSR [0000020Dh] = 0000000FE0000800h
> MSR [0000020Eh] = 0000000000000000h MSR [0000020Fh] = 0000000000000000h
>
> MTRR parsed values
> VESA 3.0 NVIDIA [262144 kB]
> LFB address: E0000000h
> MTRR #0 = 000000000, 06; 080000000, used
> MTRR #1 = 080000000, 06; 0C0000000, used
> MTRR #2 = 0C0000000, 06; 0E0000000, used
> MTRR #3 = 0DFF00000, 00; 0FFF00000, used
> MTRR #4 = 0E0000000, 01; 0F0000000, used
> MTRR #5 = 0F0000000, 06; 0F0000000, used
> MTRR #6 = 000000000, 06; 0E0000000, used
> MTRR #7 = 000000000, 00; 000000000, unused
> MTRR area E0000000-EFFFFFFFh was set to mode: WC
>
> And gues what? I got fast LFB even in pure DOS. So as you can see my tool
> set the MTRR for LFB properly (MTRR #4 = 0E0000000, 01; 0F0000000, used).
> But it seems to interfere with other MTRRs that was set by silly BIOS. I
> tried to clear them out 1 by 1 but didn't helped. Do you see the problem?
> Please help.
some MTRR entries are pushed down by NT4/VBEMP. Does the order make the different result?
I wonder if #0 to #2 can be combined into 1 entry and it is still work as expected?
RayeR

Homepage

CZ,
31.01.2012, 13:02
(edited by RayeR, 31.01.2012, 20:48)

@ roytam
 

MTRR mystery

Post reply

> some MTRR entries are pushed down by NT4/VBEMP. Does the order make the
> different result?
> I wonder if #0 to #2 can be combined into 1 entry and it is still work as
> expected?
AFAIK the order is not important. Yes some ranges seems to be possible to combine into one.

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

Homepage

CZ,
02.02.2012, 04:13
(edited by RayeR, 02.02.2012, 04:31)

@ roytam
 

MTRR mystery

Post reply

I'm on the track of the problem. I reduced the MTRR list and found that good performance affected by
base mask mode
MTRR #0 = 000000000h, 080000000h, 06h, used
when there's
MTRR #0 = 000000000h, 000000000h, 06h, used
it's slow.
The second MTRR was set for LFB WC mode same in both cases.
I'll need to study docs again how the mask is calculated.
MTRR0 is set by BIOS and maybe there's a bug that set it
wrong way. Maybe 0 is not valid for mask or it overflow
and had to be 36-bit value 100000000h or it may overlap
and then probably lower caching is used. I don't know now
but I hope I'll find a way to fix mtrrlfbe.

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

02.02.2012, 05:46

@ RayeR
 

MTRR mystery

Post reply

> I'm on the track of the problem.
Thanks for your efforts... By the way, on my c2d system with 4 GB RAM, MTRRLFBE works fine to enable WC in LFB. It's only on my i7 system (with 16 GB) and SandyBridge Intel graphics that it doesn't work. At first, it appears to set the WC, but then the entire system locks solid within 1 second after the apparent success. Removing all but one DIMM didn't help the problem. I can't get to below 4 GB total system RAM since I only have 4GB DDR3 sticks.

Tried all BIOS options, PCI latency, etc to no avail. I suspect BIOS memory allocation problem is affecting the MTRRs.

Isn't there a way to limit the upper limit of RAM detected by HIMEM.SYS or some other extended memory manager (QHimem, etc) by use of a switch? Can't remember right now, but I thought there was some obscure, undocumented way.
RayeR

Homepage

CZ,
02.02.2012, 10:51

@ Zyzzle
 

MTRR mystery

Post reply

> Thanks for your efforts... By the way, on my c2d system with 4 GB RAM,
> MTRRLFBE works fine to enable WC in LFB.
Interesting. I'd like to see how BIOS set MTRRs. Please use this test version
http://rayer.ic.cz/350d/vesatest.zip
and run it twice and grab 2 logfiles. In 1st will be MTRRs before set, in second after set. Now for the test I hardcoded MTRR0 mask to 80000000h, 1 (writeback for lower 2GB). Try on both systems.

> It's only on my i7 system (with 16
> GB) and SandyBridge Intel graphics that it doesn't work. At first, it
> appears to set the WC, but then the entire system locks solid within 1
> second after the apparent success.
Hm it seems to be different kind of error. When some MTRR is overwritten wrong way it may freeze system. On my i5 at work I use nvidia GT230 and it doesn't freeze but didn't tested with inte. vga.

> Tried all BIOS options, PCI latency, etc to no avail. I suspect BIOS memory
> allocation problem is affecting the MTRRs.
This is doesn't releated to caching and MTRRs.

> Isn't there a way to limit the upper limit of RAM detected by HIMEM.SYS or
> some other extended memory manager (QHimem, etc) by use of a switch? Can't
> remember right now, but I thought there was some obscure, undocumented way.
I got this idea too but doesn't work. It must be done on lower level than memory manager.

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

Homepage

CZ,
02.02.2012, 20:44

@ RayeR
 

MTRR mystery

Post reply

I have partial succes on core i5 @work:

MTRRs before:
VESA 3.0 NVIDIA [14336 kB]
LFB address: CF000000h
MTRR #0 = 000000000h, 000000000h, 06h, used
MTRR #1 = 000000000h, 0E0000000h, 06h, used
MTRR #2 = 020000000h, 0F0000000h, 06h, used
MTRR #3 = 030000000h, 0FC000000h, 06h, used
MTRR #4 = 0CC000000h, 0FC000000h, 00h, used
MTRR #5 = 0D0000000h, 0F0000000h, 00h, used
MTRR #6 = 0E0000000h, 0E0000000h, 00h, used
MTRR #7 = 000000000h, 000000000h, 00h, unused
MTRR area CF000000-CFDFFFFFh was set to mode: WC

MTRRs after I patched MTRR0 and removed MTRR4 that also seemed to overlap LFB area

VESA 3.0 NVIDIA [14336 kB]
LFB address: CF000000h
MTRR #0 = 000000000h, 080000000h, 06h, used
MTRR #1 = 000000000h, 0E0000000h, 06h, used
MTRR #2 = 020000000h, 0F0000000h, 06h, used
MTRR #3 = 030000000h, 0FC000000h, 06h, used
MTRR #4 = 000000000h, 000000000h, 00h, unused
MTRR #5 = 0D0000000h, 0F0000000h, 00h, used
MTRR #6 = 0E0000000h, 0E0000000h, 00h, used
MTRR #7 = 0CF000000h, 0FF200000h, 01h, used
MTRR area CF000000-CFDFFFFFh was set to mode: WC

Then I got performance gain from poor 29MB/s to less poor 270MB/s but still 10x less than expected :P Maybe on this system BIOS use PAT?

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

03.02.2012, 08:20
(edited by Zyzzle, 03.02.2012, 23:30)

@ RayeR
 

MTRR mystery

Post reply

Your test version of MTRRLFBE.exe works now for my in c2d system AND also in my i7 SandyBridge system! There are some interesting results I posted in the below logfiles as you requested. On my c2d system, I could configure BIOS to not do "memory remapping" and so detected memory was 3328 MB and MTRRLFBE works perfectly for enabling WC in lfb. When I changed bios option to enable memory remapping, memory is detected as 4096 MB, and MTRRLFBE appears to set WC in lfb successfully, the system does not freeze, but VESATEST.EXE speeds are still the same as UC mode.

On my i7 system, there is NO memory-remapping feature in BIOS, detected memory is 16384MB and your testversion WORKED! No lockup or freeze as in your old version of MTRRLFBE. However, it was only partially successful, as you had also seemed to experience on your i5 system.

I had to run FASTVID.EXE 1.10 and use its option to enable WC in lfb to get full blazing speed. It looks FastVid lfb WC uses MTRR 0 to 7 while your program only uses 0 to 6. Maybe this is the reason for your partial success? Incidently, running FastVid first WITHOUT first running your new testversion of MTRRLFBE freezes my i7 system solid.

-----------------------------------------------------------------------------
c2d E8400 system with 3328 MB RAM before WC in lfb

MTRR-WC enabler for VESA LFB 1.3 (C) 2005-2011 by Martin Rehak;
Compiled by GCC 4.6.2 at 10:33:26, Feb 2 2012
Host machine CPU vendor: GenuineIntel, ID: 10676h

VESA 3.0 Intel(r)Eaglelake Graphics Chip Accelerated VGA BIOS [32704 kB]
Intel Corporation
Intel(r)Eaglelake Graphics Controller
Hardware Version 0.0

LFB address: D0000000h
MTRR #0 = 000000000h, 080000000h, 06h, used
MTRR #1 = 080000000h, 0C0000000h, 06h, used
MTRR #2 = 0C0000000h, 0F0000000h, 06h, used
MTRR #3 = 0CDE00000h, 0FFE00000h, 00h, used
MTRR #4 = 0CE000000h, 0FE000000h, 00h, used
MTRR #5 = 000000000h, 000000000h, 00h, unused
MTRR #6 = 000000000h, 000000000h, 00h, unused
MTRR #7 = 000000000h, 000000000h, 00h, unused
MTRR area D0000000-D1FEFFFFh was set to mode: UC

c2d system with 3328 MB RAM *after* enabling WC in lfb

LFB address: D0000000h
MTRR #0 = 000000000h, 080000000h, 06h, used
MTRR #1 = 080000000h, 0C0000000h, 06h, used
MTRR #2 = 0C0000000h, 0F0000000h, 06h, used
MTRR #3 = 0CDE00000h, 0FFE00000h, 00h, used
MTRR #4 = 0CE000000h, 0FE000000h, 00h, used
MTRR #5 = 0D0000000h, 0FE010000h, 00h, used
MTRR #6 = 000000000h, 000000000h, 00h, unused
MTRR #7 = 000000000h, 000000000h, 00h, unused
MTRR area D0000000-D1FEFFFFh was set to mode: WC

NOTE: c2d system with *4096 MB* RAM in BIOS enabling WC in lfb has no speedup

i7 2600k system with 16384 MB RAM *before* WC in lfb

MTRR-WC enabler for VESA LFB 1.3 (C) 2005-2011 by Martin Rehak;
Compiled by GCC 4.6.2 at 10:33:26, Feb 2 2012
Host machine CPU vendor: GenuineIntel, ID: 206A7h

VESA 3.0 Intel(R)Sandybridge Desktop Graphics Chipset Accelerated VGA BIOS [32704 kB]
Intel Corporation
Intel(R)Sandybridge Desktop Graphics Controller
Hardware Version 0.0
LFB address: E0000000h
MTRR #0 = 000000000h, 000000000h, 06h, used
MTRR #1 = 0E0000000h, 0E0000000h, 00h, used
MTRR #2 = 0DE000000h, 0FE000000h, 00h, used
MTRR #3 = 0DD800000h, 0FF800000h, 00h, used
MTRR #4 = 000000000h, 000000000h, 06h, used
MTRR #5 = 000000000h, 000000000h, 06h, used
MTRR #6 = 000000000h, 0E0000000h, 06h, used
MTRR #7 = 000000000h, 000000000h, 00h, unused
MTRR #8 = 000000000h, 000000000h, 00h, unused
MTRR #9 = 000000000h, 000000000h, 00h, unused
MTRR area E0000000-E1FEFFFFh was set to mode: UC


i7 2600k system with 16384 MB RAM *after* enabling WC in lfb

LFB address: E0000000h
MTRR #0 = 000000000h, 080000000h, 06h, used
MTRR #1 = 0E0000000h, 0FE010000h, 00h, used
MTRR #2 = 0DE000000h, 0FE000000h, 00h, used
MTRR #3 = 0DD800000h, 0FF800000h, 00h, used
MTRR #4 = 000000000h, 000000000h, 06h, used
MTRR #5 = 000000000h, 000000000h, 06h, used
MTRR #6 = 000000000h, 0E0000000h, 06h, used
MTRR #7 = 000000000h, 000000000h, 00h, unused
MTRR #8 = 000000000h, 000000000h, 00h, unused
MTRR #9 = 000000000h, 000000000h, 00h, unused
MTRR area E0000000-E1FEFFFFh was set to mode: WC

(success but 1024x768x32bpp (mode 4118) in VESATEST.exe "only" 769 mb/sec)

i7 2600k system with 16384 MB RAM *after* enabling WC in lfb *AND* running FastVid 1.10 by John Hinkley, and enabling its "linear framebuffer write combining mode"

LFB address: E0000000h
MTRR #0 = 000000000h, 080000000h, 06h, used
MTRR #1 = 0E0000000h, 0FE010000h, 01h, used
MTRR #2 = 0DE000000h, 0FE000000h, 00h, used
MTRR #3 = 0DD800000h, 0FF800000h, 00h, used
MTRR #4 = 000000000h, 000000000h, 06h, used
MTRR #5 = 000000000h, 000000000h, 06h, used
MTRR #6 = 000000000h, 0E0000000h, 06h, used
MTRR #7 = 0E0000000h, 0FE100000h, 01h, used
MTRR #8 = 000000000h, 000000000h, 00h, unused
MTRR #9 = 000000000h, 000000000h, 00h, unused
MTRR area E0000000-E1FEFFFFh was set to mode: WC
(Now mode 0x4118h tested in "FASTVID.EXe 1024 768 32 lfb" shoots up to 1992 MB/sec!)
--------------------------------------------------------------------------
RayeR

Homepage

CZ,
03.02.2012, 19:19
(edited by RayeR, 03.02.2012, 23:25)

@ Zyzzle
 

MTRR mystery

Post reply

Thanks for debug reports. Please remove my email address from your post. I can see that your C2D machine has more intelligent BIOS (What mobo? mine is gigabyte GA-P31...). It mapped user RAM area to 3 smaller blocks set to write-back that doesnt't spread entire address space but ending probably at CDFFFFFFh. So when I add new MTRR for LFB area it doesn't conflict (overlap) with any other area and it works as expected. Please send logs with remapping enabled too, I'd like to compare them. I don't have such option in BIOS. AFAIK remapping use PAE (36bit phys addr) some way...

But your i7 system really confusing me:
MTRR #0 = 000000000h, 000000000h, 06h, used
MTRR #1 = 0E0000000h, 0E0000000h, 00h, used
MTRR #2 = 0DE000000h, 0FE000000h, 00h, used
MTRR #3 = 0DD800000h, 0FF800000h, 00h, used
MTRR #4 = 000000000h, 000000000h, 06h, used - WTF? why duplicate MTRR0?
MTRR #5 = 000000000h, 000000000h, 06h, used - WTF? why duplicate MTRR0?
MTRR #6 = 000000000h, 0E0000000h, 06h, used - WTF? why duplicate range of MTRR1 with different caching?

As I think that less caching should have higher priority, so LFB is still uncached.

Looking at MTRRs after:
MTRR #0 = 000000000h, 080000000h, 06h, used - well my hardcoded setting
MTRR #1 = 0E0000000h, 0FE010000h, 00h, used - WTF? why still uncached? Didn't you made typo error and set "UC" instead "WC"? Please try again. I cannot imagine what error could cause that base and mask was set but mode not.
MTRR #2 = 0DE000000h, 0FE000000h, 00h, used
MTRR #3 = 0DD800000h, 0FF800000h, 00h, used
MTRR #4 = 000000000h, 000000000h, 06h, used - still overlaping entire 4G
MTRR #5 = 000000000h, 000000000h, 06h, used - still overlaping entire 4G
MTRR #6 = 000000000h, 0E0000000h, 06h, used

Looking at MTRRs after FastVid:
MTRR #0 = 000000000h, 080000000h, 06h, used - well my hardcoded setting
MTRR #1 = 0E0000000h, 0FE010000h, 01h, used - WTF? why there's 1 now?
MTRR #2 = 0DE000000h, 0FE000000h, 00h, used
MTRR #3 = 0DD800000h, 0FF800000h, 00h, used
MTRR #4 = 000000000h, 000000000h, 06h, used - still overlaping entire 4G
MTRR #5 = 000000000h, 000000000h, 06h, used - still overlaping entire 4G
MTRR #6 = 000000000h, 0E0000000h, 06h, used
MTRR #7 = 0E0000000h, 0FE100000h, 01h, used - new LFB area setting by fastvid

I can see there's a difference how fastvid calculated the mask: FE100000 vs FE010000. LFB size is for some strange reason not aligned to 32MB but 32MB-64kB. This may cause problem, maybe my mask calculation is wrong. If I calculate well, fastvid covers only 31744kB of 32704kB - not entire LFB area. But available VESA modes doesn't need 32MB at all.
Anyway because of MTRR 4 and 5 is still set I wonder that this setting has any effect. Really confused... :surprised:

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

04.02.2012, 07:08

@ RayeR
 

MTRR mystery

Post reply

New Logs:

C2D Motherboard Biostar G41-M7 (Intel G41 chipset)
PCI MMIO Allocation: 4 GB to 3072 MB before WC (memory remap enabled)

LFB address: D0000000h
MTRR #0 = 000000000h, 000000000h, 06h, used
MTRR #1 = 000000000h, 0C0000000h, 06h, used
MTRR #2 = 0C0000000h, 0C0000000h, 00h, used
MTRR #3 = 0BDE00000h, 0FFE00000h, 00h, used
MTRR #4 = 0BE000000h, 0FE000000h, 00h, used
MTRR #5 = 000000000h, 000000000h, 00h, unused
MTRR #6 = 000000000h, 000000000h, 00h, unused
MTRR #7 = 000000000h, 000000000h, 00h, unused
MTRR area D0000000-D1FEFFFFh was set to mode: UC

c2d after WC and memory remap enabled

LFB address: D0000000h
MTRR #0 = 000000000h, 080000000h, 06h, used
MTRR #1 = 000000000h, 0C0000000h, 06h, used
MTRR #2 = 0C0000000h, 0C0000000h, 00h, used
MTRR #3 = 0BDE00000h, 0FFE00000h, 00h, used
MTRR #4 = 0BE000000h, 0FE000000h, 00h, used
MTRR #5 = 0D0000000h, 0FE010000h, 00h, used
MTRR #6 = 000000000h, 000000000h, 00h, unused
MTRR #7 = 000000000h, 000000000h, 00h, unused
MTRR area D0000000-D1FEFFFFh was set to mode: WC

c2d after WC and FastVid and memory remap enabled

LFB address: D0000000h
MTRR #0 = 000000000h, 080000000h, 06h, used
MTRR #1 = 000000000h, 0C0000000h, 06h, used
MTRR #2 = 0C0000000h, 0C0000000h, 00h, used
MTRR #3 = 0BDE00000h, 0FFE00000h, 00h, used
MTRR #4 = 0BE000000h, 0FE000000h, 00h, used
MTRR #5 = 0D0000000h, 0FE010000h, 01h, used
MTRR #6 = 000000000h, 000000000h, 00h, unused
MTRR #7 = 0D0000000h, 0FE100000h, 01h, used
MTRR area D0000000-D1FEFFFFh was set to mode: WC


i7 system after WC
VESA 3.0 Intel(R)Sandybridge Desktop Graphics Chipset Accelerated VGA BIOS [32704 kB]
Intel Corporation
Intel(R)Sandybridge Desktop Graphics Controller
Hardware Version 0.0
LFB address: E0000000h
MTRR #0 = 000000000h, 000000000h, 06h, used
MTRR #1 = 0E0000000h, 0E0000000h, 00h, used
MTRR #2 = 0DE000000h, 0FE000000h, 00h, used
MTRR #3 = 0DD800000h, 0FF800000h, 00h, used
MTRR #4 = 000000000h, 000000000h, 06h, used
MTRR #5 = 000000000h, 000000000h, 06h, used
MTRR #6 = 000000000h, 0E0000000h, 06h, used
MTRR #7 = 000000000h, 000000000h, 00h, unused
MTRR #8 = 000000000h, 000000000h, 00h, unused
MTRR #9 = 000000000h, 000000000h, 00h, unused
MTRR area E0000000-E1FEFFFFh was set to mode: WC


Do these help you further to troubleshoot the MTRR problems?

On further investigation, you are right. It seems some areas of lfb are still uncached after the WC enabled. Some programs show no improvement in speed. For example, AdvanceMAME v .106 (last DOS compile) is very slow using VESA vbe modes on my i7 (eg, 47% of 'normal' speed playing Popeye, 43% of normal speed using Crusin USA), where my c2d system playes Popeye at ~500% of normal speed and Cruusin USA at ~ 80% of normal speed).

What is a good option to benchmark MPLAYER, to test its absolute flatout speed, using 100% CPU power? Tried turning off VBE, and -speed, but are there other options?
RayeR

Homepage

CZ,
05.02.2012, 02:20
(edited by RayeR, 05.02.2012, 14:39)

@ Zyzzle
 

MTRR mystery

Post reply

> Do these help you further to troubleshoot the MTRR problems?
Yes. I can see that I may get various mess in MTRRs so it's not easy to make universal algo that will work on all systems. This should be job for BIOS to properly init thr HW... I also have to study Page Attribute Table and how to modify it. This may be better way. I read that it can override MTRR setting and allows fine granularity. It should be supported on PIII+. Surely I will make some further test version...

> What is a good option to benchmark MPLAYER, to test its absolute flatout
> speed, using 100% CPU power? Tried turning off VBE, and -speed, but are
> there other options?
You can try -benchmark -nosound and maybe disable vsync, then it should run unlimited speed. It worked for me and even with slowed down VESA I got ~4x faster speed.

UPDATE:
I found important note in intel SWDM:

11.11.4 Range Size and Alignment Requirement
A range that is to be mapped to a variable-range MTRR must meet the following
?power of 2? size and alignment rules:
1. The minimum range size is 4 KBytes and the base address of the range must be
on at least a 4-KByte boundary.
2. For ranges greater than 4 KBytes, each range must be of length 2^n and its base
address must be aligned on a 2^n boundary, where n is a value equal to or greater
than 12. The base-address alignment value cannot be less than its length. For
example, an 8-KByte range cannot be aligned on a 4-KByte boundary. It must be
aligned on at least an 8-KByte boundary.

So this means that fastvid set the mask wrong too! There are holes in the mask that may cause problems. In your case the range must be truncated to 16MB and it is possibe to setup additional ranges in size 8MB, 4MB, 2MB and so on to reach last 64kB block but it's wasting of free MTRRs as we have only 8 of them.
Page Attribute Table doesn't have such strict limitation - it needs only 4kB alignment.

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

Homepage

CZ,
06.02.2012, 02:23
(edited by RayeR, 06.02.2012, 02:35)

@ RayeR
 

MTRR mystery

Post reply

Ou, I found a bug in printing the MTRRs. When I did 12-bit shift I forget it will owerflow 32bit variable so the top nibble was displayed always zero. Now I can see that have a MTRR with base at 4GB and 512MB area, that looks like remapping always enabled...

Here's my updated tools: http://rayer.ic.cz/350d/vesatest.zip
* fixed debug print
* debug print is now compiled by default and can be unabled by /d switch so use
mtrrlfbe lfb wc /d
* added MTRR area trimming to highest power of 2 that fits LFB size according to intel SWDM
* added code that searchs through all MTRRs and patch MTRR with base 0 and mask 4GB to mask 2GB.

Please retest. If you have a time try to make all logs again (c2d with and without remap and i7, all twice). Fastvid now shouldn't be needed (anyway it doesn't met 2^n rule).

Here's my output - before:

VESA 3.0 NVIDIA [262144 kB]
LFB address: E0000000h
MTRR #0: base = 000000000h ( 0MB), mask = F00000000h (4096MB), WB, used
MTRR #1: base = 0E0000000h (3584MB), mask = FE0000000h ( 512MB), UC, used
MTRR #2: base = 100000000h (4096MB), mask = FE0000000h ( 512MB), WB, used
MTRR #3: base = 0DFF00000h (3583MB), mask = FFFF00000h ( 1MB), UC, used
MTRR #4: base = 000000000h ( 0MB), mask = 000000000h ( 0MB), UC, unused
MTRR #5: base = 000000000h ( 0MB), mask = 000000000h ( 0MB), UC, unused
MTRR #6: base = 000000000h ( 0MB), mask = 000000000h ( 0MB), UC, unused
MTRR #7: base = 000000000h ( 0MB), mask = 000000000h ( 0MB), UC, unused
Setting MTRR #1...
MTRR area E0000000-EFFFFFFFh was set to mode: WC

after:

VESA 3.0 NVIDIA [262144 kB]
LFB address: E0000000h
MTRR #0: base = 000000000h ( 0MB), mask = F80000000h (2048MB), WB, used
MTRR #1: base = 0E0000000h (3584MB), mask = FF0000000h ( 256MB), WC, used
MTRR #2: base = 100000000h (4096MB), mask = FE0000000h ( 512MB), WB, used
MTRR #3: base = 0DFF00000h (3583MB), mask = FFFF00000h ( 1MB), UC, used
MTRR #4: base = 000000000h ( 0MB), mask = 000000000h ( 0MB), UC, unused
MTRR #5: base = 000000000h ( 0MB), mask = 000000000h ( 0MB), UC, unused
MTRR #6: base = 000000000h ( 0MB), mask = 000000000h ( 0MB), UC, unused
MTRR #7: base = 000000000h ( 0MB), mask = 000000000h ( 0MB), UC, unused
Setting MTRR #1...
MTRR area E0000000-EFFFFFFFh was set to mode: WC

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

Homepage

CZ,
06.02.2012, 12:14

@ RayeR
 

MTRR mystery

Post reply

I finally got full performance on my i5 @work! But it was not fully automatic process, one "bad" MTRR still caused overlaping and I must manually clear it via my CPUID tool. Also fixed MTRR prints now started to give a sense to me.

before:

VESA 3.0 NVIDIA [14336 kB]
LFB address: CF000000h
MTRR #0: base = 000000000h ( 0MB), mask = E00000000h (8192MB), WB, used
MTRR #1: base = 200000000h (8192MB), mask = FE0000000h ( 512MB), WB, used
MTRR #2: base = 220000000h (8704MB), mask = FF0000000h ( 256MB), WB, used
MTRR #3: base = 230000000h (8960MB), mask = FFC000000h ( 64MB), WB, used
MTRR #4: base = 0CC000000h (3264MB), mask = FFC000000h ( 64MB), UC, used
MTRR #5: base = 0D0000000h (3328MB), mask = FF0000000h ( 256MB), UC, used
MTRR #6: base = 0E0000000h (3584MB), mask = FE0000000h ( 512MB), UC, used
MTRR #7: base = 000000000h ( 0MB), mask = 000000000h ( 0MB), UC, unused
Setting MTRR #7...
MTRR area CF000000-CFDFFFFFh was set to mode: WC

after:

VESA 3.0 NVIDIA [14336 kB]
LFB address: CF000000h
MTRR #0: base = 000000000h ( 0MB), mask = F80000000h (2048MB), WB, used - patched to not overlap LFB
MTRR #1: base = 200000000h (8192MB), mask = FE0000000h ( 512MB), WB, used
MTRR #2: base = 220000000h (8704MB), mask = FF0000000h ( 256MB), WB, used
MTRR #3: base = 230000000h (8960MB), mask = FFC000000h ( 64MB), WB, used
MTRR #4: base = 0CC000000h (3264MB), mask = FFC000000h ( 64MB), UC, used - but this bastard overlaps LFB too. It covers some MMIO that should be uncached but I really don't know what area is really used. If I can shrink it to 32MB. This is BIOS specific issue that will complicate MTRR setting routine. I would add checking of all MTRRs if not overlaps...
MTRR #5: base = 0D0000000h (3328MB), mask = FF0000000h ( 256MB), UC, used
MTRR #6: base = 0E0000000h (3584MB), mask = FE0000000h ( 512MB), UC, used
MTRR #7: base = 0CF000000h (3312MB), mask = FFF800000h ( 8MB), WC, used - my LFB setting, now with correct continuous mask
Setting MTRR #7...
MTRR area CF000000-CFDFFFFFh was set to mode: WC

Now I got 2054 MB/s wow. As it grows to complexity it more and more suggests to use PAT. But I'd like to see your logs too to getting more understand how BIOS set MTRRs...

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

07.02.2012, 08:04

@ RayeR
 

MTRR mystery

Post reply

Alright, now this is getting mysterious to me. Your new version seems to speed up all my i7 VESA lfb modes to maximum speed (between 8287 and 10070 MB/sec!), BUT now all system memory ABOVE 2gb is Uncached! Resetting my system to state before MTRRLFBE.exe is run restores full caching to my fullrange of DOS memory available to the system (to 3.5GB)

Also, more strangely, if I run "mtrrlfbe lfb UC -d" on my i7 system now, it freezes within 0.2 second of setting the MTRRs. It is like the situation is reversed from your older versions of MTRRLFBE where the i7 system would freeze in an identical manner AFTER lfb WC was enabled!!

It seems more apparent to me that I must manually set MTRRs somehow, but how? BIOS does not allow this and I do have your CPUID program, but how to set MTRRs with it?

Also, my C2D system's performance is dramatically improved with your latest version (2200 MB/sec), but again only with BIOS memory remapping disabled. No performance increase at all WITH memory remapping enabled.

New logs:
c2d w/o BIOS memory remapping before

LFB address: D0000000h
MTRR #0: base = 000000000h ( 0MB), mask = F80000000h (2048MB), WB, used
MTRR #1: base = 080000000h (2048MB), mask = FC0000000h (1024MB), WB, used
MTRR #2: base = 0C0000000h (3072MB), mask = FF0000000h ( 256MB), WB, used
MTRR #3: base = 0CDE00000h (3294MB), mask = FFFE00000h ( 2MB), UC, used
MTRR #4: base = 0CE000000h (3296MB), mask = FFE000000h ( 32MB), UC, used
MTRR #5: base = 000000000h ( 0MB), mask = 000000000h ( 0MB), UC, unused
MTRR #6: base = 000000000h ( 0MB), mask = 000000000h ( 0MB), UC, unused
MTRR #7: base = 000000000h ( 0MB), mask = 000000000h ( 0MB), UC, unused
Setting MTRR #5...
MTRR area D0000000-D1FEFFFFh was set to mode: UC

c2D w/o BIOS memory remapping after
LFB address: D0000000h
MTRR #0: base = 000000000h ( 0MB), mask = F80000000h (2048MB), WB, used
MTRR #1: base = 080000000h (2048MB), mask = FC0000000h (1024MB), WB, used
MTRR #2: base = 0C0000000h (3072MB), mask = FF0000000h ( 256MB), WB, used
MTRR #3: base = 0CDE00000h (3294MB), mask = FFFE00000h ( 2MB), UC, used
MTRR #4: base = 0CE000000h (3296MB), mask = FFE000000h ( 32MB), UC, used
MTRR #5: base = 0D0000000h (3328MB), mask = FFF000000h ( 16MB), UC, used
MTRR #6: base = 000000000h ( 0MB), mask = 000000000h ( 0MB), UC, unused
MTRR #7: base = 000000000h ( 0MB), mask = 000000000h ( 0MB), UC, unused
Setting MTRR #5...
MTRR area D0000000-D1FEFFFFh was set to mode: WC

C2D with bios memory remapping before
LFB address: D0000000h
MTRR #0: base = 000000000h ( 0MB), mask = F00000000h (4096MB), WB, used
MTRR #1: base = 100000000h (4096MB), mask = FC0000000h (1024MB), WB, used
MTRR #2: base = 0C0000000h (3072MB), mask = FC0000000h (1024MB), UC, used
MTRR #3: base = 0BDE00000h (3038MB), mask = FFFE00000h ( 2MB), UC, used
MTRR #4: base = 0BE000000h (3040MB), mask = FFE000000h ( 32MB), UC, used
MTRR #5: base = 000000000h ( 0MB), mask = 000000000h ( 0MB), UC, unused
MTRR #6: base = 000000000h ( 0MB), mask = 000000000h ( 0MB), UC, unused
MTRR #7: base = 000000000h ( 0MB), mask = 000000000h ( 0MB), UC, unused
Setting MTRR #5...
MTRR area D0000000-D1FEFFFFh was set to mode: UC

c2D with BiOS memory remapping after
LFB address: D0000000h
MTRR #0: base = 000000000h ( 0MB), mask = F00000000h (4096MB), WB, used
MTRR #1: base = 100000000h (4096MB), mask = FC0000000h (1024MB), WB, used
MTRR #2: base = 0C0000000h (3072MB), mask = FC0000000h (1024MB), UC, used
MTRR #3: base = 0BDE00000h (3038MB), mask = FFFE00000h ( 2MB), UC, used
MTRR #4: base = 0BE000000h (3040MB), mask = FFE000000h ( 32MB), UC, used
MTRR #5: base = 0D0000000h (3328MB), mask = FFF000000h ( 16MB), UC, used
MTRR #6: base = 000000000h ( 0MB), mask = 000000000h ( 0MB), UC, unused
MTRR #7: base = 000000000h ( 0MB), mask = 000000000h ( 0MB), UC, unused
Setting MTRR #5...
MTRR area D0000000-D1FEFFFFh was set to mode: WC

i7 system AFTER lfb WC
Host machine CPU vendor: GenuineIntel, ID: 206A7h

VESA 3.0 Intel(R)Sandybridge Desktop Graphics Chipset Accelerated VGA BIOS [32704 kB]
Intel Corporation
Intel(R)Sandybridge Desktop Graphics Controller
Hardware Version 0.0
LFB address: E0000000h
MTRR #0: base = 000000000h ( 0MB), mask = F00000000h (4096MB), WB, used
MTRR #1: base = 0E0000000h (3584MB), mask = FE0000000h ( 512MB), UC, used
MTRR #2: base = 0DE000000h (3552MB), mask = FFE000000h ( 32MB), UC, used
MTRR #3: base = 0DD800000h (3544MB), mask = FFF800000h ( 8MB), UC, used
MTRR #4: base = 100000000h (4096MB), mask = F00000000h (4096MB), WB, used
MTRR #5: base = 200000000h (8192MB), mask = E00000000h (8192MB), WB, used
MTRR #6: base = 300000000h (12288MB), mask = FE0000000h ( 512MB), WB, used
MTRR #7: base = 000000000h ( 0MB), mask = 000000000h ( 0MB), UC, unused
MTRR #8: base = 000000000h ( 0MB), mask = 000000000h ( 0MB), UC, unused
MTRR #9: base = 000000000h ( 0MB), mask = 000000000h ( 0MB), UC, unused
Setting MTRR #1...
MTRR area E0000000-E1FEFFFFh was set to mode: WC

i7 with lfb UC freezes system within 0.5 sec, before debug file can be written...
--------------------------------------------------------------------------
RayeR

Homepage

CZ,
07.02.2012, 16:53

@ Zyzzle
 

MTRR mystery

Post reply

> Alright, now this is getting mysterious to me. Your new version seems to
> speed up all my i7 VESA lfb modes to maximum speed (between 8287 and 10070
> MB/sec!), BUT now all system memory ABOVE 2gb is Uncached! Resetting my
> system to state before MTRRLFBE.exe is run restores full caching to my
> fullrange of DOS memory available to the system (to 3.5GB)
Yes, this is because I rewrite MTRR0 that overlaped entire 4GB to 2GB. Do you have some problems caused that mem above 2GB is uncached? I guess that common dos programs will never reach this address. If this will be problem I would need add more MTRRs covering 1GB and 0.5GB or 0.25GB range upt to 3.5GB / 3.25GB. But it may happen that there will be no free MTRR. Windows and Linux should set MTRR by own way.

> Also, more strangely, if I run "mtrrlfbe lfb UC -d" on my i7 system now, it
> freezes within 0.2 second of setting the MTRRs. It is like the situation is
> reversed from your older versions of MTRRLFBE where the i7 system would
> freeze in an identical manner AFTER lfb WC was enabled!!
Hm, on my c2d and i5 it works both. I made a set of test versions to trace problem: http://rayer.ic.cz/350d/vesatest2.zip
Try all to set WC and UC and note which freezed and which not. Logs are not needed.

> It seems more apparent to me that I must manually set MTRRs somehow, but
> how? BIOS does not allow this and I do have your CPUID program, but how to
> set MTRRs with it?

try cpuid /?
this will allow you to read/write MSR. Variable MTRR0 starts at index 200h, every MTRR use two 64bit MSRs (base and mask structure). Eg. MTTR1 starta at 202h, MTRR2 at 204h and so on...
If you will clear MTRR2 (MSR index 204 and 205) on your C2D with remapping it should work. Do you need to enable remapping anyway?

> C2D with bios memory remapping before
> LFB address: D0000000h
> MTRR #0: base = 000000000h ( 0MB), mask = F00000000h (4096MB), WB, used - I fix this to 2GB
> MTRR #1: base = 100000000h (4096MB), mask = FC0000000h (1024MB), WB, used
> MTRR #2: base = 0C0000000h (3072MB), mask = FC0000000h (1024MB), UC, used - but this still overlaps LFB
> MTRR #3: base = 0BDE00000h (3038MB), mask = FFFE00000h ( 2MB), UC, used
> MTRR #4: base = 0BE000000h (3040MB), mask = FFE000000h ( 32MB), UC, used
It seems that I cannot use Page Attribute Table because it works only when paging enabled. And not all DOS programs using LFB enables paging. Even I don't know if setting will be permanent or only for program that set it. Not much info, nobody replied @osdev :(

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

Homepage

Czech republic,
11.02.2012, 08:49

@ RayeR
 

MTRR mystery

Post reply

I treid your test version of MTRRLFBE (I didn't know which version should I use so I used the from TEST1 directory).
Tried on both my DOS machines.
LFB speedup works as always, I have never had was any problems with it.
But now I notices also speedup in VGA region. It didn't work for me before but now it works too. Great!

---
DOS-u-akbar!
RayeR

Homepage

CZ,
11.02.2012, 13:22

@ Laaca
 

MTRR mystery

Post reply

> I treid your test version of MTRRLFBE (I didn't know which version should I
> use so I used the from TEST1 directory).
This is specially for Zyzzle and his core i7 that crashed, see above post. I'm waiting impatiently. If you have installed less than 3GB of RAM it will always work for you. We're trying to fix issues on 4GB and more machines.

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

12.02.2012, 08:11

@ RayeR
 

MTRR mystery

Post reply

> This is specially for Zyzzle and his core i7 that crashed, see above post.
> I'm waiting impatiently. If you have installed less than 3GB of RAM it will
> always work for you. We're trying to fix issues on 4GB and more machines.
I'm very sorry for the long delay in responding -- lots going on,,,

I tried all 5 of the new test versions from a COLD BOOT, ie the first program run after booting clean was your MTRRLFBE. These are the results on my i7 system:

TEST1 and TEST2 immediately freeze the system, in both UC and WC modes in lfb.
TEST3 does not freeze in WC or UC modes in lfb. Still all memory > 2gb is uncached.
TEST4 and TEST5 do not freeze system in either WC or UC. In WC mode in lfb, there is no speedup effect in running test4 or test5 MTRRLFBE. Both test4 and 5 leave all memory > 2gb in cached state, but I get no speedup of lfb in either one.

Now, if I run test3 first (in either UC or WC) and THEN immediately run test1, it does NOT freeze. I can set either mode successfully, and there is lfb speedup. Also, the identical thing is true if I run TEST2 after test3. All memory > 2gb is in UNCACHED state.

PS: Newest version of Mplayer.exe runs perfectly on my i7 and C2D systems, with sound. And, vo vesa:nodga works perfectly now as well (video is displayed, no more black screen!). Thanks very much!
Zyzzle

28.01.2012, 02:09

@ Khusraw
 

New DJGPP Mplayer build from SVN

Post reply

> Can you provide your ICH10 HDA vendor and device id?
One other observation / query directed mostly toward RayeR

Why is it impossible to set WC for LFB on the I7 2600 Sandybridge Internal graphics?

Using his MTRRLFB utility. the system freezes when attempting to set WC in LFB mode...

Using VESATEST for mode 111 (640x480x16) I get 5955 MB/sec for Bankswitching, but only 204 MB/sec for LFB.

Looking at RayerR's other posts on other places, it seems this problem is an Intel limitation (WC disabled in DOS???) Have you found a fix for this very severe limitation. RayeR? Obviously in my instance a speedup of 30x would be most significant!!

@ Khusraw:

I presume -vo:VESA in your build uses LFB exclusively. Is it possible to get it to use Bankswitching instead, in light of my above problem?
Khusraw

E-mail

Bucharest, Romania,
28.01.2012, 09:03

@ Zyzzle
 

New DJGPP Mplayer build from SVN

Post reply

> I presume -vo:VESA in your build uses LFB exclusively. Is it possible to
> get it to use Bankswitching instead, in light of my above problem?
To disable LFB, use it with vesa:nodga.

---
Glory to God for all things
RayeR

Homepage

CZ,
28.01.2012, 14:56

@ Zyzzle
 

New DJGPP Mplayer build from SVN

Post reply

> Why is it impossible to set WC for LFB on the I7 2600 Sandybridge Internal
> graphics?
I know and reported this issue last year when I got new i5 system at work. Here's my thread @ OSdev but nobody give any advice
http://forum.osdev.org/viewtopic.php?f=1&t=23193

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

Homepage E-mail

Australia,
26.01.2012, 11:52

@ Zyzzle
 

New DJGPP Mplayer build from SVN

Post reply

> One REQUEST: Is it possible to provide a binary WITHOUT networking or
> support for external codecs? These options add to bloat & I feel very few
> will use them.
Networking is a large part of what makes this port attractive to me.
I will be using that a lot. Without that it is simply another player restricted to local disks.

And IMHO being able to use external codecs is a sensible thing - ya never know !

Ron
Deniska

Homepage E-mail

27.01.2012, 12:47

@ Khusraw
 

New DJGPP Mplayer build from SVN

Post reply

Thanks for this port! This is great news for everyone! However, whilst everyone is reporting on their success in getting sound, I have been less lucky... I get silence on my Intel HD Audio with 92HD81. The videos are played well and MP3 files seem to progress, but the volume is muted. Here is the output from mplayer during initialisation:

MPlayer Khusraw-SVN-r34600 (C) 2000-2012 MPlayer Team
183 audio & 394 video codecs

Playing e:\DOCS\DENISKA\MUSIC\Pogoda.mp3.
libavformat version 53.24.2 (internal)
Audio only file format detected.
Clip info:
Title: Track 3
Artist: Artist
Album: Album
Year:
Comment: Ripped by Winamp
Track: 3
Genre: Other
Load subtitles in e:\DOCS\DENISKA\MUSIC\
==========================================================================
Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders
libavcodec version 53.42.4 (internal)
AUDIO: 44100 Hz, 2 ch, floatle, 127.7 kbit/4.53% (ratio: 15965->352800)
Selected audio codec: [ffmp3float] afm: ffmpeg (FFmpeg MPEG layer-3 audio)
==========================================================================
HDA: 5 Series/3400 Series Chipset HD Audio found.
HDA: i/o base found at 96930000.
HDA: i/o base mapped to 01CF1000, selector 00D7.
HDA: reset was succesful, codec mask: 0009, osd base 0100.
HDA: codec found, address 0000, vendor id 111D, device id 7605.
HDA: starting node id 0001, total number of nodes 1.
HDA: node id 0001 supports audio functions.
HDA: starting function/widget id 000A, total number of functions/widgets 25.
HDA: parsing node id 000A.
HDA: parsing node id 000B.
HDA: found pin type HP OUT, node id 000B.
HDA: no jack is plugged-in.
HDA: the number of connections for node id 000B is 3.
HDA: index 0 has node id 0013.
HDA: parsing node id 0013.
HDA: found DAC, node id 0013.
HDA: selected connection for node id 000B is index 0.
HDA: parsing node id 000C.
HDA: parsing node id 000D.
HDA: found pin type SPEAKER, node id 000D.
HDA: this pin doesn't support presence detection.
HDA: the number of connections for node id 000D is 3.
HDA: index 0 has node id 0013.
HDA: selected connection for node id 000D is index 0.
HDA: parsing node id 000E.
HDA: found pin type LINE OUT, node id 000E.
HDA: no jack is plugged-in.
HDA: the number of connections for node id 000E is 3.
HDA: index 0 has node id 0013.
HDA: selected connection for node id 000E is index 0.
HDA: parsing node id 000F.
HDA: parsing node id 0010.
HDA: parsing node id 0011.
HDA: parsing node id 0012.
HDA: parsing node id 0014.
HDA: found DAC, node id 0014.
HDA: parsing node id 0015.
HDA: parsing node id 0016.
HDA: parsing node id 0017.
HDA: the number of connections for node id 0017 is 7.
HDA: index 0 has node id 000C.
HDA: index 1 has node id 000E.
HDA: selected connection for node id 0017 is index 1.
HDA: parsing node id 0018.
HDA: the number of connections for node id 0018 is 7.
HDA: index 0 has node id 000C.
HDA: index 1 has node id 000E.
HDA: selected connection for node id 0018 is index 1.
HDA: parsing node id 0019.
HDA: the number of connections for node id 0019 is 3.
HDA: index 0 has node id 0013.
HDA: selected connection for node id 0019 is index 0.
HDA: parsing node id 001A.
HDA: the number of connections for node id 001A is 1.
HDA: index 0 has node id 0019.
HDA: selected connection for node id 001A is index 0.
HDA: parsing node id 001B.
HDA: the number of connections for node id 001B is 6.
HDA: index 0 has node id 000C.
HDA: index 1 has node id 000E.
HDA: selected connection for node id 001B is index 1.
HDA: parsing node id 001C.
HDA: the number of connections for node id 001C is 1.
HDA: index 0 has node id 001B.
HDA: selected connection for node id 001C is index 0.
HDA: parsing node id 001D.
HDA: parsing node id 001E.
HDA: parsing node id 001F.
HDA: parsing node id 0020.
HDA: parsing node id 0021.
HDA: parsing node id 0022.
AO_WSS: detected 5 Series/3400 Series Chipset HD Audio.
AO: [wss] 48000Hz 2ch s16le (2 bytes per sample)
Video: no video
Starting playback...


P.S. I get the same problem with Mpxplay. Does that program work for everyone else with HDA cards?
Khusraw

E-mail

Bucharest, Romania,
27.01.2012, 14:41
(edited by Khusraw, 27.01.2012, 15:34)

@ Deniska
 

New DJGPP Mplayer build from SVN

Post reply

> Thanks for this port! This is great news for everyone! However, whilst
> everyone is reporting on their success in getting sound, I have been less
> lucky... I get silence on my Intel HD Audio with 92HD81. The videos are
> played well and MP3 files seem to progress, but the volume is muted. Here
> is the output from mplayer during initialisation:[...]
What output do you use, the internal speaker? Did you also try other outputs?

EDIT: Do you have a physical LINE OUT jack on your system? It seems that the LINE OUT is selected and enabled. In fact how many outputs does your system have? I saw that some codecs give wrong answers in this regard. Can you try this test program which disables all the outputs excepting the internal speaker(s)?

---
Glory to God for all things
Deniska

Homepage E-mail

28.01.2012, 06:04

@ Khusraw
 

New DJGPP Mplayer build from SVN

Post reply

> What output do you use, the internal speaker? Did you also try other
> outputs?
I have tried all available outputs. This is a notebook, by the way. There's an internal speaker, 1 line-out and 1 microphone input. I have tried plugging in headphones into all of them, but still get silence. I have also tried running mplayer in absolutely clean DOS without ANY drivers loaded - same results. Also, in the output mplayer correctly reports whether the line-out jack is connected or disconnected.

> EDIT: Do you have a physical LINE OUT jack on your system? It seems that
> the LINE OUT is selected and enabled.

Could there be an extra line-out in the card that is not used/connected? If I understand it correctly, the log shows that there are 2 DACs (nodeid=13 and 14) and only the first one is being used by the player. Am I right?

> Can you try this test
> program which disables all the outputs excepting the internal
> speaker(s)?
Still no sound. Here's the output.

HDA: 5 Series/3400 Series Chipset HD Audio found.
HDA: i/o base found at 96930000.
HDA: i/o base mapped to 96930000, selector 00C7.
HDA: reset was succesful, codec mask: 0009, osd base 0100.
HDA: codec found, address 0000, vendor id 111D, device id 7605.
HDA: starting node id 0001, total number of nodes 1.
HDA: node id 0001 supports audio functions.
HDA: starting function/widget id 000A, total number of functions/widgets 25.
HDA: parsing node id 000A.
HDA: parsing node id 000B.
HDA: parsing node id 000C.
HDA: parsing node id 000D.
HDA: found pin type SPEAKER, node id 000D.
HDA: this pin doesn't support presence detection.
HDA: the number of connections for node id 000D is 3.
HDA: index 0 has node id 0013.
HDA: parsing node id 0013.
HDA: found DAC, node id 0013.
HDA: selected connection for node id 000D is index 0.
HDA: parsing node id 000E.
HDA: parsing node id 000F.
HDA: parsing node id 0010.
HDA: parsing node id 0011.
HDA: parsing node id 0012.
HDA: parsing node id 0014.
HDA: found DAC, node id 0014.
HDA: parsing node id 0015.
HDA: parsing node id 0016.
HDA: parsing node id 0017.
HDA: the number of connections for node id 0017 is 7.
HDA: index 0 has node id 000C.
HDA: index 1 has node id 000E.
HDA: index 2 has node id 000F.
HDA: index 3 has node id 001B.
HDA: parsing node id 001B.
HDA: the number of connections for node id 001B is 6.
HDA: index 0 has node id 000C.
HDA: index 1 has node id 000E.
HDA: index 2 has node id 000F.
HDA: index 3 has node id 0013.
HDA: selected connection for node id 001B is index 3.
HDA: selected connection for node id 0017 is index 3.
HDA: parsing node id 0018.
HDA: the number of connections for node id 0018 is 7.
HDA: index 0 has node id 000C.
HDA: index 1 has node id 000E.
HDA: index 2 has node id 000F.
HDA: index 3 has node id 001B.
HDA: selected connection for node id 0018 is index 3.
HDA: parsing node id 0019.
HDA: the number of connections for node id 0019 is 3.
HDA: index 0 has node id 0013.
HDA: selected connection for node id 0019 is index 0.
HDA: parsing node id 001A.
HDA: the number of connections for node id 001A is 1.
HDA: index 0 has node id 0019.
HDA: selected connection for node id 001A is index 0.
HDA: parsing node id 001C.
HDA: the number of connections for node id 001C is 1.
HDA: index 0 has node id 001B.
HDA: selected connection for node id 001C is index 0.
HDA: parsing node id 001D.
HDA: parsing node id 001E.
HDA: parsing node id 001F.
HDA: parsing node id 0020.
HDA: parsing node id 0021.
HDA: parsing node id 0022.
5 Series/3400 Series Chipset HD Audio
nominal rate : 48000 Hz
.......
.......
Khusraw

E-mail

Bucharest, Romania,
28.01.2012, 14:34

@ Deniska
 

New DJGPP Mplayer build from SVN

Post reply

I read your codec data sheet from https://www.idt.com/sites/default/files/documents/IDT_92HD81B_DST_20110919.pdf, and unfortunately it doesn't comply to the standard. It uses vendor specific "verbs" for setting the volume, selecting the connections etc., whilst lacking support for the entire "verb" set which any vendor should implement. I detest such lack of compliance, and personally I will not add support for this kind of deviations, at least certainly not for now.

---
Glory to God for all things
Khusraw

E-mail

Bucharest, Romania,
29.01.2012, 12:09
(edited by Khusraw, 29.01.2012, 14:43)

@ Deniska
 

New DJGPP Mplayer build from SVN

Post reply

I finally decided to make an exception and try to support your non-standard codec. I sent you a PM with a link for testing.

---
Glory to God for all things
Laaca

Homepage

Czech republic,
27.01.2012, 15:21

@ Khusraw
 

New DJGPP Mplayer build from SVN

Post reply

Thanks! Fantastic job!

It works without problems on both my DOS computers.
The only small issue I have is with -vo SVGA output.
I use CVidix, I also could use VESA but I have problems with SVGA. If I am in MPlayer directory (aka .\MPLAYER -vo VESA D:\FILMS\killbill.avi) - it works.
But if I am in another directory (aka C:\MPLAYER\MPLAYER -vo VESA .\killbill.avi) it does not work but complains about "libvga.cfg not found". I tried to set variables MPLAYER_HOME, HOME and SVGALIB_CONFIG_HOME but nothing helped.
Other config file (config.) loads without problems and font TTF file too.

---
DOS-u-akbar!
Khusraw

E-mail

Bucharest, Romania,
27.01.2012, 15:25

@ Laaca
 

New DJGPP Mplayer build from SVN

Post reply

> It works without problems on both my DOS computers.
> The only small issue I have is with -vo SVGA output.
> I use CVidix, I also could use VESA but I have problems with SVGA. If I am
> in MPlayer directory (aka .\MPLAYER -vo VESA D:\FILMS\killbill.avi) - it
> works.
Svgalib video driver support was removed.

---
Glory to God for all things
Laaca

Homepage

Czech republic,
28.01.2012, 21:32

@ Khusraw
 

New DJGPP Mplayer build from SVN

Post reply

> Svgalib video driver support was removed.
Why?
And how can I use it in your older builds? Where to place the LIBVGA.CFG file?

---
DOS-u-akbar!
Khusraw

E-mail

Bucharest, Romania,
29.01.2012, 09:46
(edited by Khusraw, 29.01.2012, 10:37)

@ Laaca
 

New DJGPP Mplayer build from SVN

Post reply

> Why?
Because almost all the cards are also supported by vidix, which brings much more. When I added support for it I was hoping that it will work with NVIDIA cards like the one I have, but it doesn't.

> And how can I use it in your older builds? Where to place the LIBVGA.CFG
> file?
http://www.bttr-software.de/forum/forum_entry.php?id=8838. BTW, the omploader link is still working.

---
Glory to God for all things
dalmudlee

01.02.2012, 16:28

@ Khusraw
 

New DJGPP Mplayer build from SVN

Post reply

RE: SVN-r34600
Hi,
Referenced build only plays mono w/stereo audio file.
Video is DOA.
THX
Mr. Lee
~~~~~~~~~~~~~
Khusran SVN-r34600 error LOG w/VESA 2.0 emulation:
SolVBE VDD DLL Version 1.3b, September 15, 2004
Copyright 2004 Jari Komppa
http://sourceforge.net/projects/solvbe/

Setting video interrupt..
Setting mouse interrupt..
Setting irq12 interrupt (0x74)..
Going resident..
Starting cache process/thread failed: Not enough memory (ENOMEM).
[flv @ 363a30]max_analyze_duration 5000000 reached at 5044000
Requested audio codec family [mpg123] (afm=mpg123) not available.
Enable it at compilation.
DVB card number must be between 1 and 4

MPlayer interrupted by signal 291 in module: decode video
- MPlayer crashed by bad usage of CPU/FPU/RAM.
Recompile MPlayer with --enable-debug and make a 'gdb' backtrace and
disassembly. Details in DOCS/HTML/en/bugreports_what.html#bugreports_crash.
- MPlayer crashed. This shouldn't happen.
It can be a bug in the MPlayer code _or_ in your drivers _or_ in your
gcc version. If you think it's MPlayer's fault, please read
DOCS/HTML/en/bugreports.html and follow the instructions there. We can't and
won't help unless you provide this information when reporting a possible bug.
~~~~~~~~~~~~~~~
HARDWARE:
00:14.5 Multimedia audio controller [0401]: ATI Technologies Inc IXP SB400 AC'97 Audio
00:18.0 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
HyperTransport Technology Configuration [1022:1100]
01:05.0 VGA compatible controller [0300]: ATI Technologies Inc Radeon XPRESS 200M 5955
(PCIE) [1002:5955]
(rev 10)
~~~~~~~~~~
OS: Windows XP
~~~~~~~~~~~
GRX248 scan w/VESA graphics device:
*47 VESA modes, e.g.,non-interlaced, BGI emulation, etc.
*16 available colours
http://grx.gnu.de/
DJGPP build:
MainWindow( "Status report after InitGraph" );
settextjustify( LEFT_TEXT, TOP_TEXT );
driver = getdrivername();
mode = getmodename(GraphMode); /* get current setting */
gprintf( &x, &y, "Graphics device : %-20s (%d)", driver, GraphDriver );
gprintf( &x, &y, "Graphics mode : %-20s (%d)", mode, GraphMode );
#ifdef __GNUC__
gprintf( &x, &y, "Available pages : %d", get_BGI_mode_pages() );
#endif
gprintf( &x, &y, "Screen resolution : ( 0, 0, %d, %d )", getmaxx(), getmaxy() );
gprintf( &x, &y, "Current view port : ( %d, %d, %d, %d )",
viewinfo.left, viewinfo.top, viewinfo.right, viewinfo.bottom );
gprintf( &x, &y, "Clipping : %s", viewinfo.clip ? "ON" : "OFF" );
gprintf( &x, &y, "Current position : ( %d, %d )", getx(), gety() );
gprintf( &x, &y, "Colors available : %d", MaxColors );
gprintf( &x, &y, "Current color : %d", getcolor() );
gprintf( &x, &y, "Line style : %s", LineStyles[ lineinfo.linestyle ] );
gprintf( &x, &y, "Line thickness : %d", lineinfo.thickness );
gprintf( &x, &y, "Current fill style : %s", FillStyles[ fillinfo.pattern ] );
gprintf( &x, &y, "Current fill color : %d", fillinfo.color );
gprintf( &x, &y, "Current font : %s", Fonts[ textinfo.font ] );
gprintf( &x, &y, "Text direction : %s", TextDirect[ textinfo.direction ] );
gprintf( &x, &y, "Character size : %d", textinfo.charsize );
gprintf( &x, &y, "Horizontal justify : %s", HorizJust[ textinfo.horiz ] );
gprintf( &x, &y, "Vertical justify : %s", VertJust[ textinfo.vert ] );
gprintf( &x, &y, "Aspect ratio : %lf", AspectRatio);
getviewsettings( &viewinfo );
{
int ybase;
setfillstyle(SOLID_FILL, BLACK);
if (MaxY<350-1) {
x = 400;
y = 4;
fmt = "#%-3d: %s";
} else {
y += 5;
fmt = " Mode #%-3d : %s";
}
gprintf( &x, &y, "Available modes :");
y += 5;
ybase = y;
for (mno = 0; mno <= getmaxmode(); ++mno) {
char sp[100];
sprintf(sp, fmt, mno, getmodename(mno));
bar(x-4, y + textheight(sp), x+textwidth(sp)+4, y);
gprintf( &x, &y, "%s", sp);
if (y+viewinfo.top>viewinfo.bottom-8) {
y = ybase;
x += (viewinfo.right-viewinfo.left) / 2;
}
}
}
Pause(); /* Pause for user to read screen*/
}
~~~~~~~~~~~~~~~
Khusraw

E-mail

Bucharest, Romania,
01.02.2012, 17:09

@ dalmudlee
 

New DJGPP Mplayer build from SVN

Post reply

> RE: SVN-r34600
> Hi,
> Referenced build only plays mono w/stereo audio file.
> Video is DOA.
> THX
> Mr. Lee
1. I don't know what "DOA" means, "dead or alive"?
2. You receive an ENOMEM.
3. Video will not work in Windows XP, as near pointers are not allowed.
4. You don't have a correct config file in "mplayer" subdir, so it tries to use ao mpegpes instead of ao wss.
5. It doesn't work correctly yet with external binary codecs.

---
Glory to God for all things
dalmudlee

01.02.2012, 18:33

@ Khusraw
 

New DJGPP Mplayer build from SVN

Post reply

> 1. I don't know what "DOA" means, "dead or alive"?
> 2. You receive an ENOMEM.
> 3. Video will not work in Windows XP, as near pointers are not allowed.
> 4. You don't have a correct config file in "mplayer" subdir, so it tries to
> use ao mpegpes instead of ao wss.
> 5. It doesn't work correctly yet with external binary codecs.
 Hi,
Since video is Dead On Arrival, due to near pointers, I will
focus on audio. Stereo files still play in mono.
Can stereo be functional?
Thanks for reply!
~~~~~~~~~~
SVN-r34600 error LOG:
SolVBE - VESA VBE for Win32 dos boxes - http://iki.fi/sol/

SolVBE DOS TSR Version 1.1b, March 10, 2004
Copyright 2004 Jari Komppa

Registering VDD..

SolVBE VDD DLL Version 1.3b, September 15, 2004
Copyright 2004 Jari Komppa

Setting video interrupt..
Setting mouse interrupt..
Setting irq12 interrupt (0x74)..
Going resident..
Starting cache process/thread failed: Not enough memory (ENOMEM).
DVB card number must be between 1 and 4
~~~~~~~~~~~~~~~~
CONFIG switches:
ao=wss
vo=vesa
double=yes
zoom=yes
fs=yes
framedrop=yes
~~~~~~~~~~~
Khusraw

E-mail

Bucharest, Romania,
01.02.2012, 18:40
(edited by Khusraw, 01.02.2012, 19:48)

@ dalmudlee
 

New DJGPP Mplayer build from SVN

Post reply

> Since video is Dead On Arrival, due to near pointers, I will
> focus on audio. Stereo files still play in mono.
> Can stereo be functional?
Stereo is functional. Put a correct config file where it should be (the message "DVB card number must be between 1 and 4" tells that you don't have a correct config file where it should be) and use it in other environment than Windows XP. This is Mplayer for DOS, not for Windows XP. Windows XP emulates a SB 2.01 which will play mono higher sampling rates. If you want stereo use -srate with a sampling rate for which SB 2.01 supports stereo.

---
Glory to God for all things
Khusraw

E-mail

Bucharest, Romania,
04.02.2012, 23:08
(edited by Khusraw, 05.02.2012, 00:05)

@ Khusraw
 

Final Mplayer DJGPP build for this "season"

Post reply

Because of lack of time, this will be my final DJGPP build of mplayer for this "season".
What's new:
* upgraded the FFmpeg libraries to those from v 0.10.
* some more or less important fixes in HDA support for WSS. Please keep in mind that I have no time for wasting, and if it doesn't work for you, this means that your codec has particularities which makes it unable to work with a "generic" HDA support. If you really want support for your tricky codecs, add it yourselves, nobody is born learned, but you may learn the things for which you have a real interest, as I have always done.
* now support for external Windows codecs is complete and reliable. I tested with drvc.dll and ivvideo.dll and everything works as expected. Put the Windows dlls in the "codecs" subdir or pass the "codecpath" variable.
* now vo vesa defaults to NOT saving the video state. Use "savestate" if you want the video state to be saved and restored.
* now vesa:nodga will correctly use banked video instead of LFB, if you have reasons for this.
You may download the source code from here, and the binaries from here.

---
Glory to God for all things
Zyzzle

06.02.2012, 06:39

@ Khusraw
 

Final Mplayer DJGPP build for this "season"

Post reply

Thanks for your "final" build for now! I'm happy and inspired by your words to learn what really matters and is interesting. Making the most of DOS is right up there on the list.

@RayeR

Thanks, will test and report back. Perhaps I should create a new thread with the logs and future progress on the MTRR mystery. Also, I can test on a friend's i5 system (specs = 6 GB of RAM and Radeon 6300 video?) if that will help any more to troubleshoot.
Khusraw

E-mail

Bucharest, Romania,
06.02.2012, 09:54

@ Zyzzle
 

Final Mplayer DJGPP build for this "season"

Post reply

> Thanks for your "final" build for now! I'm happy and inspired by your words
> to learn what really matters and is interesting. Making the most of DOS is
> right up there on the list.
Well, I hope that now it works with your ICH7 HDA card, and that using vesa:nodga will show something other than the black screen. I was referring to the fact that yes, I know that it doesn't support all the HDA cards, but many codecs require non-standard verbs or special initialization commands. For example ALSA uses specific configuration scripts and "patches" for supporting such codecs. Personally I will never add support for them, due to both lack of time and lack of interest.

---
Glory to God for all things
Khusraw

E-mail

Bucharest, Romania,
08.02.2012, 17:15

@ Khusraw
 

Yet another small update

Post reply

You may download the source code from here, and the binaries from here.
In case you have installed the external Windows codecs package, available from http://www.mplayerhq.hu/MPlayer/releases/codecs/, you may experience some crashes with certain WMV DMO encoded files. It is a known mplayer bug. In order to avoid such crashes, use mplayer with "-vfm ffmpeg" (or "vfm=ffmpeg") when running those files.

---
Glory to God for all things
glennmcc

Homepage E-mail

North Jackson, Ohio (USA),
11.02.2012, 00:53

@ Khusraw
 

Yet another small update

Post reply

> You may download the source code from
> here, and the binaries from
> here.
> In case you have installed the external Windows codecs package, available
> from
> http://www.mplayerhq.hu/MPlayer/releases/codecs/,
> you may experience some crashes with certain WMV DMO encoded files. It is a
> known mplayer bug. In order to avoid such crashes, use mplayer with "-vfm
> ffmpeg" (or "vfm=ffmpeg") when running those files.
It works great here on this P4-2.6ghz machine running OpenDos v7.01

Thank you !
ron

Homepage E-mail

Australia,
11.02.2012, 07:56

@ glennmcc
 

Yet another small update

Post reply

> It works great here on this P4-2.6ghz machine running OpenDos v7.01
And here on my AMD K6 600 MHz running MS-DOS 6.20.
It even streams from youtube when called by Arachne.

Ron

---
AUSREG Consultancy http://www.ausreg.com
Tadpole Tunes http://www.tadpoletunes.com
Sna Keo Il http://www.tadpoletunes.com/sna_keo_il/
DOS386

24.02.2012, 01:52

@ Khusraw
 

Yet another small update | OMP | works mostly

Post reply

> New DJGPP Mplayer build from SVN
Thanks :-)

> You may download the source code from
> http://ompldr.org/vY3A4Mg and the binaries from http://ompldr.org/vY3A4NA
they switched back:

http://omploader.org/vY3A4Mg and the binaries from http://omploader.org/vY3A4NA

Minimal test results:

* Source code available (lack of source used to cause problems in the past) :-)

* No sound (most likely bad PC with card not on the list, I'll try other later)

* Theora-mirror-BUG fixed

* Theora-offset-BUG still in (99% of binaries have it too, but 1% (by Mik IIRC) don't ... lost patch ... http://ffmpeg.org/ wrote:

> January 24, 2012, Forgotten Patches
> FFmpeg development has gone into OVERDRIVE. Over the years we
> have missed patches, so we need your help to locate old unapplied
> patches to review again.
> If you find a patch that was never applied, please let us know,
> either by resubmitting it to ffmpeg-devel or by attaching it to a
> bug on our bug tracker.
* Vidix driver correctly identifies my card but doesn't switch mode (old-hat BUG ?)

* Video sometimes flickering (??? related to no sound ???)

* One movie (FLV 320 * 175 http://jafile.com/uploads/dos386/fluid.zip) causes fullscreen (??? new BUG ???)

* -really-quiet is -really-badly needed oterhwise not only messy output (as always in the past) but even more damage (memory corruption ??? hangs ??? fails to switch back to text mode "vesa" when done ???)

* Still "theft" of some frames or complete movie if very short ... because monitor takes ages to recover from mode switch ... would it be possible to add a delay after mode switch (2 s ?) before playing and another one after last frame (1 s ?) before switch back to text mode ?

* XXX264-CMOVNTQ-BUG not tested http://omploader.org/vN2c4Mw/BALLMERA.FLV

* Some movies do play (YUV, Theora, WebM, MP0-MPEG4-XXX264, ...)

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

E-mail

Bucharest, Romania,
24.02.2012, 13:05

@ DOS386
 

Yet another small update | OMP | works mostly

Post reply

> * No sound (most likely bad PC with card not on the list, I'll try other
> later)
With which sound card?

> * Vidix driver correctly identifies my card but doesn't switch mode
> (old-hat BUG ?)
Use vesa:vidix to have the mode switched, vidix doesn't set video modes, as was already told here not only once.

> * Video sometimes flickering (??? related to no sound ???)
> * One movie (FLV 320 * 175
> http://jafile.com/uploads/dos386/fluid.zip) causes fullscreen (??? new BUG
> ???)
Those depend on your configuration file/command line options.

> * -really-quiet is -really-badly needed oterhwise not only
> messy output (as always in the past) but even more damage (memory
> corruption ??? hangs ??? fails to switch back to text mode "vesa" when done
> ???)
This perhaps depends on video card, e.g. with my Intel 945GM there is no such a problem even if I run it with -msglevel all=9.

> * Still "theft" of some frames or complete movie if very short ... because
> monitor takes ages to recover from mode switch ... would it be possible to
> add a delay after mode switch (2 s ?) before playing and another one after
> last frame (1 s ?) before switch back to text mode ?
It is possible, you may put the delays in "vo_vesa.c".

---
Glory to God for all things
DOS386

05.03.2012, 07:47

@ Khusraw
 

Yet another small update | OMP | works mostly

Post reply

> > * No sound (most likely bad PC with card not on the list, I'll try other later)
> With which sound card?
ES1371 ... other PC, got sound, ICH LDA :-) (except Vorbis, see below)

> Use vesa:vidix to have the mode switched, vidix doesn't set video modes, as
> was already told here not only once
Right, had forgoten :-(

> > * Video sometimes flickering (??? related to no sound ???)
NO. It's NOT related to no sound. Codec problem?

There is one more problem: if Theora video has Vorbis sound and sound card is suported, it crashes, not even "-ac null" helps. Audio-only OGG Vorbis files are OK.

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

E-mail

Bucharest, Romania,
05.03.2012, 09:02
(edited by Khusraw, 05.03.2012, 09:42)

@ DOS386
 

Yet another small update | OMP | works mostly

Post reply

> There is one more problem: if Theora video has Vorbis sound and sound card
> is suported, it crashes, not even "-ac null" helps. Audio-only OGG Vorbis
> files are OK.
I can't reproduce this. All the vorbis+theora encoded files I tried work without problems on my systems, with sound (e.g. those from here). Can you provide a link to such a crashing file?

---
Glory to God for all things
DOS386

11.03.2012, 15:57

@ Khusraw
 

OMP | works mostly | OGG Theora+Vorbis issues

Post reply

> > There is one more problem: if Theora video has Vorbis sound and sound
> > card is suported, it crashes, not even "-ac null" helps. Audio-only OGG
> > Vorbis files are OK
> I can't reproduce this. All the vorbis+theora encoded files I tried work
> without problems on my systems, with sound (e.g. those from
> here). Can you
> provide a link to such a crashing file?
Most likely this is not specific to the file but the system, crashing file (exploits the offset-BUG too, see bottom):

http://jafile.com/uploads/dos386/ff5years.ogv 24 MiB

It does NOT crash if I send the video into PNG or YUV4MPEG ... sounds plays OK and when done I can separately view the video from the YUV4MPEG file :-( Maybe it initializes the sound output hardware even if I specify "-ao null -ac null" ? It does not crash if no supported soundcard is found. Looks like a silly resource conflict: real sound output + VESA + OGG -> BOOM . If I omit "-really-quiet" then it says "crash in decode video" :-|

Another BUG: "-vo png" doesn't work if in main directory (IIRC this is another MPLAYER-old-hat-BUG ...).

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

E-mail

Bucharest, Romania,
11.03.2012, 16:18

@ DOS386
 

OMP | works mostly | OGG Theora+Vorbis issues

Post reply

> Most likely this is not specific to the file but the system, crashing file
> (exploits the offset-BUG too, see bottom):
>
> http://jafile.com/uploads/dos386/ff5years.ogv
I can see the offset bug, but on my systems it doesn't crash, it plays well, with the sound enabled.

> Another BUG: "-vo png" doesn't work if in main directory (IIRC this is
> another MPLAYER-old-hat-BUG ...).
This may be a problem specific to my DJGPP build, I never looked on the vo_png file. I will look, when I will find time.

---
Glory to God for all things
DOS386

13.06.2012, 11:28

@ Khusraw
 

MPLAYER 1.1 is out 2012-Jun-10

Post reply

http://mplayerhq.hu/design7/news.html

there will never be 1.0-final :clap:

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

E-mail

Bucharest, Romania,
14.06.2012, 20:33

@ DOS386
 

MPLAYER 1.1 is out 2012-Jun-10

Post reply

> http://mplayerhq.hu/design7/news.html
>
> there will never be 1.0-final :clap:
In what I am concerned, I am very busy with other things during these times and unfortunately, temporary I can't pursue my DOS hobbies. I provided the whole source code for my builds, so if someone is interested he may try to compile v 1.1 (I don't think that something has been changed in the system-dependent code).

---
Glory to God for all things
Back to index page
Thread view  Board view
22632 Postings in 2109 Threads, 402 registered users, 550 users online (0 registered, 550 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum