|
|
This topic comprises 3 pages: 1 2 3
|
|
Author
|
Topic: DTS - 6D has NO RAM
|
Daryl C. W. O'Shea
Film God
Posts: 3977
From: Midland Ontario Canada (where Panavision & IMAX lenses come from)
Registered: Jun 2002
|
posted 04-05-2003 11:57 PM
Steve, I don't recall ever saying anything about the dts.exe executable, but I guess it was brought into this when I said the motherboard doesn't really do anything. Now, since I don't have a copy of the dts.exe executable source code, I can only hypothesis as to what it is and is not doing. My educated guess would be this:
The dts.exe executable performs the function of a supervisor. It initializes the hardware and periodically checks to make sure everything is running alright. i.e., the D422, D536 and AVA-1501A boards are all still responding (haven't locked up).
Given that the original units could play any audio with any title, the executable may decide whether or not the timecode matches the audio. This could also be handled by the since revised D442 (Timecode) board.
Crossfades are handled by the D536 (Playback) board, under the direction of the D442 (Timecode) board. The playback board also handles 'automation connector' processes/functions. Specifically, this would allow for the fastest possible revisions to analog in the event that the processor can no longer provide audio (loss of timecode, loss of audio data, failed component, etc.).
I would also expect that the dts.exe executable would have the capability of accessing enough of the 'automation connector' to initiate a reversion (in case the D422 board fails). Although I expect it, from past experience, I don't think this is actually the case.
Data is retrieved from the CD-ROM discs via the Adaptec AVA-1501A SCSI card. The SCSI card is initialized at boot time by the dts.exe executable. In theory there is no reason why the Timecode board could not directly request the appropriate data from the discs (via the SCSI card) without the intervention or 'consultation' of the dts.exe executable. It is however likely that the executable is involved in a 'messenger-type' fashion as this would allow for future flexibility concerning data structures.
Things that the dts.exe executable could do while initializing the hardware:
- Set things like crossfade times, time to continue without timecode before reversion, automation signalling times -- although these may be permanently set by hardware structure.
- Try to detect whether it (the executable) is being executed by a DTS player and not some other computer.
- Run a quick hardware diagnostics to make sure everything is in good shape.
- Count to 1000 just for fun.
Reasons for updated versions of the dts.exe executable:
- Correct software bugs that caused bad things to happen.
![[Smile]](smile.gif) - Possibly implement workarounds for known hardware issues.
- Reprogram programmable parts of the hardware to correct known hardware issues.
- Allow for a different data structure on the DTS discs.
- Update the hardware's audio codec.
- Do nothing but make it look like DTS is continuously improving their product. (I'm sure this isn't true. )
Why do I hypothesis this?
This is simply the most efficient and reliable way to structure the system. Looking at the hardware, it is also the case that makes the most logical sense to me. Depending on the engineers who designed the system this could be very close or very far off from reality (or somewhere in-between). I know many engineers that like to complicate the heck out of things and many, like myself, that think the simplest solution is the only solution.
That said, it would be possible to build a unit where the dts.exe executable handled the timecode and audio decoding. The existence of the large timecode and playback boards lead me to believe that this isn't the case though. In such a software dependent solution you'd really only need a small output board and a fast, non-purpose specific processor. Fast because file handling and data decoding are two of the most processor intensive computing tasks.
So... my position is still that, once booted, the motherboard (and x86 CPU) doesn't do much other than provide a databus via the motherboard's ISA bus at a maximum of 8 Mbytes/sec.
All of this aside, adding more RAM to a DTS unit wouldn't increase the unit's performance since it (the player and software) wouldn't be expecting it and therefore likely not know what to do with it. It is very likely that the hardware nor the software would even know that the additional memory existed. In the case that adding additional RAM did in fact increase performance, what would the benefit be? NONE... the hardware would just sit there doing nothing for longer periods of time while still producing the same quality of audio.
| IP: Logged
|
|
|
|
|
|
|
|
|
|
All times are Central (GMT -6:00)
|
This topic comprises 3 pages: 1 2 3
|
Powered by Infopop Corporation
UBB.classicTM
6.3.1.2
The Film-Tech Forums are designed for various members related to the cinema industry to express their opinions, viewpoints and testimonials on various products, services and events based upon speculation, personal knowledge and factual information through use, therefore all views represented here allow no liability upon the publishers of this web site and the owners of said views assume no liability for any ill will resulting from these postings. The posts made here are for educational as well as entertainment purposes and as such anyone viewing this portion of the website must accept these views as statements of the author of that opinion
and agrees to release the authors from any and all liability.
|
Home
Printer-friendly view of this topic