******************************************************************************* * DM6437 Demo Application Release Notes * * Texas Instruments Incorporated * Copyright (c) 2007, All Rights Reserved ******************************************************************************* ------------------------------------------------------------------------------- DM6437 Demo 1.30.00 ------------------------------------------------------------------------------- Disclaimers: This is demo code only and although every effort has been made, TI makes no claims pertaining to performance nor robustness of the demo. The demo should serve as a reference to see how all the various pieces of the DVSDK are integrated together into a single coherent application. The demo is designed to be somewhat generic and flexible and therefore may not be implemented in the most optimal way. Also, the demo implementation is complex, so there are more simplified code samples in the DVSDK examples directory. The demo code has not been through rigorous testing and hence is not considered to be production code. It's quite possible undiscovered bugs exist in the demo. TI will make every effort to fix bugs for future releases. The demo is not guaranteed to decode all H.264/G.711 clips that the user obtains from outside sources, as testing in this area has been minimal. TI is not positioning this demo code as production software nor does TI plan to make a product out of the demo code. It is here purely for example purposes. ------------------------------------------------------------------------------- Known Issues & Things to Take Note of: - When the host app is connected over Ethernet, it can introduce extra CPU load because of network latencies. Sometimes the CPU load may spike up to 16% momentarily and then come back down. We suspect this is due to the two-way handshaking that happens between the host and target once per second when the host makes a series of RPC calls to query statistics from the target. If you disconnect the host application, the CPU load does indeed go down to a steady expected value. This does not impact audio/video performance, since the RPC is at a lower priority. This is still being investigated and improvements might be made in a future release. - When using the IP discovery feature of the host application, the host machine and the EVM are required to be on the same subnet. One common situation to watch out for is when a laptop is on a wireless network and the EVM is plugged into a wired LAN. In general this won't work because in most cases the wireless network will be on a different subnet than the wired LAN. You can still manually enter the IP address into the host app and it will work, but you can't use the IP discovery feature. In this case, you will have to run the code from CCS to see the IP address that gets printed to the CCS console. There is one other IP discovery issue to watch out for. A laptop with a wireless network connection that is also docked and connected to a wired LAN may have both connections active at once, and the laptop will actually have two IP addresses, each of which on a different subnet. This will prevent the IP discovery protocol from working. The solution is to disable the wireless network while docked. - The CCS project now has multiple 'Configurations': Debug, Release, iDebug, and iRelease. The difference between debug and release is that the debug configuration is built with -o3 compiler optimization. The 'i' configurations use instrumented versions of the PSP drivers. - There is no other demo application documentation. However, you can find a high level PowerPoint presentation in the demo doc folder. - The hardware resizer is used to both de-interlace the input and also to scale the video input from D1 to CIF. For optimal video quality, D1 video is set to 704x480 for NTSC and 704x576 for PAL instead of 720x480 and 720x576. This is because the CIF resolution of 352x240 NTSC (352x288 PAL) is exactly half of 704 lines horizontally and yields the best quality. - When running the host app in encode to file or decoding from file mode, the demo is not performing streaming, but rather using file IO fread/fwrite operations. The demo has implemented a simple file IO over TCP/IP sockets system that allows the target to open/close/read/write host files. - In some instances, depending on the video source equipment used (DVD, camera, NTSC, PAL, etc.), you might observe one or more black lines at the edges of of the video input. - Occasionally, audio may output a brief moment of noise. At other times you may hear "ticking" artifacts. Many times if you hit "stop" and then "play" again, the noise artifacts will disappear - Many times when you first start the demo with audio enabled, you will hear some initial noise artifacts. - You may observe that when the audio produces noise, that the synchronization between audio and video is disrupted. - Certain instabilities have been observed, mainly with using the host application to start and stop the demo. - For best performance, remember to "Run Free" from CCS as opposed to just "Run". - "Disconnect" the host application to eliminate any rate loss due to network latencies. This of course won't be possible when encoding to a file or decoding from a file, since the host application is required for those modes. - Occasionally, initiating a play or stop from the host app will fail to work. Usually repeating the action again after the error dialog box appears seems to work. Also, occasionally clicking on the Play button from the host application will not work at all. Usually trying it a second time will work. This is being investigated. - It has been observed that attempting to encode to file over a slow network connection (such as a wireless connection), will cause the demo application to crash. - When you decode from file, it can take a moment before you see the output. This is because the application has to initially read from the file to buffer up the video before the decode begins. If you then decode again from the same file, it can happen quicker because Windows has the file cached and the read operation happens quicker. - When you hit Stop while encoding to a file, it can take a moment for the application to actually stop. This is because the application has to flush all in-flight buffers and also flush the file I/O. - It is generally a good idea to reset the board frequently if making modifications to the application and re-running it. Sometimes the EVM board will get in a bad state and must be reset. We strongly recommended you at least initiate a 'Debug->Reset CPU' from CCS before loading a .out file. In addition, you may find it necessary to actually reset the board using the POR reset button on the EVM. To do this, use Debug -> Disconnect Emulator from CCS, hit the POR reset button, then use Debug -> Connect Emulator from CCS to re-establish emulation. On rare occasions, it will be necessary to do a complete power cycle of the board. To do this, you must quit out of CCS. - If you modify the DSP/BIOS TCF file and rebuild your CCS project, all source files will rebuild. However, the very next incremental build will also cause all source files to be rebuilt. - The NDK Network Stack included in the DVSDK is the evaluation version and will expire after 24 hours of continuous operations. Currently, the demo only printf's a message saying the NDK is about to shut down in 5 minutes. No other action is taken by the demo. This means the app has the potential to hang upon reaching the timeout. - By default, the demo is configured to use DHCP to obtain its IP address. You can assign a static IP address by modifying app_main.c and changing "dhcp" to 'static' in the configuration section. - The demo defaults to using a variable bit rate for the H.264 encoder. This can be changed by setting the max bit rate in the configuration section of app_main.c. - The video decode task uses a CPU memcpy() to move some data. A future enhancement may change this to use DMA for better performance. - A future enhancement may add a Pause/Resume feature in addition to just Play/Stop. There is some code is in the demo to support this, but is not functional at this time. - The code is set up to light user LEDs on the EVM but there are currently some issues with performing I2C transactions to set the LEDs during runtime, so the lines of code that set LED's on/off has been commented out. - If you want to run the demo using instrumented device drivers, you will need to rebuild it using one of the project configurations. Select Project->Configuration from CCS to change this. - The demo is a very dynamic system -- just about everything is created dynamically at runtime. Currently, there is no real support to tear down these resources. - While decoding from file, if you are decoding both video and speech files and the "Repeat on Decode" box is not checked, the demo will stop playing when the first file finishes. - Mic-in is not supported in this release - There are many spots in the demo code where a runtime assertion can occur, such as a memory alloc fail. In these cases, the demo will abort and stop running. If you have CCS open, you will see a message on the console. However, if you are just using the host app, you will not see any error messages and the host application will freeze up. - There is the possibility for a memory leak to occur due to buffers not getting freed on certain audio driver error conditions. A memory leak has been discovered when audio is enabled. 3300 bytes will be lost each time play & stop are hit. You can observe this by looking at the system stats in the host app, the heap free decreases. A new 48 byte memory leak was introduced in 1.10.00. The heap loses 48 bytes each time you play then stop. ------------------------------------------------------------------------------- ******************************************************************************* * End of File *******************************************************************************Download Driver Pack
After your driver has been downloaded, follow these simple steps to install it.
Expand the archive file (if the download file is in zip or rar format).
If the expanded file has an .exe extension, double click it and follow the installation instructions.
Otherwise, open Device Manager by right-clicking the Start menu and selecting Device Manager.
Find the device and model you want to update in the device list.
Double-click on it to open the Properties dialog box.
From the Properties dialog box, select the Driver tab.
Click the Update Driver button, then follow the instructions.
Very important: You must reboot your system to ensure that any driver updates have taken effect.
For more help, visit our Driver Support section for step-by-step videos on how to install drivers for every file type.