this is a great post, i appreciate the consideration given without ire,
i'll try to truncate my responses:

erland;174700 Wrote: 
> I'm not a GPL expert but I think it probably would be possible to do
> this as a separate thing from slimserver, the result would be that you
> wouldn't have to license it as GPL.

as was pointed out, i don't know, i'm not a pro in these matters.

but i would imagine that if i used any of their info in any way, they'd
have the right to use my work.  very reasonable imo.  it just means that
i probably couldn't make money off it, as someone else suggested i
should try to, not that that was ever my intent.

erland;174700 Wrote: 
> From my perspective there is a number of ways to do it:
> 1. A device driver connecting to slimserver, using the already existing
> CLI interface to add and play the currently played track on your PC.
> 2. A device driver implementing SlimProto and connecting directly
> towards the SqueezeBox.
> 
> In both situations you don't have to mix your code with any GPL
> licensed code, so you shouldn't have a problem with the GPL license.
> 
> Note! I'm not sure my understanding of GPL is completely correct, so
> you might want to check with someone that knows it better before you
> start.

no danger in me starting.  and i have no problem in saying this isn't
my field.  of course, neither is politics, but i have opinions there
too.  ;)

erland;174700 Wrote: 
> Regarding a device driver you should note that there are a number of
> problems you need to solve.
> 1. You probably want some of your PC sound to go through the PC
> speakers and some other sounds to go through the SqueezeBox. So the
> software you are using on the PC probably would have to support some
> way of selecting output device.

since xp supports multiple sound cards, a lot of apps allow you to pick
the specific audio device, or the "direct sound" api, or what have you.

so if the option is there, from an app perspective, its no problem. 
and this allows the user to send music only to one set of speakers,
system sounds to another.

erland;174700 Wrote: 
> 2. The SqueezeBox is a networked device, networks sometimes sends data
> fast and sometimes not. SqueezeBox solves this by buffering all sound
> before its played. This works since slimserver knows the next thing
> that is going to be played so it can send it in advance to the
> SqueezeBox, that wouldn't be the case with a device driver. The result
> you probably be bad sound quality. I guess the SqueezeBox could buffer
> the data by it self, but you probably don't want a delay of 15 seconds
> from the time you press play until the music starts. Another issue with
> the buffering is that you probably expect the sound to be in sync with
> the visualization stuff in the player of your choice, due to the
> network and buffering this will probably be hard to accomplish.

ok, admittedly i'm def out of my depth here...  i am not sure first if
anyone offers a tcp/ip audio device via device driver, but someone may.
if so, it would show it could be done.

i know in radio, there are very similar types of routing devices.

but in any case, couldn't the driver work like a delay in terms of
buffering?

you hit play, and it starts to play right away, hopefully getting all
the bits it needs for the first few seconds or so, while at the same
time, you build up (buffer) the next seconds.

this would be fairly easy for local files, but i can see where for net
streams, a wait to play mode might have to take effect.  of course,
that not too far different from the current way it works now, (in terms
of user interaction)

that all of course assumes that the driver could request for the
information to be pulled from the app faster than real time i guess... 
but the SB buffer could handle a lot in advance if it could, thus
mitigating network problems.

erland;174700 Wrote: 
> If you are not a developer yourself, I'm sure there are many developers
> that would be interested in helping you if you just payed them for
> their work. As an example you might want to look at
> http://www.rentacoder.com or similar sites.

i appreciate the suggestion, and actually i may use them for other
stuff, but this is something i already paid for, and i don't think i
should have to pay more for something that will benefit a lot of
people, not just me.

erland;174700 Wrote: 
> All those companies selling iPod accessories sure have a hard time
> selling their stuff, don't they ?

not really.  i know thats your point, but its really not a valid
comparison.

erland;174700 Wrote: 
> If a device driver solution were available, I'm sure it would be
> possible to get an agreement with SlimDevices/Logitech to announce it
> somewhere here.

definitely.

erland;174700 Wrote: 
> I'm not into betting, but I think there is a lot of other things that
> are more important than a device driver. I would be dissapointed if
> SlimDevices/LogiTech choosed to write a device driver as the next thing
> instead of focusing on improving the current SlimServer/SqueezeBox
> architecture.

again, why not both?  i'm not saying either / or.

erland;174700 Wrote: 
> If a device driver could be written by a 3rd party developer on the
> other hand that would be good, then you would get what you want and I
> would still get the benefit of improvements in the current architecture
> by SlimDevices/Logitech. As I see it this is one of the strenghts with
> the open source solution with available protocol specifications.
> SlimDevices/Logitech can focus on the core and 3rd party developers can
> focus and the add-ons and bells and whistles. 
> 
> What I'm a bit tired of is people that just complain on the current
> solution and aren't willing to help improving it themself or paying for
> someone else to do it. I still appreciate that people are announcing
> what things they like to be improved, because thats a matter of getting
> feedback, but when they just repeat the same thing over and over again
> it is starting to get a bit annoying. You should be aware of that
> although many parts of SlimServer has been written by SlimDevices there
> are also a lot of contributors who have spent their free time without
> any salary contributing to it in one way or another. Some contribute by
> writing code, others contribute by helping to find bugs or beta testing
> the stuff.

well, this thread was for making suggestions and gripes, etc...  its
just when i made mine, i got attacked for it.  i still don't understand
that, but hey, everyone has their pet tech loves i guess.

getting back to your suggestion...

assuming a user had a stable local network capable of using SS/SB as it
exists now, how valid is it that using the SB via a audio device driver
and TCP/IP would be anymore problematic than current networking
issues?

i'm asking b/c i don't know...  it just seems to me the same BW gets
used, only the how is different.  how impactful is this change to the
network and the quality of the given audio?


-- 
MrSinatra

www.LION-Radio.org
Using:
Squeezebox2 w/SS 6.5.1 (beta!?) - Win XP Pro SP2 - 3.2ghz / 2gig ram
------------------------------------------------------------------------
MrSinatra's Profile: http://forums.slimdevices.com/member.php?userid=2336
View this thread: http://forums.slimdevices.com/showthread.php?t=31324

_______________________________________________
discuss mailing list
[email protected]
http://lists.slimdevices.com/lists/listinfo/discuss

Reply via email to