• Welcome to OS2World OLD-STATIC-BACKUP Forum.
 

News:

This is an old OS2World backup forum for reference only. IT IS READ ONLY!!!

If you need help with OS/2 - eComStation visit http://www.os2world.com/forum

Main Menu

smplayer for os/2 ecs

Started by Saijin_Naib, 2008.10.15, 18:30:56

Previous topic - Next topic

Pete

Hi Dave

Would you Please be so kind as to report this to Silvan as he is unable to duplicate the screen redraw problems I have described to him - I also supplied some jpgs to illustrate the problem.

At least then he will know I am not the only person seeing the problem and, hopefully, he will then look into look into fixing the problem.

I also find resizing the playback window shows the screen redraw problem.

Regards

Pete


IBManners

Just a reminder to all,

As a generalisation,

If you have a ATI card and use the SNAP drivers ao=kai:uniaud
should work fine when selected for MPlayer.

If you have a NVidia card and use the SNAP drivers ao=kai:dart
should work fine when selected for MPlayer.

The SNAP drivers do not support NVidia cards to the same extent
that they support ATI cards due to code access.
I am the computer, it is me.

Pete

Hi

The build of uniaud HDA that works best on my system is not really up to the job.

Although I am using SNAP with an ATI X800 KO Myung-Hun recommended using ao=kai:dart on my system due to the uniaud build in use.

Regards

Pete

diver

as long as you use a older uniaud for HDA you will always see some strange problems with smplayer.
please try at least 1.9.22 or better, as this should fix a lot of stuff. And then you can use kai:uniaud

rudi

Quote from: diver on 2010.05.31, 11:58:01
as long as you use a older uniaud for HDA you will always see some strange problems with smplayer.
please try at least 1.9.22 or better, as this should fix a lot of stuff. And then you can use kai:uniaud

What is actually the advantage of the UNIAUD API  vs. DART ?  I never understood, why it was
necessary to add a special API to a sound driver when there is already something present in
the OS that can do the job...

diver

Rudi,

the uniaud api talks direct to the driver (32 bit part), while DART uses the 16 bit part to talk to the 32 bit part. all i can say is that with the uniaud api i have never had a hang in HDA, while using the DART api i had hangs. With the current uniaud driver also those hangs are mostly gone. what i still have with the DART api are sound loops, while with the uniaud api i never have those. i see them mostly with emperoar tv , when i have a not so good connection.

regards
Silvan

rudi

Hi Silvan,

Quote from: diver on 2010.05.31, 13:28:57
all i can say is that with the uniaud api i have never had a hang in HDA, while using the DART api i had hangs. With the current uniaud driver also those hangs are mostly gone.

Which makes me believe that there was a bug in the DART implementation, which should have been fixed instead of forcing application developers to use a new API...

Quote from: diver on 2010.05.31, 13:28:57
what i still have with the DART api are sound loops, while with the uniaud api i never have those. i see them mostly with emperoar tv , when i have a not so good connection.

Yeah, I'm aware of this problem. It has been introduced with the RC5-version of UNIAUD16.SYS and became even worse later on. But again: preferable UNIAUD should have been fixed to behave like any other sound driver on OS/2 (and like it did prior to RC5). BTW, I just tested the latest 1.9.22 release on an AC'97 system: It's pretty much unusable with ETV... Back to 1.1.4RC4, which - just like the native SBLive! or C-Media drivers - works perfectly O.K.


diver

Rudi,

of course you are right about being a bug in the DART implementation. But is looks like it's hard to be found. As it's only for HDA systems. For me the 1.9.22 version works almost perfect, but not with emperoartv :( i still have looping sound there. but i have to ry the latest version from svn, as there seems to be some problems fixed.

rudi

Hi Silvan,

recently a new guy has started working on UNIAUD. Rumors say, that he already fixed some stuff in UNIAUD16...

BTW, did you try to combine version 1.9.22  of UNIAUD32 with UNIAUD16 from 1.1.4RC6 or  1.1.4RC4 ? This might fox the looping problems with ETV as well.


Pete

Hi

i had a response from Silvan about the screen redraw problems I'm seeing here.

He suggested using this setting, either in config.sys or on a command line used to start smplayer:-

SET QT_PM_NO_DIVE=1

I added that to config.sys, rebooted and the screen redraw problems seem to have gone.

Silvan also said this is not an smplayer problem but a QT problem specific to some systems.

Regards

Pete



Andi

Quote from: Pete on 2010.06.07, 01:45:29
...
SET QT_PM_NO_DIVE=1
...
Thanks Pete that did the trick for my ATI X300 and Snap where the newest smplayer were nearly unusable otherwise.

David McKenna

 Thanks, Pete... that fixed it here too...

Regards,

Dave McKenna

Pete

Hi Dave

Out of interest: Are you using an ATI X??? graphics card and Snap?

I ask because Andi is using "ATI X300 and Snap" and I'm using ATI X800 and Snap.

Just wondering If ATI and Snap are the "QT problem specific to some systems" mentioned by Silvan.

Regards

Pete

David McKenna

Pete,

  Yes... ATI Radeon 9600 AGP. I have this on both my desktop and laptop. Both use SNAP. QT_PM_NO_DIVE fixes the window corruption in SMPlayer (haven't seen it anywhere else yet) on both.

Regards,

Dave McKenna

Andi

Update - even with QT_PM_NO_DIVE not all problems are gone. Sometimes the space were the video should be drawn remains black until I move another window over it. After that it starts repainting as usual. But the bottom menu bar (volume, track position, start/pause...) are corrected with this setting.

Another problem is, machine hangs after some time. 10-20min ? WPS is completely unusable then. No CAD session (2 times CTRL-ALT-DEL reboots). But netbios and tcp/ip are working. Seems a video problem too or another uniaud problem?