[slim] Community SB: expansion infrastructure
In the main thread there has been a fair amount of talk about IR blasters, relays etc. This go me thinking about the subject of software expansion, along the lines of plugins, applets, bolt-ons etc. Now seems like a good time to discuss how this wants to be dealt with in a community project. At least in the beginning we will probably still be using LMS, so the existing plugin interface will most likely be used for the server side. But on the player side it does not look like we will be using SqueezePlay which had the "applet" infrstructure. Some simple aspects of player to server communication for things like IR blaster was embedded in slimproto, but I don't think we need to stick with that if we don't want to. A lot of work was done with JSON outside of slimproto. Another issue is how such expansion code will be implemented on the player. In SqueezePlay it was one big monolithic program with a Lua interpreter that handled all the applets, personally I think that is the wrong way to go for this. We have a fairly powerful hardware platform with a fair amount of memory, I think we can get away with multiple cooperating programs, I don't think it has to be one monolithic thing. Having expansion code written in an interpretive language (such as lua) has some big advantages, which still probably exist for this project, but I don't think it has to be one interpreter instance. I don't see why we couldn't have several lua interpreters running at the same time, each one running a particular add-on. The "linux way" tends to be multiple programs cooperating together to make a system rather than one large monolithic thing, and I think with our hardware platform this is certainly doable. But then of course that brings up issues about how these things are distributed and installed, updated etc. All this may be completely unnecessary, but I just have a gut feeling that if some form of framework isn't worked out that everybody that wants to add some little functionality to the system is going to reinvent the wheel and do it their own way and after a while we will have a mess. Any thoughts? BTW I certainly do NOT want to be the keeper of this, I'm doing the hardware, that's enough for me, but I think this needs discussing. John S. JohnSwenson's Profile: http://forums.slimdevices.com/member.php?userid=5974 View this thread: http://forums.slimdevices.com/showthread.php?t=98179 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Community SB: expansion infrastructure
Good ideas, from a user perspective the least you could do is a common installer for these kind of things . If the player has a web UI for settings expand that for add on / app install . If an app has settings , you need to figure a interface for that , maybe expand player settings in LMS or use a corresponding plugin to have settings in advanced plugin settings in LMS . Mnyb's Profile: http://forums.slimdevices.com/member.php?userid=4143 View this thread: http://forums.slimdevices.com/showthread.php?t=98179 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Community SB: expansion infrastructure
JohnSwenson wrote: > > Any thoughts? > I'm not sure the applet infrastructure is going to be completely gone based on what Triode said here: http://forums.slimdevices.com/showthread.php?98156-Announce-JiveLite-cut-down-squeezebox-control-application http://forums.slimdevices.com/showthread.php?97881-Community-Funded-Squeezebox-Replacement-Would-you-be-interested&p=738431&viewfull=1#post738431 The next question is what kind of add-ons people want on this platform. Is it just screen saver related add-ons or are we considering other options to ? I could see a need for add-ons which integrate the HiFi equipment, like IR-blaster and amplifier volume control add-ons, but except for that I mainly see a need to run screen saver related add-ons on the player side. I'm not even sure about IR-blaster and volume control as I believe those are run as server side plugin today and obviously works good, so what remains is probably screen savers. As long as LMS must exist to make the device work, the only add-ons that makes sense on the player side are those that have to run in the HiFi cabinet. If they can run on the server in the storage room in the back there isn't a need to support that kind of add-ons on the player, more or less I think this means that what we need on the player side is a way to make screen savers, custom UI skins and visualizers. It doesn't make sense to run multiple screen savers and visualizers at the same time, but it does make sense to have them separated from the player to ensure a badly performing screen saver won't disturb the audio. I believe Mnyb is on the right track, making it easy to install add-ons is the key. Also, a general recommendation from my side is to not tie any new software too much to LMS, reason being that I'm not sure LMS is going to be what we will use on longer terms for this hardware. LMS has a place on short terms while Logitech is maintaining it, but when Logitech stops maintaining it we will likely switch to something else after a while. I don't think there is enough interest among community developers to step up and start maintaining LMS by themselves, I think we are more likely going to see completely new solutions when LMS stops working. For the UI, on longer terms, I would focus on a XBMC integration rather than making something based on lua and SqueezePlay, because XBMC is more likely to survive on longer terms than something based on lua and SqueezePlay. However, something based on lua and SqueezePlay makes sense on short terms as it might make it possible to re-use a lot of code from existing Squeezebox applets. Another option is to run Android on the hardware and get access to the Android app market. erland's Profile: http://forums.slimdevices.com/member.php?userid=3124 View this thread: http://forums.slimdevices.com/showthread.php?t=98179 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Community SB: expansion infrastructure
I run both XBMC and Squeeze in my household. I have toyed with turning my hifi side of things over to xbmc and it is possible to get pleasing results. However - it is too complex and I'm not sure AudioEngine sounds as good as straight ALSA (although I've not done any subjective testing of this) The main thing is that I don't really like having to tv on to listen to music. Keep it simple. Lem's Profile: http://forums.slimdevices.com/member.php?userid=22702 View this thread: http://forums.slimdevices.com/showthread.php?t=98179 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Community SB: expansion infrastructure
JohnSwenson wrote: > At least in the beginning we will probably still be using LMS, so the > existing plugin interface will most likely be used for the server side. > But on the player side it does not look like we will be using > SqueezePlay which had the "applet" infrstructure. Some simple aspects of > player to server communication for things like IR blaster was embedded > in slimproto, but I don't think we need to stick with that if we don't > want to. A lot of work was done with JSON outside of slimproto. I completely agree for now, but I think we need to have in the back of our minds a desire to move away from LMS -if that's the longer term plan- and planning with this philosophy now could save many a headache later. My own opinion is that the LMS architecture has had its day and we could, if inclined, develop a new architecture that could emulate slimproto to allow older SBs to function without requiring new firmware. simbo's Profile: http://forums.slimdevices.com/member.php?userid=11481 View this thread: http://forums.slimdevices.com/showthread.php?t=98179 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Community SB: expansion infrastructure
'LIRCd' (http://www.lirc.org/) is probably what should be used on the Community SB to handle sending/receiving IR. It's been around a long time and is well tested. The current board has a db9 serial for which there are many IR S/Rs available, it doesn't have to be used for the serial tty login. There is also a couple 'gpio lirc kernel drivers' (http://aron.ws/projects/lirc_rpi/) available so we'd have 2 options without resorting to using up a usb port for IR. The IRBlaster plugin could be modified to talk to an lirc daemon via the unix domain socket support already available for controlling other equipment with IR. Receiving IR back to the server from the device will be a bit more challenging as John suggests. ralphy's Profile: http://forums.slimdevices.com/member.php?userid=3484 View this thread: http://forums.slimdevices.com/showthread.php?t=98179 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Community SB: expansion infrastructure
JohnSwenson wrote: > At least in the beginning we will probably still be using LMS, so the > existing plugin interface will most likely be used for the server side. > But on the player side it does not look like we will be using > SqueezePlay which had the "applet" infrstructure. Some simple aspects of > player to server communication for things like IR blaster was embedded > in slimproto, but I don't think we need to stick with that if we don't > want to. A lot of work was done with JSON outside of slimproto. > > Another issue is how such expansion code will be implemented on the > player. In SqueezePlay it was one big monolithic program with a Lua > interpreter that handled all the applets, personally I think that is the > wrong way to go for this. We have a fairly powerful hardware platform > with a fair amount of memory, I think we can get away with multiple > cooperating programs, I don't think it has to be one monolithic thing. > > Having expansion code written in an interpretive language (such as lua) > has some big advantages, which still probably exist for this project, > but I don't think it has to be one interpreter instance. I don't see why > we couldn't have several lua interpreters running at the same time, each > one running a particular add-on. Why NOT use SqueezePlay? What's the disadvantage? JJZolx's Profile: http://forums.slimdevices.com/member.php?userid=10 View this thread: http://forums.slimdevices.com/showthread.php?t=98179 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Community SB: expansion infrastructure
It contains Logitech proprietary content so can't be redistributed. pippin's Profile: http://forums.slimdevices.com/member.php?userid=13777 View this thread: http://forums.slimdevices.com/showthread.php?t=98179 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Community SB: expansion infrastructure
Ok, then if you can't use SqueezePlay even if you wanted to, then what other choice is there except to rely on a bunch of separate programs working together? That seems to be the guiding philosophy in any case, both in hardware and software - do as little work as necessary to glue whatever is available into a working system. JJZolx's Profile: http://forums.slimdevices.com/member.php?userid=10 View this thread: http://forums.slimdevices.com/showthread.php?t=98179 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Community SB: expansion infrastructure
Similar question, Whats the business case for moving away from Squeezeplay? In the short term 1yr it does the job and you would only need to plug gaps that are proprietary code. Longer term if there is enough interest its worth moving to something completely shiny. There is so much code in LMS it cant all be bad :) apart from the web interface stuck in the 1990s Bluetooth connectivity would be nicer than Infrared, devices could then be out of sight. Yep the whole install/remove extras sucks and needs to be reworked, Logitech should have developed a store front framework cparker's Profile: http://forums.slimdevices.com/member.php?userid=2083 View this thread: http://forums.slimdevices.com/showthread.php?t=98179 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Community SB: expansion infrastructure
JJZolx wrote: > Why NOT use SqueezePlay? What's the disadvantage? > My guess is that on short terms it will be based on SqueezePlay, but it will be called JiveLite: http://forums.slimdevices.com/showthread.php?98156-Announce-JiveLite-cut-down-squeezebox-control-application Which basically is SqueezePlay without Logitech copyrighted content optimized for usage on a big screen like a TV. I'm not sure if SqueezePlay could be redistributed as it is, but based on what Triode has done previously I suspect JiveLite is the way to go on short terms. I know there are copyright issues with icons and and other graphics in SqueezePlay but I doubt Logitech would really care if we re-used them as long as we don't show a Logitech logo in the interface. We are never going to get official permissions from them but it's probably fairly low risk that they will try to sue someone just because we use some icons, at least as long as we are talking about a couple of hundred users. erland's Profile: http://forums.slimdevices.com/member.php?userid=3124 View this thread: http://forums.slimdevices.com/showthread.php?t=98179 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Community SB: expansion infrastructure
erland wrote: > My guess is that on short terms it will be based on SqueezePlay, but it > will be called JiveLite: > http://forums.slimdevices.com/showthread.php?98156-Announce-JiveLite-cut-down-squeezebox-control-application > Which basically is SqueezePlay without Logitech copyrighted content > optimized for usage on a big screen like a TV. > > I'm not sure if SqueezePlay could be redistributed as it is, but based > on what Triode has done previously I suspect JiveLite is the way to go > on short terms. > > I know there are copyright issues with icons and and other graphics in > SqueezePlay but I doubt Logitech would really care if we re-used them as > long as we don't show a Logitech logo in the interface. We are never > going to get official permissions from them but it's probably fairly low > risk that they will try to sue someone just because we use some icons, > at least as long as we are talking about a couple of hundred users. >From the other thread, we don't even know if the thing will _have_ a user interface yet. JJZolx's Profile: http://forums.slimdevices.com/member.php?userid=10 View this thread: http://forums.slimdevices.com/showthread.php?t=98179 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Community SB: expansion infrastructure
simbo wrote: > I completely agree for now, but I think we need to have in the back of > our minds a desire to move away from LMS -if that's the longer term > plan- and planning with this philosophy now could save many a headache > later. > > My own opinion is that the LMS architecture has had its day and we > could, if inclined, develop a new architecture that could emulate > slimproto to allow older SBs to function without requiring new > firmware. > While I agree regarding your LMS worries, I think we on short terms need to accept LMS and try to get something up and running without spending too much effort. On longer terms we need something else, but to make that happen there needs to be a business around this and it's pointless to discuss what will happen then, we will just have to wait and see. Basically, let's take this in baby steps and see how it evolves. cparker wrote: > > There is so much code in LMS it cant all be bad :) apart from the web > interface stuck in the 1990s > It's not about the code being bad, it's about the code having a legacy of almost 10 years development and barely none in the community understanding how the different pieces works together and being willing to take over the maintenance, but as said above it's not an issue on short terms, it will become an issue some time after Logitech stops maintaining it. cparker wrote: > > Yep the whole install/remove extras sucks and needs to be reworked, > Logitech should have developed a store front framework > 100% agree, but a central app store is unlikely to happen unless there is a business/company around it. The tax regulations regarding selling apps world wide from a central store is just too tricky for an individual developer to handle, there is a reason I just use links to PayPal for my commercial plugins. Also, for an app store to be of interest the platform needs to have lots of users, a few thousand users will be way too little to motivate someone to make an operate an app store. erland's Profile: http://forums.slimdevices.com/member.php?userid=3124 View this thread: http://forums.slimdevices.com/showthread.php?t=98179 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Community SB: expansion infrastructure
JJZolx wrote: > From the other thread, we don't even know yet if the thing will _have_ a > user interface. > If it doesn't have a UI, just use the squeezelite player as it is, but I think it's pretty clear that Gen2 will have a UI but maybe not Gen1. erland's Profile: http://forums.slimdevices.com/member.php?userid=3124 View this thread: http://forums.slimdevices.com/showthread.php?t=98179 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Community SB: expansion infrastructure
erland wrote: > If it doesn't have a UI, just use the squeezelite player as it is, but I > think it's pretty clear that Gen2 will have a UI but maybe not Gen1. UI, as in hardware to support the I/O peripherals, or UI as in software? Whether or not the hardware is there, doesn't the software approach need to be figured out as soon as possible, before development begins on Gen1 (or 0.5) code? If the main copyright problems are only with SqueezePlay's graphics, then SqueezePlay sounds like a viable approach. So again, what are the advantages to an approach consisting of separate cooperating programs vs. the monolithic SqueezePlay? Wouldn't development of add-ons like applets be simpler within the framework of SqueezePlay, rather than having to invent means to communicate between the various applications? Other than the philosophical reasoning that John mentioned. JJZolx's Profile: http://forums.slimdevices.com/member.php?userid=10 View this thread: http://forums.slimdevices.com/showthread.php?t=98179 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Community SB: expansion infrastructure
erland wrote: > It's not about the code being bad, it's about the code having a legacy > of almost 10 years development and barely none in the community > understanding how the different pieces works together and being willing > to take over the maintenance, but as said above it's not an issue on > short terms, it will become an issue some time after Logitech stops > maintaining it. Indeed. Not wanting to start any religious wars on programming languages and environments here, but I have seen similar things happen with other projects - a tool/language/environment is chosen (in the cases I have seen, it's been either perl or php) that is good for an initial version, and then features are added, the architecture grows - but the language/tools don't really scale and aren't really up to supporting such a complex piece of software, and the patches start growing patches of their own... I think the important thing would do would be to gather as much information as we can in the wiki about the protocol, so that LMS can be rewritten in a compiled language. Julf's Profile: http://forums.slimdevices.com/member.php?userid=42050 View this thread: http://forums.slimdevices.com/showthread.php?t=98179 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Community SB: expansion infrastructure
JJZolx wrote: > UI, as in hardware to support the I/O peripherals, or UI as in software? > Whether or not the hardware is there, doesn't the software approach need > to be figured out as soon as possible, before development begins on Gen1 > (or 0.5) code? > I'm not 100% sure I've updated myself with the latest info in the thread, but if I've understood it correctly we weren't sure if HDMI would be there until Gen2. I think it wasn't there in Gen1, but then someone found the wandboard and with the wandboard it might be there already in Gen1 and Gen0.5. Either way, as soon as the hardware is available a decision definitely has to be made and I guess that's basically what you are suggesting ? JJZolx wrote: > > If the main copyright problems are only with SqueezePlay's graphics, > then SqueezePlay sounds like a viable approach. So again, what are the > advantages to an approach consisting of separate cooperating programs > vs. the monolithic SqueezePlay? Wouldn't development of add-ons like > applets be simpler within the framework of SqueezePlay, rather than > having to invent means to communicate between the various applications? > Other than the philosophical reasoning that John mentioned. > I personally see a purpose of separating the playback code from everything else because you want to be sure that playback isn't disturbed just because a screen saver isn't implemented the optimal way. This might already be the case in SqueezePlay, I haven't looked at the playback parts much so far, I know there are some separate jive_alsa processes that runs and I suspect they are handling the playback. Except for this, I don't really see a benefit of having it divided into many different parts. I don't look at SqueezePlay as a monolith, it's based on a lot of applets which can be installed and uninstalled. I haven't looked at JiveLite but from the brief description from Triode it sounded like it was more or less based on similar principles as SqueezePlay. If we were talking about many different applets executing simultaneously it would be different, but so far I can mainly see a need for screen saver/visualizer applets and as long as we only have a single screen I can only see a reason to run one at the time and for that something like SqueezePlay/JiveLite should work perfectly. erland's Profile: http://forums.slimdevices.com/member.php?userid=3124 View this thread: http://forums.slimdevices.com/showthread.php?t=98179 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Community SB: expansion infrastructure
Julf wrote: > Indeed. Not wanting to start any religious wars on programming languages > and environments here, but I have seen similar things happen with other > projects - a tool/language/environment is chosen (in the cases I have > seen, it's been either perl or php) that is good for an initial version, > and then features are added, the architecture grows - but the > language/tools don't really scale and aren't really up to supporting > such a complex piece of software, and the patches start growing patches > of their own... > > I think the important thing would do would be to gather as much > information as we can in the wiki about the protocol, so that LMS can be > rewritten in a compiled language. > It's just that the issue isn't just the perl code, the much bigger problem is that some of the protocols has become a bit messy over time and isn't designed to scale to a cloud solution which would be required to support online streaming services, so I'm not sure we want to re-implement them in a different language. The real question we should ask ourselves is how important it really is to support the old Classic/Boom/Transporter/Receiver devices on longer terms, maybe supporting the Touch and Radio which easily can be loaded with custom firmware and the new Community Squeezebox is good enough ? It might feel important now, but is it going to be equally important in three years (or something similar) when our houses hopefully is filled with Community Squeezebox hardware and Logitech decides to shutdown LMS maintenance completely ? Let's take this in baby steps, on short term something more or less based on LMS and SqueezePlay/JiveLite/SqueezeLite should be the easiest way to get something up and running, so let's start with that and see how it evolves. erland's Profile: http://forums.slimdevices.com/member.php?userid=3124 View this thread: http://forums.slimdevices.com/showthread.php?t=98179 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Community SB: expansion infrastructure
erland wrote: > The real question we should ask ourselves is how important it really is > to support the old Classic/Boom/Transporter/Receiver devices on longer > terms, maybe supporting the Touch and Radio which easily can be loaded > with custom firmware and the new Community Squeezebox is good enough ? For multi-player sync, it's absolutely essential. JJZolx's Profile: http://forums.slimdevices.com/member.php?userid=10 View this thread: http://forums.slimdevices.com/showthread.php?t=98179 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Community SB: expansion infrastructure
erland wrote: > > > The real question we should ask ourselves is how important it really is > to support the old Classic/Boom/Transporter/Receiver devices on longer > terms, > > . JJZolx wrote: > For multi-player sync, it's absolutely essential. +10 My 0.02$ the old hardware must be supported until it's technical life time is over there are to many SB2,3 And transporters around. And actually if we want to leverage one of the real stregths of the LMS architecture and use it future systems it is the longevity and backwards compatibility . IMO it could -maybe- be time to drop slimp3 support now and SB1 one 2-3 years into the future Mnyb's Profile: http://forums.slimdevices.com/member.php?userid=4143 View this thread: http://forums.slimdevices.com/showthread.php?t=98179 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Community SB: expansion infrastructure
JJZolx wrote: > For multi-player sync, it's absolutely essential. +1 I also don't think it'd be too difficult to make these old devices think they're still talking to LMS via an API layer, leaving us complete freedom with the underlying architecture. simbo's Profile: http://forums.slimdevices.com/member.php?userid=11481 View this thread: http://forums.slimdevices.com/showthread.php?t=98179 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Community SB: expansion infrastructure
simbo wrote: > +1 > > I also don't think it'd be too difficult to make these old devices think > they're still talking to LMS via an API layer, leaving us complete > freedom with the underlying architecture. +1 You only have to do it once as this protocol is not going to change ever no one will build a new Boom firmware with some new function . Mnyb's Profile: http://forums.slimdevices.com/member.php?userid=4143 View this thread: http://forums.slimdevices.com/showthread.php?t=98179 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Community SB: expansion infrastructure
Mnyb wrote: > +10 > > My 0.02$ the old hardware must be supported until it's technical life > time is over there are to many SB2,3 And transporters around. > > And actually if we want to leverage one of the real stregths of the LMS > architecture and use it future systems it is the longevity and backwards > compatibility . > > IMO it could -maybe- be time to drop slimp3 support now and SB1 one 2-3 > years into the future > I hate to be realistic, but if this project is going to survive on longer terms, it have to be organized in a company and a company will need to make profit, how much do you think SB1, 2, 3 users would be willing to pay 2016 to get support for their almost 10 year old $300 players ? How many of them do you think would prefer to instead spend that money to replace the old devices with a fresh new Community Squeezebox with excellent audio quality ? People often want a lot of things but usually when they realize they have to pay for it they don't think it's worth it. erland's Profile: http://forums.slimdevices.com/member.php?userid=3124 View this thread: http://forums.slimdevices.com/showthread.php?t=98179 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Community SB: expansion infrastructure
simbo wrote: > > I also don't think it'd be too difficult to make these old devices think > they're still talking to LMS via an API layer, leaving us complete > freedom with the underlying architecture. Just for reference, I happen to know that there are several people who have tried to implement SlimProto in third party servers with the intention to replace LMS, as far as I know none have succeeded to get 100% compatibility. So even if I haven't looked into it in detail myself, I'm fairly sure it's not as easy as you make it sound like. erland's Profile: http://forums.slimdevices.com/member.php?userid=3124 View this thread: http://forums.slimdevices.com/showthread.php?t=98179 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Community SB: expansion infrastructure
erland wrote: > I hate to be realistic, but if this project is going to survive on > longer terms, it have to be organized in a company and a company will > need to make profit, how much do you think SB1, 2, 3 users would be > willing to pay 2016 to get support for their almost 10 year old $300 > players ? > How many of them do you think would prefer to instead spend that money > to replace the old devices with a fresh new Community Squeezebox with > excellent audio quality ? > > People often want a lot of things but usually when they realize they > have to pay for it they don't think it's worth it. Damn you and your realism ;) I think this all depends on where this project is heading. From my standpoint, I've made an investment in older SB devices and I'd like to contribute to a project that will allow me to extend and improve on that investment. Also, I've yet to see anything on the market that provides a similar service at the same price point. If we really are talking about getting proper corporate support, maybe the SB2/3/Boom owners would provide a great market from-the-go to buy more devices? Regardless, there are plenty of community projects that are doing well without corporate investment - just look at the media centre ecosystem with MediaPortal, XBMC, etc. I'm not saying you're wrong, and I do think it's too early to be planning a complete replacement to LMS, but I don't think we should rule it out. simbo's Profile: http://forums.slimdevices.com/member.php?userid=11481 View this thread: http://forums.slimdevices.com/showthread.php?t=98179 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Community SB: expansion infrastructure
This looks like another thread for multiple people to have opinions on Let me comment on my views on the architecture and the software I am looking at: 1) Playback should be a small self contained application which is able to be deployed on multiple devices with a minimal memory footprint. It will be optimised for real time performance and low memory footprint. This is what squeezelite is - its a C only implementation of a squeezebox playback implementation which is reasonably efficient for deployment on small footprint linux devices. At present it supports most major codecs with the exceptions of wma and alac and is being run by quite a few people already. Squeezelite is already at release 1.0 and I believe most of the bugs are already resolved with this... (YMMV) 2) User interface can and should be a separate application and is probably best mainly written in a higher layer scripting or other language. What I propose for this is jivelite which is a cut down version of squeezeplay and support applets and scripting to extend its capabilities. Initially my focus is to create the framework for this as I am making some significant internal changes to the jive code for this. I am currently using the Logitech icons as they are all part of the development tree which has a BSD license, but I would like to replace the icons with ones which we generate. My primary target for this will be to get to a new skin which works on a 1080p display. I did look at xbmc but was concerned that for just rendering a user interface it looked to be overkill and specially on the platform I tested on it seemed to use high cpu load to continuously render the display. For an audio device which would ideally not do any display activity unless there is something to show and would allow us to disable the display completely I took the view that we would be better to have direct control over this. 3) I am assuming at least in the medium term LMS remains as the server application. However longer term its possible to do more in applets scripted as part of jivelite and possibly creating direct control of squeezelite from jivelite (for instance I'm thinking of a spotify applet) 4) IR control and other user interface devices need to be integrated with jivelite as this is how it will be controlled. This will require us to work on getting a common set of user interface options for it. (Jivelite is sdl based so we need to provide input to sdl which should be reasonably well supported) 5) Specific audio output drivers - this bit is the only bit which I think needs to be specific to the wandboard based community squeezebox hardware. This will require us to develop whatever is necessary to drive the hardware John is planning. [I think John and Clive have been talking on this] Jivelite is very early days at present - I'll post more on the linux thread when I have more for people to test... I would be interested in anyone who has graphics art skill who can create some more icons for us at some point. Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=98179 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Community SB: expansion infrastructure
Triode wrote: > I did look at xbmc but was concerned that for just rendering a user > interface it looked to be overkill and specially on the platform I > tested on it seemed to use high cpu load to continuously render the > display. I had the same issue on the R-Pi and I understand it's a well-known problem. That's the downside of community software projects - they tend not to be well optimised. simbo's Profile: http://forums.slimdevices.com/member.php?userid=11481 View this thread: http://forums.slimdevices.com/showthread.php?t=98179 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Community SB: expansion infrastructure
simbo wrote: > I had the same issue on the R-Pi and I understand it's a well-known > problem. That's the downside of community software projects - they tend > not to be well optimised. Well in this case its intended to render video images, so it its scaled to perform well doing this and there's no real downside in using the same rendering for the menus - in our case I believe we want a relatively static image and ideally minimal/no overhead if it is not doing anything... Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=98179 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Community SB: expansion infrastructure
erland wrote: > I hate to be realistic, but if this project is going to survive on > longer terms, it have to be organized in a company and a company will > need to make profit, how much do you think SB1, 2, 3 users would be > willing to pay 2016 to get support for their almost 10 year old $300 > players ? > How many of them do you think would prefer to instead spend that money > to replace the old devices with a fresh new Community Squeezebox with > excellent audio quality ? > > People often want a lot of things but usually when they realize they > have to pay for it they don't think it's worth it. Well, well. How much do you predict Touch users are willing to pay more than those destitute SB1-3 owners ?? I only use SB3 and Booms, because I like these models. Later ones were, IMO, POS. Except for Touch which is ok, except I don't care AT ALL for a color screen. Audio quality is, as you know, not an issue and we have DACs if needed (since an unsupported TP is not an option.) I am not missing 24/96 and aboveĀ If the new Community Player is supposed to align with HTPCs or smart phones and look like a christmas tree, let me know and I'll stop following the thread. My interest is in reliability, sound quality, home integration. Ah yes, running a nice VU-meter, too. Limiting the amount of what *must* run in the player is important for reliability and lifespan. I change PC every 2-3 years, I change hifi every 10 years at most. The original slim models had this right. epoch1970's Profile: http://forums.slimdevices.com/member.php?userid=16711 View this thread: http://forums.slimdevices.com/showthread.php?t=98179 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Community SB: expansion infrastructure
Triode wrote: > 5) Specific audio output drivers - this bit is the only bit which I > think needs to be specific to the wandboard based community squeezebox > hardware. This will require us to develop whatever is necessary to > drive the hardware John is planning. [I think John and Clive have been > talking on this] That's all I seem to have been doing, talking. After I spoke to you I did some brain scratching. I think I'm very close to getting a known name in Linux kernel circles (who happens to be a friend) on-board specifically for the kernel parts that John needs. Hopefully I should have a definite one way or the other very shortly. I've seen mention of XBMC in this thread (and another). Please, no We need to deliver something, preferably before April 2016, not go off at a tangent. ;) With regard to software, LMS is the server backend. (Like it or loathe it. Until someone has a replacement up and running it's no use doing anything other than using what we have today.) Squeezelite is the client player. That, along with John's DAC design and the Wandboard will deliver a high quality standalone headless player. It should have a web interface to be able to configure the network interfaces (eth & wlan) and allow the configuration of squeezelite without having to directly edit a text file. If there is some sort of GUI (music player controller) actually on the device, available via a HDMI port, (Jivelite), that's a bonus, rather than a necessity. I mean there are already enough ways of being able to control it, from a phone, from a pad, from a computer, that a built-in GUI controller is a luxury rather than a necessity. Well, that's how I see it anyway.. JackOfAll's Profile: http://forums.slimdevices.com/member.php?userid=3069 View this thread: http://forums.slimdevices.com/showthread.php?t=98179 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Community SB: expansion infrastructure
JackOfAll wrote: > I've seen mention of XBMC in this thread (and another). Please, > no We need to deliver something, preferably before April 2016, > not go off at a tangent. ;) I only used XBMC as an example of a successful community-driven software project. I certainly wouldn't want us to tie ourselves to it in any shape or form. JackOfAll wrote: > With regard to software, LMS is the server backend. (Like it or loathe > it. Until someone has a replacement up and running it's no use doing > anything other than using what we have today.) Totally agree, but I'd like to think we can ensure the hardware, drivers and software being delivered -now- won't prevent the opportunity for an LMS replacement -in the future- by locking us to it. simbo's Profile: http://forums.slimdevices.com/member.php?userid=11481 View this thread: http://forums.slimdevices.com/showthread.php?t=98179 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Community SB: expansion infrastructure
epoch1970 wrote: > Well, well. How much do you predict Touch users are willing to pay more > than those destitute SB1-3 owners ?? > Probably not much, but the Touch and Radio would be easier to adapt to a new architecture, making it possible to get rid of some of the legacy and move on to something new. But as said previously, we need to take this in baby steps, on short terms relying on LMS is the only realistic solution. erland's Profile: http://forums.slimdevices.com/member.php?userid=3124 View this thread: http://forums.slimdevices.com/showthread.php?t=98179 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Community SB: expansion infrastructure
Gen05 is going to have an ethernet jack, serial port, RCA analog and TOSLINK digital, and two host USB ports, thats it. It just enough to be able to get drivers going for our audio interfaces. I'm thinking that this just has Squeezelite for the first launch of Gen1 boards. Gen1 as I'm envisioning it now will have the above plus HDMI out, coax S/PDIF and headphone jack. I'm going to include the module connector for the wifi module I've mentioned, we will have to decide whether we want to go that route or use onboard wifi on the dual wandboard. Putting the connector on the board doesn't add much to the complexity/cost. The linux image developed with gen0.5 should be enough for Gen1 to be usable as a headless player out of the box. All the rest can be done once more people have Gen1 in their hands. The wandboard module has all the pins brought out to do an onboard LCD and touch interface, either separate from the HDMI, or driven with the same image. So a later version could add a touch/LCD display, without needing too much in the way of software change. Thanks everybody for chiming in on this, I think it's an important discussion to have. Triode, if we go with Jivelite, one thing I would find VERY helpful is some better documentation on the applet graphical API. I tried for a year to write some fairly simple applets but could never figure out how to get on the screen what I wanted. Even after spending months with the source code I still couldn't figure out how the "style" system worked. Now I know I'm a hardware oriented guy and some of the aspects of this are probably obvious to you software guys, but a few little hints would go along way. This is probably one of my main reasons for not wanting to go with Squeezeplay as it is, I found the lack of documentation for applet writing to be a major stumbling block for me. I was kind of hoping we could put something together that was a lot easier to learn. John S. JohnSwenson's Profile: http://forums.slimdevices.com/member.php?userid=5974 View this thread: http://forums.slimdevices.com/showthread.php?t=98179 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Community SB: expansion infrastructure
Triode wrote: > This looks like another thread for multiple people to have opinions > on Let me comment on my views on the architecture and the software I > am looking at: > > 1) Playback should be a small self contained application which is able > to be deployed on multiple devices with a minimal memory footprint. It > will be optimised for real time performance and low memory footprint. > This is what squeezelite is - its a C only implementation of a > squeezebox playback implementation which is reasonably efficient for > deployment on small footprint linux devices. At present it supports > most major codecs with the exceptions of wma and alac and is being run > by quite a few people already. Squeezelite is already at release 1.0 > and I believe most of the bugs are already resolved with this... (YMMV) > > > 2) User interface can and should be a separate application and is > probably best mainly written in a higher layer scripting or other > language. What I propose for this is jivelite which is a cut down > version of squeezeplay and support applets and scripting to extend its > capabilities. Initially my focus is to create the framework for this as > I am making some significant internal changes to the jive code for this. > I am currently using the Logitech icons as they are all part of the > development tree which has a BSD license, but I would like to replace > the icons with ones which we generate. My primary target for this will > be to get to a new skin which works on a 1080p display. > > I did look at xbmc but was concerned that for just rendering a user > interface it looked to be overkill and specially on the platform I > tested on it seemed to use high cpu load to continuously render the > display. For an audio device which would ideally not do any display > activity unless there is something to show and would allow us to disable > the display completely I took the view that we would be better to have > direct control over this. > > 3) I am assuming at least in the medium term LMS remains as the server > application. However longer term its possible to do more in applets > scripted as part of jivelite and possibly creating direct control of > squeezelite from jivelite (for instance I'm thinking of a spotify > applet) > > 4) IR control and other user interface devices need to be integrated > with jivelite as this is how it will be controlled. This will require > us to work on getting a common set of user interface options for it. > (Jivelite is sdl based so we need to provide input to sdl which should > be reasonably well supported) > > 5) Specific audio output drivers - this bit is the only bit which I > think needs to be specific to the wandboard based community squeezebox > hardware. This will require us to develop whatever is necessary to > drive the hardware John is planning. [I think John and Clive have been > talking on this] > > > Jivelite is very early days at present - I'll post more on the linux > thread when I have more for people to test... I would be interested in > anyone who has graphics art skill who can create some more icons for us > at some point. This jivelite suppose it's also for other interfaces than hdmi ? I'm not particularly interesed in TV based UI (some are ) I would not really want to turn on a tv for controlling the player , I do have iPad and iPhone for control . Or are there suitable touch screens and other small screens that uses hdmi ? screensavers could be cool in some applications . Mnyb's Profile: http://forums.slimdevices.com/member.php?userid=4143 View this thread: http://forums.slimdevices.com/showthread.php?t=98179 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Community SB: expansion infrastructure
Why is an applet system needed ? To run commercial apps not allowed to mix with an open source server ? The ability to run Android or other apps may be interesting, for radio services and such, but I fear the interface will be dreadful. And how will the SB player (main feature) interoperate with random apps ? I think one plugin system is enough, the intelligence of the device should be in the server. The server can be in the device if so required. My 2cts. epoch1970's Profile: http://forums.slimdevices.com/member.php?userid=16711 View this thread: http://forums.slimdevices.com/showthread.php?t=98179 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Community SB: expansion infrastructure
epoch1970 wrote: > Why is an applet system needed ? To run commercial apps not allowed to > mix with an open source server ? The ability to run Android or other > apps may be interesting, for radio services and such, but I fear the > interface will be dreadful. And how will the SB player (main feature) > interoperate with random apps ? > > I think one plugin system is enough, the intelligence of the device > should be in the server. The server can be in the device if so required. > > My 2cts. We could buy Logitech from the number of 2cts posted on this forum :) Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=98179 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Community SB: expansion infrastructure
My 2cts. We could buy Logitech from the number of 2cts posted on this forum :) Good plan. If you only took the SB group, you could even save some! -- Michael ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Community SB: expansion infrastructure
JohnSwenson wrote: > Gen05 is going to have an ethernet jack, serial port, RCA analog and > TOSLINK digital, and two host USB ports, thats it. It just enough to be > able to get drivers going for our audio interfaces. I'm thinking that > this just has Squeezelite for the first launch of Gen1 boards. > > Gen1 as I'm envisioning it now will have the above plus HDMI out, coax > S/PDIF and headphone jack. I'm going to include the module connector for > the wifi module I've mentioned, we will have to decide whether we want > to go that route or use onboard wifi on the dual wandboard. Putting the > connector on the board doesn't add much to the complexity/cost. Will Gen1 also have GPIO? Maybe it's just me, but I see value in having presets even on a display-less device. Mark Miksis's Profile: http://forums.slimdevices.com/member.php?userid=529 View this thread: http://forums.slimdevices.com/showthread.php?t=98179 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Community SB: expansion infrastructure
I probably should have posted a link here first as this thread is more developer orientated. My latest Wandboard Dual Image, based on F18, 'Plastic Box Which Plays Noises' (http://forums.slimdevices.com/showthread.php?98190-Plastic-Box-Which-Plays-Noises). JackOfAll's Profile: http://forums.slimdevices.com/member.php?userid=3069 View this thread: http://forums.slimdevices.com/showthread.php?t=98179 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
