Letters to the Editor

New Media Programming columnist Bill Day does his honorable best to answer all his mail -- praise, suggestions and grumbles alike. Plus: Bill Venners fields a slew of tough Design Techniques-related questions, Mark Johnson sets the record straight on serializing class objects, and more

"Improve your programs with practical audio" by Dan Becker

Read

Audio apps

Dan,

In your article you claim to have shown how to put sound in an application. I read the article carefully, but I still don't see how to put sound in an application. I probably missed something, but I'm not sure what.

I wrote a nice Draw Poker program that deals five cards and allows the player to draw as many as five cards, then wins or loses depending on the resulting hand. I wrote it as both an application and an applet. I can get the sounds of coins being returned and the deck being shuffled in the applet, but I can't get the same sounds into the application. Can you give me some advice?

Sam Rhoads

Sam, Use the streams method of loading and playing a sound. This method does not use or depend on any classes in

java.applet.Applet

. Here is a code sample for playing a sound from a given file:

   import java.io.*;
                                       import sun.audio.*;
                                       // Get sound from file stream.
                                       FileInputStream fis = new FileInputStream( new File( "spacemusic.au") );
                                       AudioStream as = new AudioStream( fis ); // header plus audio data
                                       AudioData ad = as.getData(); // audio data only, no header
                                       AusioDataStream audioDataStream = new AudioDataStream( ad );
                                       continuousAudioDataStream = new ContinuousAudioDataStream( ad );
                                       audioPlayer.start( audioDataStream );
                                      

Use the following calls to stop (pause) and reset the stream:

         audioPlayer.stop( audioDataStream );
                                       audioDataStream.reset();
                                      

Dan Becker

Media Programming: "Introduction to Java media programming" by Bill Day

Read

Media server support

Bill,

I am a student in Israel and I am trying to create a streaming video application using the Java Media Framework. If I use PushDataStream, does it follow that I have to prepare the file I'm streaming (AVI in our case) and send the frames via DataOutputStream? Or can the JMF help me implement a stream from the server?

Ikaros

Ikaros, The JMF is (at least so far) a client-side only framework. It helps you build media players for audio and video, but it does not provide any media server support. You will need to build your own server services or use third-party servers. If you're able to use its codecs instead of AVI, Real Networks has free but fairly powerful versions of its encoders and servers. Real Networks has also promised to make JMF-based versions of its RealPlayer available at some point but it has yet to deliver them. If you want a JMF player now, you'll have to build your own using the C++ interface. If you need to stick with AVI format and you're serving from a Windows NT system, you could possibly use a Netshow server and then use the JMF for the client playback. And yes, your server needs to handle the control events. Your JMF player, in turn, needs to have a DataSource that uses the server's events to keep the playback in synch. Also, the premier article in my new monthly Media Programming column contains some information on the JMF, and will be followed, a few columns down the road, by a JMF-specific article. Bill Day

Media programming with MS-Java

Bill,

I would like you to cover both Sun's and Microsoft's media APIs in your new column. Comparison between the various technologies would be useful.

And, for your information, Microsoft's IE 4.0 ships with DirectSound for Java, DirectAnimation, Direct3D for Java, and DirectDraw for Java.

Sean Sullivan

Sean, Thanks for the input. It's actually quite timely, as I have been thinking a lot recently about how much I should personally learn about MS-Java related technologies and wondering how much of that readers would like to see in the column. I'm planning to pose that question to my readers in an upcoming column. A compare/contrast of Java Direct3D with Java 3D, for instance, might be a good thing to write about, but if more people are interested in learning about Java OpenGL bindings, I would like to cover that, too (or instead of Direct3D). My other problem with DirectX is that I am simply not an expert on this technology. As I mentioned before, I've been getting up to speed as quickly as possible, but I'm sure there are a lot of good references I'm unaware of. If you have a short list of DirectX-meets-Java references, please pass them on. I'd love to hear more specific ideas for things you'd like to see in the column, Microsoft media APIs or otherwise. Two specific things I'm thinking about discussing related to DirectX/MS-Java technology are WFC graphical services as compared with the Sun Java AWT, and Java 2D and Direct3D as compared with Java 3D. Any other comparison-type articles you'd like to see? Bill Day

SGI MediaBase update

Bill,

I've been in love with SGI technology since a second mortgage bought my Indy. I'm looking to begin implementing a video-based intranet for a client. I'm curious, does MediaBase have a set of its own Java APIs? Does MediaBase adhere to/implement the Java Media Framework? Do I have to pick from MediaBase/C++ (hope not!) or MediaBase/Java (preferable) or roll my own (Java/JMF)?

Bob Namestka An avid Bill Day reader

Bob, Thanks for that line about being an avid reader! I haven't worked with MediaBase since it was in an earlier version, so I checked with the development team. Following are the answers I received from a member of the team:

  1. Does MediaBase have any Java-based APIs? Yes. We did have a Java-based player API (working with a Java version of OCS). It corresponds to the MediaBase 1.0 version of movie library. Technically, it should still work with MediaBase 3.0 servers (since our servers support such backward compatibility). We haven't tried it in a long time.
  2. Does MediaBase use Java Media Framework? The JMF implementation also corresponds to version 1.0 of MediaBase.

I should also point out that Silicon Graphics announced in November of last year that all future work on JMF for IRIX was being discontinued. (This affects JMF players for MediaBase for other platforms, I believe.) You can read this announcement from the jmf-interest archive at

http://java.sun.com/products/java-media/mail-archive/Framework/0653.html

So, where does this leave you? You can probably use the Java-OCS support (though I don't have any specifics on this) to roll your own MediaBase player. If this doesn't work for you, you probably need to use MediaBase with the C++ players or roll your own Java-based players. I would strongly suggest that you contact the MediaBase team (via your SGI contact or via e-mail addresses on the SGI Web page) and let them know that you want to see Java-based players in MediaBase. If you think they should build these using JMF, let them know that, too. I believe they are very receptive to customer suggestions and requests, but they do need to be convinced, so be eloquent when you contact them. Bill Day

JMF compatibility issues

Bill,

I'm glad to see that someone intends to keep up with the growth of media extensions for Java.

I'm having a problem with the lack of compatibility between the two versions of JMF, Sun's and Intel's.

Do you intend to address this issue in the future? Do you know very much about the differences and how programmers may come to deal with them?

Phillip Dukes

Phillip, I will be discussing the various JMF implementations in an upcoming column or series of columns. These implementations will likely include Sun's (the reference) as well as Intel's, Real Network's (JMF RealPlayer in RealSystem G2), and possibly SGI's (though it is now somewhat obsolete). There are some mechanisms for dealing with these differences. The best one is probably to simply write robust Java code using try-catch blocks. If something fails, fall back and try another method by catching the exception, figuring out what went wrong, and then calling the appropriate follow-up method. For example, an attempt to create a player for an RTP-based protocol (which Sun's implementation supports, at least in part) will fail in Intel's implementation. But, if I wrap the attempted Manager.createPlayer() inside a try, the catch allows me to attempt to create a player for another, more standard protocol like HTTP (which both Sun and Intel support fairly well). I hope this gives you an idea of how I would approach this problem in general. If you have more specific questions, please let me know and I'll see that they make it into my column and/or my O'Reilly book on the JMF, Java Media Players due in October of this year. Bill Day

Introducing: JIMI

Bill,

Congratulations on your new column. I hope it will be a great channel for getting more people involved with all aspects of Java media.

My company, Activated Intelligence, has just completed its first product, JIMI, and it might be of interest to you. In essence, JIMI is an all-Java toolkit that makes it really easy for programmers to read and write a wide variety of graphics file formats.

Rick Ross

Rick, I've been lurking on the java2d-interest mailing list for a while and observing the discussion regarding JPEG codec support vs. more general frameworks. JIMI has come up several times, and I've briefly checked out Activated's JIMI page. I'm interested in knowing more. In fact, my current column details Java 2D. Several follow-up columns will also cover this topic. If you have a specific pointer that you feel will give me maximum bang for my buck with regard to learning about JIMI (say a really good whitepaper or doc with code in it, demonstrating the basics of JIMI's use), please send it my way. Bill Day

A note from the author

While the majority of reader response to last month's Media Programming debut was positive, we can't ignore the grumblers. At least two readers, who remain anonymous, felt that the introductory column was "content free." Another complained that the column was about "what we don't and can't have." Author Bill Day responds below. --Editor

This column is in some sense a strategic one, pointing the way towards up-and-coming technologies. At the same time, I don't want to turn this column into a forum for marketing hype and not-ready-for-primetime material. I have every intention of providing real-world tips with current, available Java-based technologies. I'll also be discussing Microsoft technologies, i.e., Java DirectX bindings, which should lend some credence to the availability and practicality of Java media programming. My current column kicks off a series on Java 2D. Java 2D is available now in the 1.2 betas and will be a part of the core platform when 1.2 releases later this year. Because a 1.2 runtime version (JRE) will be available for developers to ship with their Java-based products, I would argue that this is definitely something that at least Java application programmers can and will have at their disposal sooner rather than later. The introductory column was not overly technical by necessity. It was designed to set the stage, and as such I believe it succeeded. I hope you will come back and read the next and subsequent columns and then let me know what you think about the practicality of Java-based media programming and the level of technical content in the column. Bill Day

Disappointed beginner

Bill,

I thought this article was supposed to be for beginners or for folks who want to get into Java programming, but it wasn't. I'm disappointed.

John Hedge

John, The column is targeted to people who are familiar with Java programming, but not yet familiar with multimedia programming in Java. I will provide an introduction to the basics of each new topic before I move into more advanced information on it; however, I won't provide readers with information on the more fundamental parts of Java. If you're looking for general information on getting started with Java, I suggest that you check out the Getting Started trail in the Java Tutorial from Sun. The General Documentation should be useful to you as well. Bill Day

On the lookout for an all-Java MPEG encoder

Bill,

Great kick off. Good luck! Do you know of an MPEG encoder written in Java, perchance?

Nick Didkovsky

Nick, Of late, there has been some discussion about this on the jmf-interest mailing list. In fact, I see that you've posted to the list on this topic, so I hope my reply won't be old hat to you. The specifications for MPEG codecs are asymmetric. That is to say, it takes much more work to encode an MPEG bitstream than it does to decode it. This is by design, so that decoders can be simpler and hopefully much faster for end users. So, software MPEG decoders should be, and in fact are, more common than software encoders. As Andrew Wason mentioned in

his response

to your jmf-interest post, a number of Java-based MPEG decoders are available. Of the choices he presented, the

Inline MPEG - 1 - player in Java

looks to be the most mature. You might try contacting the people responsible for this decoder and asking them if they have an encoder in the works or are aware of one. You might also try the following:

Related:
1 2 3 Page 1
Page 1 of 3