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).
-
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 boa
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/mailma
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 fe
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 r
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 m
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 envisioni
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 someth
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
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 b
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
>
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
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-k
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. I
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
>
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 implemen
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 an
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 wil
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.
---
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 suppo
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
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 initia
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
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
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 appr
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.
---
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 it
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
>
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 Squ
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 LM
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 avai
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
___
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 aspe
'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.
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 aspe
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)
T
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?
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
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
39 matches
Mail list logo
