| |
News
About
FAQ
Howto
Download
Links
Developers
Project Page
|
|
Notes from email
> I tried to use your HOWTO, read it carefully but practically my attempt ended,
> when I ran 'make config ; make dep' in kernel
> source tree, because I didn't understand 99% of question it asked me...
> So I was just pressing enter, hoping that defaults are reasonable...
it's important that the linux source tree you are using agree with the kernel you are
running. i use Redhat 7.1 and they distribute config files that come with the various
stock kernels. i just pick the one that agrees with the name of the kernel i'm using.
(they are found in the configs directory) if you have x-windows (and you must)
you should better run 'make xconfig' instead of make config. select the 'load
configuration' button and load a config file that agrees with your kernel. now save
and exit. now when you run 'make dep' the dependencies also agree with your
kernel. after that go back and 'make clean && make' in the em8300/modules
directory and report back what happens. make-modules-2.4 is depricated, use
'make' instead. other mandrake users can probably be better help but this is how it's
done under Redhat. as an aside, when you go through the whole process of building
your own kernel (don't forget to save a config file for it) and running the kernel you
build you have the source tree in just the same condition, in total agreement with the
kernel. Redhat just makes it so you can simulate this condition by supplying config files
for the stock kernels. the catch seems to be that you have to say 'make dep' in the source
directory to build modules for that kernel. just make sure you aren't building modules for
some Other kernel.
As far as I can tell, the dxr3 has no mixer or volume control onboard.
The theory is that the windows driver adjusts the audio samples to control
volume. We could do it if someone felt like writing the code (write the
function, call it in preprocess_*, add an ioctl to set the volume).
I have the audio running into my soundcard and adjust the volume there.
If it's hooked up to my stereo/tv I use that. I think it'd only be a
problem if someone plugged in headphones without an amp.
xine_dxr3 opens /dev/em8300_mv and /dev/em8300_ma, demuxes the input
stream and sends the video and audio streams to the corresponding
device. It also calls the setpts ioctl's at the appropriate times so
the driver knows when the data it's receiving should be presented.
The em8300 module receives the data that is written to the devices and
adds it to the fifo's that are read by the dxr3 hardware (one for audio,
one for video, one for spu). For the video and spu there is also a
second type of fifo which contains the pts values so the hardware knows
when to display the data. There is no such pts fifo for the audio
(AFAIK).
The audio syncing occurs when audio data is written to the
/dev/em8300_ma device, not when it is played. Essentially, the write
function checks the pts values of the data being written against
(the SCR + total pts of buffered audio data) to see if we're in sync.
If not, it adjusts the SCR by the differnece to get back in sync. The
algorithm is actually more complicated than that because it's handling
pts rollovers as well. Ideally we want a mechanism where the driver
doesn't care about pts rollovers and never resets/modifies the SCR on
the card (except when playback is stopped of course).
What I want to do is move this logic to Xine rather than the driver.
I'm just afraid it would require rewriting Xine's syncing (unless the
cvs version is more like what we need, I haven't looked at it yet). In
addition, I think it would be better if we're not too far out of sync to
gradually insert or drop samples to correct it so the correction is not
very noticable. Perhaps it'd be possible to adjust the pts values of
the video to make the necessary minor adjustments..
If we're way out of sync we can take more drastic measures.
I've done some initial work in ripping the audio syncing out of the
driver and adding the OSS ioctl's but I haven't been able to finish and
make the necessary changes to Xine's syncing yet. I'm wary about
checking in the changes I have now as it would break syncing for anyone
using the cvs drivers. Of course, I can release a 0.7.3 with the
changes that are currently in cvs and people can use that..
The PTS (Presentation Time Stamp) values are 33bit numbers based on a
90khz clock. They tell when some video or audio should be presented.
They can go for about 24hours before wrapping, but will often reset
between episodes or chapters on a dvd.
The SCR (System Clock Reference) is what the PTS values are based
on/synchronized to. I don't know if the windows driver adjusts the SCR.
There is most definately data in the FIFO's waiting to be played/being
played when we change it. I don't know what the behavior of the card is
defined to be when the SCR is changed. From observation: if you adjust
the SCR forward I think it will skip data or maybe just play faster. If
you adjust the SCR backwards it will wait until the video PTS matches
the SCR to play more data (video will appear to freeze and writes to the
device will block when the fifo fills).
To write data to the card, we read a writeptr address from a register on
the card. This gives us the address of a fifo on the card. Each
element of this fifo contains a memory address and a buffer size.
To send data to the card we set the memory address to the address of a
buffer containing the data and set the buffer size to the size of this
buffer. There are also some flags for the video fifo, but I don't know
offhand what they do. We keep track of the number of free slots in the
driver so we don't overwrite data when it gets full. When we get to the
end of the FIFO we wrap around to the beginning (using modulus
operator).
Basically you need to look at em8300_fifo.c (and grep for the
em8300_fifo_* function calls in the other code). This was written by
Henrik, I've just explained what I know from reading it.
To use overlay:
Currently, your display size must be equal to your monitor resolution.
The only exception is if you have more than once monitor in xinerama
mode edit autocal.c and dxr3view.c to change MONITOR_NUM to however many
monitors you have.
start xine_dxr3 (to upload microcode)
run autocal (if you've never run it before)
run dxr3view
hit play
The microcode needs to be uploaded to use autocal. Do not run autocal
while the video is playing.
On Thu, Apr 19, 2001 at 11:09:08PM +0300, Samuli Sorvakko wrote:
>
> Is there something badly wrong in the sync code (version 0.7.0) or is it
> just me?
> When I try to play an mpg stream (any mpg stream goes) with xine, it
> outputs a few of the first frames and then the picture halts (TV
> mode). Kernel messages show a _mass_ of 'dropping frames' -messages and
> about nothing else. Is there something I might have overlooked?
The current driver requires the pts values to be continuously
increasing. About 1/4 or more of my mpeg's have pts values that shift
backwards briefly. I consider the encoder that made these broken but
just about every decoder plays them fine. The 'dropping frames'
messages are where the driver detected a slight backwards pts shift and
dropped the data. It didn't help.
I'm going to work on it again eventually because it bugs me, but it's
not high on the todo list.
DVD menu's are implemented using small mpeg streams with spu streams for
the highlighting. It also uses a sort of machine code for all the
actions. Nobody yet has a functioning implementation for linux so I
can't say exactly.
Perhaps I can help shed a little light on the matter... When going
through the disassembly of the windows driver, One of the initialization
things is a fairly convuluted set of tests/calculations performed on the
values read from a couple of registers. These are used to computer, for
the lack of a better word, a sub-version of the card. This number can
take on several different values, for instance, 15, 17, and I think 16,
all for the same board revision (1 and 2 in the current linux driver).
I've been meaning to check that my C version of it is right for some time
and contribute it to the project. This magic number is also what is used
to determine which microcode should be uploaded to the card, 0, 1, or 2.
This is probably important. the magic number is also used in a HUGE HUGE
HUGE number of places to determine what routine to run in a certain
situation, etc. If you have windows installed, you can find out the value
of this magic number for your card by using regedit. Look at the sigma
designs keys. I think that they are in
HKEY_LOCAL_MACHINE/Software/SigmaDesigns/REALMagic. One of the key names
(either after REALMagic or between Sigmadesigns and REALMagic, you'll see
what I mean) is a number. This is the "magic number" computed from this
routine. sub-version, whatever you want to call it. Perhaps it would be
beneficial from now on, at least until I can get this stuff converted
(give me a week), for people to find out their "Magic Number" when
reporting problems that seem to vary between the same revision of the
board. If these magic numbers coincide with the problems, I think we'll
have hit on the solution to this large stumbling block. Time will tell.
> Running Red Hat 7.1 - kernel 2.4.2-2
> In file included from /usr/src/linux-2.4.2/include/linux/spinlock.h:35,
> from /usr/src/linux-2.4.2/include/linux/module.h:11,
> from em8300_main.c:20:
> /usr/src/linux-2.4.2/include/asm/spinlock.h:8: nondigits in number and
i had this problem too. under Redhat 7.1 make sure you have a soft link
to the sources in
/usr/src/linux
"cd /usr/src"
"ln -s linux-2.4.2-2 linux"
this isn't all that necissary and it looks like you've found a way
around this but it does make
things a lot easier. then in your sourc directory do
"make clean"
"make mrproper"
"make menuconfig"
go to the bottom of the menu and select 'load configuration'
in the dialog box enter 'configs/kernel-2.4.2-i686-smp.config'
note that i need the smp kernel, if you don't then enter the kernel you
are using. all the
distributed kernels are listed in /usr/src/linux/configs. the fact that
you are seeing a spinlock
error makes me think that you are using an smp kernel as well.
then exit the program, saving your changes.
now do
"make dep"
and now the spinlock and other errors associated with nodigits should
dissapear.
go back to your project and see if it doesn't work now.
> BTW, do you know how MVCOMMAND_SYNC works? It seems some xine
> developer discovered it and never told us in the dxr3 project about
> it. So it's been undocumented up until I read your sources. I've
> added some small info on how I thought it worked but if you know
> anything relevant please let me know.
IIRC the MVCOMMAND_SYNC was introduced by Harm van der Heiden. Since he
apparently left the xine project at the beginning of the year, I took
over the maintenance of the dxr3 code. Current xine actually makes
quite heavy use of MVCOMMAND_SYNC. I made some experiments and it seems
to be an alternative play mode that should be used when the stream is
in sync. What happens is: When issuing MVCOMMAND_PLAY, the dxr3
switches to a play mode, where it seems to stick to the delivered PTS
very strictly. This sometimes causes the field order to change, when a
frame gets displayed for 3 instead of 2 fields (because the next
frame's PTS dates it a bit later). The next one is then shown for 1
field only, I guess. When that happens, the image jumps slightly on the
TV. But when issuing MVCOMMAND_SYNC, the dxr3 seems to disregard the
PTS values to some extent and play more by framerate. That way, the
playback is much smoother, because none of these field jumps happen.
What xine's dxr3 decoder plugin does now is watch the stream's a/v sync
and if the video is in sync with audio (PTS value for the card ==
currently played audio PTS), it switches the card to this synced mode.
If the a/v sync somehow gets off (happens almost never on well-authored
DVDs), the card is switched back to normal play mode which (for small
diffs) cures the gap after a while. (Of course this switching has a
hysteresis.)
Michael
|
|
|
