Smn 1 0 smart media network
1 / 32

Smart Spaces - PowerPoint PPT Presentation

  • Updated On :

SMN 1.0 Smart Media Network Auburn University COMP7970 Richard Chapman 19 Sept 2002 Home audio/video Back side view... And… How do real users cope? The problems Undocumented configuration and interconnection information Difficult to modify or reconfigure: snarl of wire

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Smart Spaces' - andrew

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Smn 1 0 smart media network l.jpg

SMN 1.0Smart Media Network

Auburn University


Richard Chapman

19 Sept 2002

The problems l.jpg
The problems

  • Undocumented configuration and interconnection information

  • Difficult to modify or reconfigure: snarl of wire

  • “Secret” knowledge required to operate

  • Sometimes just cannot be configured

Motivations for a solution l.jpg
Motivations for a solution

  • MP3, streaming media, fast Ethernet

  • Jini, CORBA, OSGi, UPnP

  • Universal remote controls based on PDA, Mobile phone, web

  • Utter indifference of consumer electronics manufacturers

Calls for a solution l.jpg
Calls for a solution

  • “A Call for the Home Media Network”, Bell and Gimmell, Communications of the ACM, July 2002, pp. 71-75

  • Donald Norman, “The Perils of Home Theater”, IEEE Computer, June 2002.

Requirements l.jpg

  • Good audio and video quality

  • Easy to operate

  • Easy to configure, udpate, modify

  • Easy to develop for

Other goals l.jpg

Open source

Standards based

Vendor, OS language neutral

Keep orthogonal issues orthogonal

Pay attention to the user interface

No global state to maintain

Capable of redundancy, fault tolerance

Support multiple UI’s

No preferences or settings

Other goals

User stories l.jpg
User stories

  • “I want to play CD’s, video or listen to the radio”

  • “I want to record my soaps”

  • I can listen to music or watch TV or movies”

What can we deduce l.jpg
What can we deduce

  • Users want to ignore connectivity

  • Users don’t want to set up the system

  • Content is what matters

Device categories l.jpg
Device categories

  • Server -- multiple okay, no direct user access

  • Controller (phone, PDA, web, custom HW) -- multiple controllers okay

  • Player -- originates content stream (audio, video players, tuner, Internet radio)

  • Recorders (PVR, MP3 ripper, etc)

  • Presenters(amp/spkrs, video monitor)

  • Processors (e.g. EQ, reverb)

What is good l.jpg
What is good

  • The snarl of wires is gone

  • The configuration information is no longer secret

  • Control and data can share one wire

What might be bad l.jpg
What might be bad?

  • Audio and video quality?

  • Use RTP/UDP

  • Buffering is okay

  • Compare Gibson Guitar Corp MaGiC, Peak Audio (synchronous protocols for audio over Ethernet, but not TCP/IP)

  • We’re going to try TCP/IP

The orthogonal issues l.jpg
The orthogonal issues

  • Service registration, lookup, discovery

  • Control messages to devices

  • Streaming protocol

  • User interface

Service registration leasing lookup query l.jpg
Service registration, leasing, lookup, query

  • Many options exist: OSGi, UPnP, Jini, CORBA, SOAP

  • We have experience with Jini (smart badges, lego demo, eClassroom)

  • Want language and OS independence

  • Want something simple

Problems l.jpg

  • CORBA would require “brittle” interface wrappers (IDL) for everything

  • Jini has more flexibility, but still requires Java on all devices

  • UPnP -- is Microsoft ready for a university development effort?

Smn 1 0 l.jpg
SMN 1.0

  • Use LDAP for registry

  • Add a “keepalive daemon” to handle leasing

  • Use SOAP for control messages

  • Use XML to store description of device capabilities, control message formats, in the server

  • Use variety of streaming protocols

Why ldap l.jpg

  • Solves the registry problem

  • Simple to implement

  • Language, vendor, OS independent

  • Lots of languages have LDAP libraries

  • OpenLDAP

How much should the controller know about a device l.jpg
How much should the controller know about a device?

  • Nothing: just present the controls to the user in some “nice way” on the interface

  • Lots: this way you get as much basic functionality as you can

  • “The universal remote is always missing a few buttons you really need”

User interface issues l.jpg
User Interface Issues

  • Make the common tasks simple

  • One way of doing things

  • No “set preferences” in the interface

  • Support multiple interface implementations

  • No configuration knowledge required

  • Get away from WIMP and remote controls as interfaces

One knob one button one navigator l.jpg
One knob, one button, one navigator



rotating ring


What we will do l.jpg
What we will do

  • Define the LDAP schema, SOAP messages, XML format for the server

  • Implement a basic player, presenter

  • Implement a couple of controllers

  • Probably audio only

  • User study

What else is there to do l.jpg
What else is there to do?

  • OSGi gateway to the WAN (mobile phone controller, mobile phone presenter, multi-LAN network)

  • Other controller implementations

  • Alternative service discovery, registration system