unit testing multimedia
We're in a debate here over performance vs. utility. We've got a program using standard Windows multimedia controls in VB 6.x and VB.NET. The formats we have to play are WAV, MID, and AVI. The developers are using two multimedia controls - which is causing massive overhead in terms of performance. The developer's claim it's the only way to play two types of files is to use the controls simultaneously like this. In other words, if we have the need to play AVI and WAV then we need the two controls no matter what. We're earmarking this as a big risk.
So I guess two questions:
(1) Are the developers right that you need to use two controls? (This is more a unit test question.)
(2) Do you go more with the performance or do you go more with the code utility (functionality) when looking at unit testing?
Re: unit testing multimedia
<BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica">quote:</font><HR>Originally posted by AitenB:
(1) Are the developers right that you need to use two controls? (This is more a unit test question.)<HR></BLOCKQUOTE>
It depends. In general, with VB controls the answer is "yes" - you do need two controls. The key is understanding that the file formats are played through different parts of the overall Windows architecture. For example, a WAV file will be played through a digital-to-analog converter whereas a MID format (which is a linear data stream) will be played solely via the sequencer. AVI is uncompressed at each frame and then played via the video subsystem. Since each is a different system they can be played at the same time. However, in VB that means that one multimedia control has to be established to handle each system (or process, if you will; think of it as a thread). So, for example, if I have an AVI video file and I have a WAV sound file and I want to play both so that they synchronize, I have to have two multimedia controls to play both.
There are exceptions to all of this but not many. One exception would be that, with my above example, the WAV sound could be encoded into the AVI file as an auxiliary data stream. In that case, both subsystems (video and digital-to-analog coverter) are used but only one multimedia control would be necessary because the decoding process (done by Windows) would force the video and sound to the right subsystems. So, in that case, having two controls would be resource overhead that you could do without.
<BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica">quote:</font><HR>(2) Do you go more with the performance or do you go more with the code utility (functionality) when looking at unit testing?<HR></BLOCKQUOTE>
It is a trade-off usually. In this case, however, you are dealing with the use of controls - which are encapsulated sets of code. You have to determine if you want to use the full bulk of the control or write your own code. For example, staying with VB but switching controls, consider the image control and the picture (or picture box) control. Both of these can do roughly the same things but the picture box control has a great deal more functionality. But if you do not need that functionality, then you do not need to use a picture box control and should opt for the lightweight image control instead because otherwise you will have too much overhead.
As another example, the Windows Common Dialog Control is often used in VB programs to allow you to easily use Open and Save dialogs as well as to handle the Print dialogs. However, that control has a lot of overhead and there are ways to write your own code that exactly simulates the code of the Common Dialog Control and include your own code as class files within your VB project. Now, with multimedia controls that custom approach might be a lot more difficult but it is something to think about. Also remember that with multimedia you can use direct API calls to the Windows architecture which can increase your performance by removing the full control from your project. You have a little code bloat but, on the other hand, you make direct calls to the subsystems via the Windows API. Again, a trade-off.