Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Matthew

Pages: 1 ... 3 4 [5] 6 7 ... 38
61
Developers / Re: linuxmce and PS3
« on: January 31, 2008, 04:47:54 pm »
And if you really want to be cool, kboot claims to support HTTP and NFS for retrieving the boot image. You might even make the boot image server keep state of which PS3 MD has already loaded the image, and use the DCE history to see whether there's a PS3 MD that's got the image, but not busy, and point the currently booting PS3's kboot at that other MD by HTTP or NFS, to offload from a busy Core. If you want to be a hero, figure out how to add BitTorrent to kboot, make it store the boot image before booting, and let the Core respond to DHCP request with a .torrent pointing at all the booted PS3 MDs, which can participate in the swarm if they're not too busy. That's the kind of system that could make diskless MD booting a PS3 over its Gb-e really fast.

guy, what are you smoking???

What's the problem? Make a PS3 MD kboot over HTTP to the Core. Make the HTTP URL point at a CGI that checks all the MDs in the DB for one that's not busy playing, and return an HTTP redirect (or Object Moved etc) message pointing to that MD's HTTPd.

Revising kboot to use bittorrent to MDs is harder, but doable. Making MDs de/activate in the swarm whether they're busy or not is harder, but a doable tweak. And if we're trying to get MDs to boot fast (which several are, by hibernating), and remain diskless (which is an important way to keep MDs upgraded and manageable), this is a strategy. And if we want MDs to power up/down on changing presence info (which I do), this is an infrastructure to do it.

Booting a host is already complex because of conditions varying while the machine is off and unresponsive. Network boot management adds more complexity. But there is an architecture here that is compatible with architecture already part of LMCE. That could be even better with some swarm tech. Designing a PS3 MD is a good opportunity to think through some of that "grand design" because of the PS3's limitations (balanced by strengths when actually running). For example, PS3 has only only 512MB RAM, a single SATA connection, and no PCI, so there are stategies to netboot, use a large SATA i-RAM bank as swap, and get something closer to a 16GB PS3 than just 0.5GB. And since we're talking about managing power (and cheaper HW overall), a BitTorrent boot swarm is one way to maximize the HW and power consumption, by decentralizing away from the busy Core whenever possible.

62
Why does an MD need multiple audio player SW instances running? Are you using a single MD to route different audio streams each to multiple rooms?

That is what I envision.

That's different from my preferred architecture, so my comments will be relevant for the other way, which is probably closer to the basic LMCE media distribution architecture, for future reference.


I believe the SlimServer can already do that. If you want to use Xine to play the audio stream to the MD soundcard, you need to add to the Xine wrapper code that starts up the SlimServer and requests from it. Or make a DCE wrapper for the SoftSqueeze that offers that control and requesting.

If only I knew how to do that, perhaps that would get us somewhere...as long as the MD could play three or more sources at the same time without three different hardware MDs.

Actually my original thought was to use Squeezbox units for each desired music input to the multi-zone amplifier. I decided that it would be cleaner if this could be integrated into LMCE somehow.
(...)
The new NuVo system named Essentia is EnergyStar compliant, so one would suppose this would be a better option than having multiple MDs (12 or more) to control said zones. Especially by the time you add televisions, monitors, remotes, etc. to each zone.

I prefer to have the audio kept digital as close to the speaker as possible. A multi-zone amp would send long speaker wires into each zone, which is the weak link in the audio quality chain (even with very expensive speaker wire, more than 5-10m will be worse than inexpensive DACs). Even relatively (to speaker wire) cheap soundcards/DACs are better. The cheapest MD in each room can pump audio from ethernet probably for $50. Or a series of 5m USB cables on hubs, or maybe an optical USB extender. Those ways still require an amp in each room, but preserve the digital quality.

In fact, what I'm hoping is that Bluetooth speakers, which have fairly hifi A2DP digital streams already, will upgrade their fairly lofi DACs, small amps and cheap speakers. Or a Bluetooth amplifier that powers regular speakers. All that Bluetooth could run off a single MD with Bluetooth dongles that can reach multiple rooms.

I'm working on getting Bluetooth speakers that appear in range (get powered on) to trigger starting up a SoftSqueeze on the BT MD, the same way a SqueezeBox's DHCP events trigger starting up a SlimServer on the Core. And then getting the SoftSqueeze to also trigger starting up the SlimServer the same way.

My preferred energy management is to put each device on a home automation controller, maybe as simple as a $5 X10 power controller module. I'd like to wrap the LMCE device that controls them with logic that ensures they're powered on in time to receive the command. And also powers them off when a presence server says there's no one near to hear them.

63
Developers / Re: linuxmce and PS3
« on: January 31, 2008, 02:17:33 pm »
As far as PXEboot, your guess is as good as mine.  This might be doable if there was a special kernel on the ps3 that would get far enough in the bootstrap to then go out and get the rest from the linuxmce box, but for now I would be happy with a hard drive version of the boot disk I see some people using in their media directors when the MD doesn't support PXEboot'ing.  Does anyone know how those disks were created?

PS3 boots first by loading the Hypervisor (whether from ROM/Flash or disk I don't know), which finds otheros.bld (on disk, I think, not Flash), which specifies (or perhaps even executes) loading/running kboot, which loads and runs Linux (initramfs etc). The point in that chain to do PXEboot would be kboot. [ur=http://kboot.sourceforge.net/]kboot[/url] uses kexec to load a kernel file and boot it, but wraps kexec in a uCLinux kernel and BusyBox (Sony might have modified it to use something different on PS3, but then they have to have released the revised source - interesting side note). There's an old article that describes PS3 boot process in more detail. kboot (unless Sony stripped it) supports DHCP and TFTP, which should let it simulate PXEboot (which uses DHCP to get instructions to load the boot image from a server). Since LMCE has a DHCP monitor triggering when clients make DHCP requests, and a TFTPd, just changing kboot's configs should let it load a PS3 boot image. The Core's dhcpd.conf should even be configurable to recognize the PS3's Gb-e MAC range to specify the right boot image.

And if you really want to be cool, kboot claims to support HTTP and NFS for retrieving the boot image. You might even make the boot image server keep state of which PS3 MD has already loaded the image, and use the DCE history to see whether there's a PS3 MD that's got the image, but not busy, and point the currently booting PS3's kboot at that other MD by HTTP or NFS, to offload from a busy Core. If you want to be a hero, figure out how to add BitTorrent to kboot, make it store the boot image before booting, and let the Core respond to DHCP request with a .torrent pointing at all the booted PS3 MDs, which can participate in the swarm if they're not too busy. That's the kind of system that could make diskless MD booting a PS3 over its Gb-e really fast.

Let us know how it goes.

64
Users / Re: Z-Wave News
« on: January 30, 2008, 11:45:36 pm »
this is great news. Finally some affordable HA hardware available again.

How much does it cost?

65
Developers / Re: linuxmce and PS3
« on: January 30, 2008, 11:37:55 pm »
I don't think the PS3 will be any good as a Core (or Hybrid). It's got only 512MB RAM.

But a PS3 Media Director could work. Especially if you use the spu-medialib version of MPlayer. I'd like to see the HowTo on getting that up and running, along with the other accessories that usually take extra steps to get running in PSUbuntu. Which would include KDE, because PSUbuntu us GNOME, but LMCE is KDE. Should be doable, but not trivial.

And if you got the PS3 to PXEboot somehow into LMCE, that would be quite a revelation.

A PS3 MD would be a $600 1080p 5.1 audio Bluetooth Gb-e MD with a Blu-Ray drive. Quite a compelling accessory, even if you don't boot it into GameOS when LMCE isn't looking.

66
Users / New 0710 Release Date Target?
« on: January 30, 2008, 09:35:01 pm »
I'm not trying to make the 0710 release come any faster (though I'd like to :)). But we don't have any indication of a target release date for 0710. We started in October with an "endo f November" release date. We went through December thinking "maybe by Christmas" but sometime in January if not. Now January is over.

Can we get a new target date? It'll be easier to keep on going if someone credible can make an estimate.

Also, by the end of February we'll be only a month away from the next release of Kubuntu, which would be numbered 0804. So maybe "0710" will never come out, if we add "upgrade to Kubuntu 0804" to the requirements for the next version.

67
Developers / Re: S60 Phones
« on: January 30, 2008, 03:00:06 pm »
A JavaMO for JME would be widely portable. Blu-Ray players run JME as BD-J (for menuing apps, HTTP, etc). DVB and OCAP/ACAP use JME the same way. Lots of phones, including the Android spec, run JME. JME looks like the grand convergence platform. So a JavaMO would be easily (supposedly trivially) portable to all those devices.

68
Why does an MD need multiple audio player SW instances running? Are you using a single MD to route different audio streams each to multiple rooms?

Seems to me that what's needed is the Core running multiple audio servers, streaming audio data packets to whichever MD requests each stream. I believe the SlimServer can already do that. If you want to use Xine to play the audio stream to the MD soundcard, you need to add to the Xine wrapper code that starts up the SlimServer and requests from it. Or make a DCE wrapper for the SoftSqueeze that offers that control and requesting.

At least that's what I gathered from my research in these forums into getting a Bluetooth speaker running. So I'd also mention that the audio sink might not even be a "soundcard" per se, but perhaps a Bluetooth dongle running A2DP which sends the audio to the BT A2DP speaker.

69
Developers / Re: How does a core system start?
« on: January 30, 2008, 02:41:26 pm »
Just a comment: this is an interesting thread, I hope one day it will help to make "clean core" option into mainstream LinuxMCE - right now the LM spawns the core services and devices, but it would be interesting to consider detaching this functionality to be done by backend service and LM be only an client UI, so it can be independent.

AFAICT, it would be pretty easy to replace the GUI LM with a handful of scripts, and a tiny Tk or Qt shell that calls them (and a dinky CGI/HTML interface):

Most of the Launch Manager is info reporting, and some GUI commands that are replicated elsewhere (like in the Orbiter). There are also some features for switching between Orbiter and KDE contexts which are unnecessary if either or both of the KDE contexts are eliminated. The unique LMCE dependencies on the Launch Manager seem to be only
1. Auto/start/stop Core/MD,
2. MySQL connection configs
3. Video driver/resolution settings
4. Audio driver/passthru settings
5. Opening external editors for config textfiles

#2-5 seem trivially replaced with commandline tools. #1 seems pretty easy, too. Are there really no other LMCE dependencies on KDE/X? If there are some dependencies on KDE/X libraries for processing multimedia, but not for displaying anything on the Core, then even those libraries could be installed without actually running X, and getting all the benefits of cutting X bloat from the LMCE Core.

Why don't you make a feature request in Mantis? I'd love to watch the resource requirements of the Core go down, by offloading all X/GUI processing to another host on the network (that's running an Orbiter or just an Adminsite).

70
Developers / Re: sync_pluto2amp.pl to SVN?
« on: January 30, 2008, 02:37:36 pm »
I see that Ender fixed  Mantis bug#3839: Cisco 7970 does not come up after configure with a new sync_pluto2amp.pl . Any reason it's not in SVN, where we could get it with the rest of 0710b3?

(I'd PM Ender, but their mailbox is full.)

It is in SVN  :) Look at the folder: http://svn.linuxmce.com/pluto/trunk/src/Dhcpd-Plugin

Yeah, and I've got it locally. Don't know how I missed it with find and locate.

71
Developers / Re: MAME Plugin Progress Thread
« on: January 29, 2008, 05:33:24 pm »
I have just tried it under UI1, and the window management works as expected, fantastic! when the remote is clicked, the display shrinks to allow room for the on-screen control panel. Works very well..

also, I have successfully played my first game of Bubble Bobble, tonight.

Which got me thinking.. Basically, to make this work... i'm going to have to make /dev/input to DCE joystick devices, and special joystick devices for certain devices like the Tankstick, etc...

"Why? it works now."

yes, it works NOW.. but the idea will fall apart when I start bouncing games to multiple media directors.... I need the joystick movements as DCE... mouse may be a bit....trickier.... hell, it may not work at all...but i'll try...as soon as i am happy with process management and media identification....

I'd love to see a PS3 sixaxis work over Bluetooth. I might even buy you one to test with :).

you can use that already:
"The PS3 SIXAXIS controller follows the USB HID class specification and should automatically be detected as a joystick by any Linux kernel:"
http://ps3.jim.sh/sixaxis/usb/


I mean the sixaxis data getting sent as DCE. If the sixaxis can pair to multiple BT dongles throughout the Floorplan, it could roam among different MDs, too.

72
Developers / Re: MAME Plugin Progress Thread
« on: January 29, 2008, 04:19:08 pm »
I have just tried it under UI1, and the window management works as expected, fantastic! when the remote is clicked, the display shrinks to allow room for the on-screen control panel. Works very well..

also, I have successfully played my first game of Bubble Bobble, tonight.

Which got me thinking.. Basically, to make this work... i'm going to have to make /dev/input to DCE joystick devices, and special joystick devices for certain devices like the Tankstick, etc...

"Why? it works now."

yes, it works NOW.. but the idea will fall apart when I start bouncing games to multiple media directors.... I need the joystick movements as DCE... mouse may be a bit....trickier.... hell, it may not work at all...but i'll try...as soon as i am happy with process management and media identification....

I'd love to see a PS3 sixaxis work over Bluetooth. I might even buy you one to test with :).

73
Developers / Re: minutes from the conference.
« on: January 29, 2008, 04:17:20 pm »
Just a quick reminder... It's been a week now, and I guess those that could not attend would love to get an insight into the discussion...
At least I do... ;)

I've asked Aaron about getting notes/minutes or even just a recording (if one exists), but I haven't heard back. I myself had the same (or worse) audio problems that many on the conf stream had, so I know I missed stuff, some of it essential. I'd rather start a discussion that continues from that conference from the notes of the conference.

However, despite that, I'll mention here that a lot of the discussion was about whether and how to use SWF and TrollTech's Qt (or just one or the other) as the UI3 framework. The reason I mention that now is that Nokia bought TrollTech this week. Which almost certainly affects plans for using Qt in UI3, probably for the better (ie. mobile Orbiter not necessarily limited by Symbian OS' UIKON GUI framework).

This is newsworthy. And probably has Aaron dealing with more complex issues underlying UI3 now. So at the risk of moving the discussion forward without a consistent transition from the last event, the actual UI3 brainstorming conference, maybe we should talk about at least what it would take to create a UI3 along the lines we've already talked about.

One conference point that we raised but didn't fulfill was a requirements list of UI3. If we could get even Aaron's UI3 wiki article reduced to bulleted requirements as something to kick around, we'd be more productive. There are requirements of the final UI itself at runtime. There are separate requirements of the process to create that UI (eg. requirements of the UI composer tool that include supporting requirements of the UI it generates), which include collaboration and probably cross-compiling (eg. Linux dev env targeting mobile phones). And there are requirements of both to support transition from the current UI1/2/2-blend to UI3. If we can start such a list, even if the requirements aren't nearly finalized (ie. proposed requirements), by the time we complete the initial version just from Aaron's article, maybe we'll also have the notes from the next artifact, the UI3 brainstorm conference, ready to take it a step further.

74
Developers / Re: Code Where Orbiter Sends DCE Event?
« on: January 28, 2008, 07:38:01 pm »
However, the actual object that executes the ripDiskWrapper.sh script is a RipTask object that is contained (inside a RipJob object) in the Disk_Drive_Functions object. Which the Powerfile object sends to, and which any disc management object will send to for ripping. The right place for the rip format default is in the RipTask or the RipJob, which should know about its own rip job parameters. However, the current default code in the Powerfile class that converts empty format properties into "ogg" prevents the RipTask or RipJob from detecting whether it's "ogg" only because it went to default. That Powerfile code should be removed, and moved to the RipTask or RipJob class. And really, the default format shouldn't be OGG, because it's lossy. Since FLAC is a lossless compressed format, I'd like to make the default FLAC. So the Orbiter can set the format, or else the RipJob sets it to the Installation Settings in the DB, or else the RipJob sets it to FLAC.

Looking more carefully at the RipJob and RipTask classes, it looks like they are just managing the hardware, not performing any logic on the rip itself, which is all in the Powerfile object. Which is wrong - the ripping operation itself should manage its defaults, even if other objects like the Orbiter that have more immediate data (like user override when requesting the rip) that should override the default. But the whole architecture is wrong. The Powerfile is the hardware executing the ripping, and the RipJob and RipTask are abstractions that should be calling the Powerfile's hardware. The Powerfile should know whether it uses ripDiskWrapper.sh or some other script that knows what code actually runs that rippable object's HW.

But I'm not going to fix the architecture all at once just to ensure the defaults are called by the right object. That will just make fixing it later harder, because the code has been further shuffled around the wrong objects in the wrong architecture. I'm going to make the minimum revision, which is to make the overly simplistic default format enforcement code also check the DB for the default setting before giving up and setting it to OGG. But I am also going to change the default from OGG to FLAC, because that will be the least destructive action to take if all the other exceptions to setting the format happen.

Unless someone can talk me out of it, first :).

OK, nobody talked me out of it, but I think I'm going to insert the format setting lookup into the Orbiter code anyway. It doesn't belong there, but the Orbiter already has infrastructure for querying the DB. The RipTask class doesn't have any DB access, and when I try to add calls to db_wrapper_query_result() either in the DCE or DB_Wrapper namespace/classes, the build fails unable to resolve the symbol (even with the .h files #included). At least it will work. If I can't find out how to make the RipTask access the DB, I'll just make the Orbiter do it. And refactor rhese encapsulated properties properly later.

75
Developers / Re: MAME Plugin Progress Thread
« on: January 28, 2008, 05:27:11 pm »
Typically, the orbiter only does one media type at a time... I did not tell it to stop other media in the same EA, so if you have a squeezebox etc.. it will still trigger.

I am going to try to support other stuff, after I do MAME....but I need others to help jump in here, not to finish THIS one...but to also become familiar with this setup, so that, while a totally generalised version won't be practical..at least make it extensible to add more emulator types.

I'm looking forward to seeing your HowTo on this project (please :)). LMCE should be able to play multiple simul media streams as long as they are "compatible", like screensaver+audio, or even allow override like (muted) video + (independent) audio. Really it should be up to a device what to do with commands to play media when it's already busy (replace, mix, override components, etc).

Pages: 1 ... 3 4 [5] 6 7 ... 38