Yes, there is.
I'm assuming your broadcast stream is (or can be) somehow broken up in smaller messages (or "packets"), and you don't need to retire a key before a message is finished.
Then you produce a random session key for each message, and encrypt this session key with each of the subscribers' keys, prepend them (together with some tagging) to the message.
Each subscriber than filters the header for his section, decrypt the session key and then can decrypt the whole message.
This gives some overhead proportional to the number of subscribers for each message, so it works better when the messages are large enough and the number of subscribers is low. On the other hand, if subscribers can switch on at every time, you'll want to have the message size small so they don't have to wait long until the next session key comes around.
The OpenPGP protocol includes this feature, and is commonly used for sending encrypted emails to multiple receivers. I suppose S/MIME does it similarly.
This method works both with symmetric long-term keys as well as with asymmetric key pairs for encryption (such as RSA or ElGamal).
If you have a "normal" directed communication method in addition to your broadcasting channel, you could also send each subscriber the session key (encrypted with his key) directly, without the bandwith overhead for all the other subscribers.
There might be some more fancy method of encrypting a session key to more receivers without the linear bandwith growth, but I know of none. (1-of-n secret sharing or such?)