Dxr3 Logo

DXR3 & Hollywood Plus Logo

DVD/Driver Design Notes
Project Page

Notes from email

RedHat kernel config (Chris C. Hoover)

> 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.

Volume control (Kuroyi)

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.

Sync overview (Kuroyi)

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..

DVD Sync and writing data to the DXR3 (Kuroyi)

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.

Using overlay (Kuroyi)

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.

Broken mpeg's (Kuroyi)

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 Menus (Kuroyi)

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.

Card Subversions (Jeremy T Braun)

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.

Tons of make-install-2.4 errors (Chris C. Hoover)

> 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.

MVCOMMAND_SYNC (Michael Roitzsch)

> 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
SourceForge Logo    
dxr3-devel mailing list
Last modified: Sun Nov 6 11:00:10 EET 2005