Hi,
I thought I would try this
First a question asked on the Forum that did not get a reply:
- PCM volume is being turned down to 0 which is very annoying
Where do I change these settings?
SetDigitalAudioDevice: 0 SetAudioChannelDevice: 0
The new versions of VDR and xine plugin:
- xine CPU usage is up 10% from 35% to 45% on my Epia M10000. I am using xine-lib 1.1.8 and the CVS version of xine-ui (I could not log into CVS this morning to get xine-lib)
- when it works it seem very fluid and zapping seems faster - any attempt at using the xine configuration dialog results in a lock up - vdradmin 3.6.0 am has problems staying connected to VDR
This is what I saw in about 15 minutes of use.
Cheers
Tony
Hi,
Tony Grant wrote:
First a question asked on the Forum that did not get a reply:
- PCM volume is being turned down to 0 which is very annoying
Where do I change these settings?
SetDigitalAudioDevice: 0 SetAudioChannelDevice: 0
These commands from VDR don't change the volume. Have a look for
SetVolumeDevice: 175
In vdr-xine's setup menu, you can control how vdr-xine handles volume control.
An excerpt from vdr-xine's MANUAL:
Control xine's volume: Yes (by hardware)
Allows you to control whether xine shall honor VDR's set volume requests. You might need this if you have a special setup (e. g. external audio decoder or amplifier) where changing the volume in xine might mute external audio:
* No xine isn't instructed to change the volume. * Yes (by hardware) xine will change the volume by changing the hardware mixer (won't work when using a digital audio output). * Yes (by software) xine will change the volume by using it's internal software mixer (should work even when using a digital audio output).
Muting: Simulate
Lets you choose among several options how xine shall process VDR's muting requests:
* Ignore Muting respectively unmuting requests will be ignored. * Execute Muting respectively unmuting requests will be executed. * Simulate Muting is simulated by setting volume to 0. Unmuting is simulated by restoring the previous volume.
NOTE: This happens even if "Control xine's volume" is set to "No"!
The new versions of VDR and xine plugin:
- xine CPU usage is up 10% from 35% to 45% on my Epia M10000. I am
using xine-lib 1.1.8 and the CVS version of xine-ui (I could not log into CVS this morning to get xine-lib)
Do I get it right: it increased from 10% to 35% - 45%?
- when it works it seem very fluid and zapping seems faster
... seems faster than what?
- any attempt at using the xine configuration dialog results in a lock
up
Cannot reproduce this here.
- vdradmin 3.6.0 am has problems staying connected to VDR
I'm sorry, I do not have any test results here so far.
Bye.
Hi,
Tony Grant schrieb:
- any attempt at using the xine configuration dialog results in a lock
up
Hmm, I've upgraded to openSUSE 10.3 this morning. I now get such dead locks when using -V xxmc. The deadlock happens for "simple" libX11 functions like XLockDisplay() or XSync(). One change in openSUSE 10.3 seems to be, that it now uses a xcb-based libX11.
Is there some similarity to your system?
Which one of xine's video output drivers do you use?
Have you tried --verbose=2 -V xv and verified from the output, that video_out_xv is used?
Bye.
Le vendredi 19 octobre 2007 à 19:48 +0200, Reinhard Nissl a écrit :
- any attempt at using the xine configuration dialog results in a lock
up
Hmm, I've upgraded to openSUSE 10.3 this morning. I now get such dead locks when using -V xxmc. The deadlock happens for "simple" libX11 functions like XLockDisplay() or XSync(). One change in openSUSE 10.3 seems to be, that it now uses a xcb-based libX11.
Is there some similarity to your system?
Fedora Core 6
It is stable since last post but I am just watching TV not messing with Xine...
Which one of xine's video output drivers do you use?
I am just running with -V xxmc on an epia M10000 with Openchrome driver
Have you tried --verbose=2 -V xv and verified from the output, that video_out_xv is used?
No I have a timer running so I will try in the morning
Cheers
Tony