Charmed Quark Systems, Ltd. - Support Forums and Community

Full Version: Class: MediaRenderer
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
This thread is for discussion of Media Renderers. Media Renderers are one of the few device classes that are already standardized. So this thread exists primarily for the purpose of documenting that existing standard, though of course suggestions are welcome for ways to improve it.

[to be done]
(reserved for expansion)
(reserved for expansion 2)
What would be the best driver to use as a V2 example for the Mediaplayer class, DevSim_AudioPlayer_V2?

It would be nice if these standards could be documented in these threads (unless this info is documented somewhere else):

Fields: Name/Type/Access
Standard Manifest Info/Prompts
Standard Methods
Examples and/or Pointer to an Example Driver
etc.

This would really help me in getting my drivers updated..
The device simulator would be the best example. It actually does V1 and V2 in the same driver as well, with just two different manifests. And, since the base class lets it clearly separate what is device specific from what is common, and that one has so little device specific code, that makes it even more obvious what is going on.

In the case of this one, since there I also a base class, and it's too much to just do twice, I'll probably stick to high level stuff here and put the details in the base class docs.

If you are using the standard base class, none of the fields are really your responsibility. You would only have to deal with device specific stuff. I think that the Dune driver is one that has some device specific fields. But, since all of the ones I do are now based on the common base class, sort of any of them would do as a model.
I guess one fundamental thing to consider is that, if you use the base class, you can override any of the regular driver methods. But assume that the underlying driver uses them as well, and pass the calls on to the base driver.

So, if you have writeable fields of your own, override the write callbacks, check the id to see if it's one of yours. If not, pass it to the base class, and return his return value.

For 'on the way up' type overrides (init, wait config, connect, get comm res), call the parent class first, then do your stuff. For on the way down stuff, do your stuff first, then call the parent class.
I should qualify the above to say that, you are responsible for the Audio and Media Transport device class writeable fields, since those are device specific. But the base class handles the Media Renderer fields if you are basing your driver on it, and updating the volume/mute and media state fields (based on info your class returns to it.) It handles all of the interaction with the repositories, serves up cover art and metadata, handles addition of new media to the playlist and playlist management field writes, etc...

But of course you have to handle incoming writes to the transport and volume and mute fields since those are device specific things.
I don't remember if it ever got mentioned elsewhere, but the render base class is documented now in the CML docs on the web site: