Go Back   Winamp & Shoutcast Forums > Winamp3 > Wasabi Development

 
Thread Tools Search this Thread Display Modes
Old 23rd July 2002, 05:45   #1
Garious
Junior Member
 
Join Date: Jul 2002
Location: Chicago
Posts: 21
Project: Perfect Sync of Winamp3 over LAN

Certainly this is not a new idea, but I haven't seen anyone go all out with it yet (sorry if I just didn't look hard enough). At school, we throw a lot of parties and we like the same music blasting from every room. To do that I need all the computers in my house play music in perfect sync and stay in perfect sync. Already developed, we could use ShoutCast, but then each stream is a few seconds out of sync. There's also NetSync for 2.x, which I haven't actually tried but I've heard looses sync after a couple songs (please tell me if this is not the case). Anyway, I'd like to start an open-source project designing a perfectly synced Winamp across a LAN and am calling upon Winamp community to help with ideas, the high-level design and perhaps the implementation.

Some thoughts on making the sound sync:
What I know is that when I use ShoutCast, the streams are off, but why? There are several buffers in the system that cause delay but I have no idea which would cause a significant difference in different computers.

There's the network delay which could be brought down significantly by forgeting about TCP and using UDP broadcast (or multicast if practical) to send just one packet to multiple clients on the LAN. Every computer would get the same real-time data within milliseconds of each other. It's also possible the network delay is just caused by the packets being too big.

There's the Winamp buffering delay. Here's an area where I'm really in the dark. Will faster computers buffer less, simply because they can? If so, if there's hooks within Winamp, it should be possible and not all that hard to sync the clocks on everyone's computer. Then you could simply have a massive buffer controlled by time.

Lastly, there's the sound card delay. If the time it takes for a sound packet to propagate through the card causes more than a half-second difference between cards, then I may just bail on this idea all together, because I can think of no generic way to sync everyone's sound card. That'd be a royal pain. The only hack I can think of is to calibrate your Winamp by listening to the room next to you and adjusting a delay till they sound okay and then hope they stay in sync.

So I'm looking for feedback. If you've tried to sync and know it's just about impossible to make perfect, please tell me and save me some time.

If it turns out it is possible...
In Winamp3, where's the hook to for a component to pull out the sound packet before it plays (and likewise where I can drop one in)?

Let me know if you'd like to help develop in this project. I have plenty more ideas that follow up syncing that would require more people if you want to see every feature before Winamp4:
sync each playlist
allow any computer to modify the playlist, and change songs
access permissions so that you and your roommates can change songs anywhere, but some drunk won't clear a massive playlist you set up.
keychain remote Winamp, so that you don't have to get off your lazy ass to skip a bad song or turn up the tunes.
Garious is offline  
Old 23rd July 2002, 06:07   #2
Garious
Junior Member
 
Join Date: Jul 2002
Location: Chicago
Posts: 21
Alright, so two seconds after I posted I saw the FAQ. oops. For some reason, I was thinking sound was like video game updates where you just apply the most recent update as soon as you get it.

Instead of syncing the sound packets, maybe the way to go with this is syncing the control signals like 'play' and 'next'. For every song, at about 3 seconds before the end of the song, have the server send out a 'next' signal and have every winamp crossfade to the next song. Or, without crossfading, have each client wait till the end of the song, send a signal to the server that it is DONE. When the server gets the DONE signal from everyone, you start up the next song (and obviously this can be optimized, by starting the sync just before the end of the song, but you get my point).

What do ya think? Should I just stop posting?
Garious is offline  
Old 23rd July 2002, 17:04   #3
thepyr0x
Major Dude
 
thepyr0x's Avatar
 
Join Date: Oct 2001
Location: At my house in a city in Canada
Posts: 1,336
you're right it isn't a bad idea, however at the same token, it would never be perfectly in sync no matter how hard u try; and therefore it would sound like shit

thepyr0x is offline  
Old 23rd July 2002, 17:17   #4
Darkain
Major Dude
 
Darkain's Avatar
 
Join Date: Apr 2001
Location: Tacoma, WA
Posts: 1,224
Send a message via ICQ to Darkain Send a message via AIM to Darkain Send a message via Yahoo to Darkain
hey, no too bad. and if you could get it within even 50ms sync, itll be good. cause i mean, i got a prog thatll delay my rear speakers output by aprox 50ms, and it just makes a small echo type effect. it aint that bad.

one way to get nearly perfect sync on all computer, this is gonna be a bit tricky, but i think itll work... if while winamp is playing, it also has the sync component recording the wave output, this was its for perfect sync with the sound card, and therefor can adjust forwards or backwards the audio as needed.

-=- Darkain Dragoon -=-
-=- RM-X Home Page - Controlling Winamp via RM-900, RM-1000, RM-1500, ATI Remote Wonder, Joysticks, Gamepads, Wheels, Keyboard shortcuts, Multimedia keyboards, across the net, and much more! -=- Defenestration !!! -=-
Darkain is offline  
Old 23rd July 2002, 17:38   #5
thepyr0x
Major Dude
 
thepyr0x's Avatar
 
Join Date: Oct 2001
Location: At my house in a city in Canada
Posts: 1,336
there is a way that I can think *might* work, but I kinda doubt it
if you had the plugin sync up the times of each and every computer that would be participating; then you could have your plugin send out a signal that would tell them to buffer x song, and start playing exactly 1 second after the signal was sent (in the signal you would give the time, not just 1 second after); that theoretically should work

however synching up even 2 computers to be anywhere less than 100ms (just the system time) is quite an accomplishment in itself

thepyr0x is offline  
Old 23rd July 2002, 21:56   #6
ProneaX
Senior Member
 
ProneaX's Avatar
 
Join Date: Aug 2001
Posts: 206
Send a message via AIM to ProneaX
If this is all in one house (did I catch that right??) Then there is another way to get around this. If you hook all the speakers in the house up to one computer, then they would all be synced. This might require running through an amplifier I'm not familier with how far signals run efficiently in these settings. Then, if you have an RF remote (NOT an IR remote) hooked into winamp, then you can control playback from anywhere in the house (RF remotes work up to about 100 feet away and they transmit through walls and ceilings).
Turtle Beach offers a stand alone RF remote. It's meant to work with thier proprietary software but might be able to work. Streamzap also offers a remote as does ATI . Find more here.
If you have other computers where you want to change the playlists etc. alongside using the RF remote here are some options:
Winamp 2 remote control plugins
Or you could use a VNC
There are some interesting conversations In these threads

Hope this helps and again I'm not saying don't do it your way but giving an alternative. Please any corrections or comments to what I've said are appreciated.
ProneaX is offline  
Old 24th July 2002, 15:20   #7
Garious
Junior Member
 
Join Date: Jul 2002
Location: Chicago
Posts: 21
The idea of waiting for the winamp buffer to load before playing is an important one. I don't know much about the SDK yet, but I somehow doubt there's a way to load the play buffer without actually playing the song. If there is, problem solved. If not, I'm thinkin all we need to do is start playing the song and then pausing it as soon as the time into the song is nonzero. Then you know the buffer is loaded and the server can send the unpause signal as soon as all the clients have reported that they are ready to go. Unfortunately, I also doubt that the granularity of time into each song is less than a second. My plan would only work if it were in milliseconds or less.

Also, even though I said earlier that I wanted everything in *perfect* sync, I'd be content as long as they were within 100 ms, and never diverged after any amount of songs.

In the path from when a playlist first sees a song to play, to where the sound packet is sent to the soundcard, could somebody post each point where a component can hook into the system?
Garious is offline  
Old 24th July 2002, 17:18   #8
thepyr0x
Major Dude
 
thepyr0x's Avatar
 
Join Date: Oct 2001
Location: At my house in a city in Canada
Posts: 1,336
ok, well that could potentially be done like that; however you cannot have any crossfading on, and you'd have to set winamp to not automatically go to the next song, instead to stop after each and wait for the signal from the server to queue up the next song.

Quote:
Originally posted by Garious
In the path from when a playlist first sees a song to play, to where the sound packet is sent to the soundcard, could somebody post each point where a component can hook into the system?

u lost me there...

thepyr0x is offline  
Old 24th July 2002, 19:31   #9
Garious
Junior Member
 
Join Date: Jul 2002
Location: Chicago
Posts: 21
What I mean by hooks is places where the Winamp kernel will call the code in your component when a particular event happens. In the MAKI scripting language for winamp, there are hooks for every major event for the user interface. You can say:
onPlay() { do this }
onStop() { do that }

I'm wondering if there are similar hooks for components that allow to register functions with the kernel.

On top of the hooks that MAKI supports, we'd need more calls such as:
onPlaylistSeesNextSongIsUp (String song_name)
onPlayBufferFull ()
onPlayBufferEmpty ()
onPacketReadyToSendToSoundCard (Packet*)

Having calls like this (which may or may not already exist) allow you to write interrupt-driven software rather than polling for events or making synchronous calls (calls that don't return until the action in completed). It allows third-party developers to add extra goodies to the kernel as it goes through it's normal activity. MAKI does an excellent job with that, and I'm just wondering if the SDK has similar and more advanced features for components.
Garious is offline  
Old 25th July 2002, 04:59   #10
thepyr0x
Major Dude
 
thepyr0x's Avatar
 
Join Date: Oct 2001
Location: At my house in a city in Canada
Posts: 1,336
well, you'd hafta check std.mi and the sdk to find out what kind of calls wa3 supports and whatnot.......hrm, maybe this could be a way for me to jump into wa3 programming (I know programming, just not c++/maki)

ok, on running thru std.mi myself (and throughly convincing myself I really wanna learn wac programming), here's what I found. seemingly, onPlay registers when winamp3 begins playing and not when it begins buffering (i'd check but I'm not sure how right now). for onSystemSeesNextPlaylistItem I think, since (to my knowledge) there is no such thing, what you would have to do is take the next playlist item selecting into your own hands. you would check to see whether or not random was enabled, if it was select a random track, ir not then just select the next track in the playlist; then once you have arbitrarily decided what song will play, you can tell each client what song will be next, and have them remember that. then, once the server finishes a song, it will start the next song immediately, and use onPlay { pause }, at which time it would tell the rest of the servers to play and then do onPlay { pause }. after waiting a second or two, your server would tell each client to play, and a few ms later (you could somehow integrate a ping into the wac so that it knows approx how long to wait) begin playing itself



do I make any sense whatsoever??


Last edited by thepyr0x; 25th July 2002 at 05:16.
thepyr0x is offline  
Old 25th July 2002, 06:49   #11
Garious
Junior Member
 
Join Date: Jul 2002
Location: Chicago
Posts: 21
I started looking through the SDK, and a lot of things are starting to look very possible.

I believe we can pull design this thing so it could do everything ShoutCast can do in addition to optionally syncing with those connected to you.

...and so i began to architect.

Terms:
Client - a component in Winamp that plays what song it is told
Server - a component in Winamp that controls the playlist
and tells clients what to play

There is an important distinction between client and server in that the two components have no overlapping duties. If the instance of Winamp that is acting as the server wants to also play music, he must start a client component and have it register to its own IP.

The server will be extremely lightweight in that it will only broadcast control signals and URLs.
The client will be responsible for streaming the current and next song.

In sync-mode, the client will start filling a local file from the stream for the current song. After it has enough data to play and not run dry from a slow DL, it will send a signal to the server saying that it is ready. When everyone is ready, the server will send a message out to everyone saying to start playing the file. Assuming the connection stays stable, the file will continue to fill as the song is played. If the connection is fast enough, after a few seconds of playing the current song, a separate thread will start downloading the next song. This way, if you want to skip the current song, the client can immediately tell the server it's ready to play. This syncing will occur at the start of every song so that the sound card doesn't have enough time to throw things off.

In async-mode, the client will simply stream the URLs it's given and play them as soon as it can.

The details:
By doing this in *delayed-time* rather than real-time allows us to use all TCP which makes it so we can establish connection from inside a firewall, so long as the server is on a public IP (or within the firewall).

When the client establishes a connection with the server, the server will tell it to cross-fade or not and the cross-fading preferences. The client will save the old settings and apply the server's settings, which will remain while the client is connected.

Winamp3 hooks:
We need to find out how to capture the play and next events and then clear them so they cannot go through the rest of the system and actually play anything. As for now, we should also disable most other events such as jumping to the middle of the song.

The only other calls we need to make are getting the current and next song, as well as calling play which are all really simple.

I got to hand it to the Winamp3 development staff, the SDK code is beautiful. It looks to me that this project will be a breeze because of it.

The reason why I posted this architecture and didn't just go implement it is because I want to know what other people think of this strategy. If you think it'll work, let us know. If not, let us know. I'll open-source everything I write so if you're thinking of adding features on top of this, tell me now so I can make you some hooks into the code.

Lastly, my interest in this component is syncing Winamp. Therefore I will probably terribly lazy about putting any sort of decent GUI on top. If you'd like to help, I can do all the annoying networking and buffering stuff, and so the interface to Winamp and the GUI are up for grabs. Who's up for it?

-Greg
Garious is offline  
Old 25th July 2002, 21:58   #12
ProneaX
Senior Member
 
ProneaX's Avatar
 
Join Date: Aug 2001
Posts: 206
Send a message via AIM to ProneaX
Garious + Greg = Gregarious???

gregarious \grih-GAIR-ee-us\, adjective:
1. Tending to form a group with others of the same kind.
2. Seeking and enjoying the company of others.

Is this on purpose?
ProneaX is offline  
Old 25th July 2002, 22:04   #13
ProneaX
Senior Member
 
ProneaX's Avatar
 
Join Date: Aug 2001
Posts: 206
Send a message via AIM to ProneaX
(last post was before reading your lost post lol)

Anyway this sounds great. I'm not much help as far as coding goes bc I don't know C++ or Maki and frankly don't have the time right now.
You talk about differentiating between "client" and "server" well from what I gather about wasabi you might be able to compile it as a separate exe from winamp??? is this correct???
Also you might want to be able to disable any options on all the clients like shuffle , crossfade etc.
ProneaX is offline  
Old 26th July 2002, 00:37   #14
Garious
Junior Member
 
Join Date: Jul 2002
Location: Chicago
Posts: 21
Yeah, the name is intentional. You're very bright. Here's a cookie

_____
/ \
/ * \
| * * |
| * |
\ * * /
\_____/
Garious is offline  
Old 26th July 2002, 01:02   #15
Garious
Junior Member
 
Join Date: Jul 2002
Location: Chicago
Posts: 21
Drag, that looked great in reply window. I guess the text window is not the canvas of our imaginations. What can ya do?

Anyway, the client and server will be compiled as components separately from Winamp and loaded in as modules. They will each be, in a sense, plug-ins.
Garious is offline  
Old 26th July 2002, 02:40   #16
Garious
Junior Member
 
Join Date: Jul 2002
Location: Chicago
Posts: 21
This post is aimed at the development staff or anyone else who knows the SDK well.

Is the Wasabi thread-safe? For example, if I create a thread to listen for messages on a TCP port, can I call coreHandle.play() from that thread and not cause problems in the kernel?

If Winamp3 and all its modules are meant to run on a single thread, can I register a port to sleep on somewhere? I'm guessing you're probably calling sleep somewhere to time the next set of onPaint calls. Maybe you can change that to a select() call and sleep on a port too. Then you could allow the module to register a callback associated with a particular socket.

If neither of the two are possible, I think that means the only way to do it is to poll the sockets for messages whenever Winamp gives a us a chance. Is that true? If it is, what call does Winamp make most often to a module? Hopefully, it is not onPaint(), which is only called every 1/20th of a second. Please let me know.
Garious is offline  
Old 27th July 2002, 04:56   #17
thepyr0x
Major Dude
 
thepyr0x's Avatar
 
Join Date: Oct 2001
Location: At my house in a city in Canada
Posts: 1,336
I'll take u up on that gui offer........I can design guis (as I do for my mIRC scripts).....however I don't know where to start when workin with a winamp wac....so u'd hafta tell me what I need to dl and let me figure stuff out from there

thepyr0x is offline  
Old 28th July 2002, 06:49   #18
Garious
Junior Member
 
Join Date: Jul 2002
Location: Chicago
Posts: 21
Sweet! To get started, all you have to do is download the SDK. It comes with a bunch of really good examples for getting off the ground. You don't need to learn anything too tricky, just text, buttons, sliders, and check boxes.

The server GUI should probably be something on the lines of a window with a checkbox for syncing. "[box] Synchronize" perhaps? We should probably have some other stuff in there for what address to bind to, or maybe a 'public' checkbox. I don't know, be creative. This might require and 'Advanced' button for specifying protocol, ip, and port for those who might need to set up a router to pinhole a firewall.

If we can get this far, I'd like to make it so the GUI displays everyone who is connected. Also, if the client has remote-volume-control enabled, then a volume slider appears in the server GUI. And the final touch for that would be a master volume control that changes everybody's volume.

I don't think to client will need a GUI. It will only need to be able to let the user change preferences such as enabling remote-volume-control. If possible I'd like to make is so that you use playlists to determine what server you're going to connect to. That way you could switch between your own music and the broadcasted music.

The only other GUI related thing I can think of is actually a completely separate module. If we're gonna allow people to control the server remotely, then we should probably make it so you can lock winamp. This would just be a little window with a picture of an unlocked lock, and a button that says 'Lock'. If you click the button, the picture goes to a lock and the button changes to 'Unlock'. At this point you cannot change anything in winamp. When you click again to unlock, a window should pop up and say 'Enter Password'. Obviously, if you get it right, it goes back to the unlocked state. This might be a good GUI to write first since it is simple enough where you wouldn't have to wait on me at all.

As always, more ideas are welcome. I'd like to make this project all-inclusive and have it do everything you might want to do over the network.
Garious is offline  
Old 28th July 2002, 20:59   #19
Brennan
Monkey Hump Master
 
Brennan's Avatar
 
Join Date: Apr 2000
Posts: 782
Neat! You're right, Wasabi/Winamp3 is the perfect platform for you to build this on. I hope you do. And I have another piece of your puzzle almost solved for you, too, to let you have a single shared display for all people connected. I'm hoping to finish it for 3.1 once Francis adds a couple more hooks for me


--Brennan
Brennan is offline  
Old 29th July 2002, 06:34   #20
thepyr0x
Major Dude
 
thepyr0x's Avatar
 
Join Date: Oct 2001
Location: At my house in a city in Canada
Posts: 1,336
now I'm really lost...I've had the sdk here for a while...and i understand most of it
but i can't seem to compile anything......nor do I know where to start....damn you brennan
lol

thepyr0x is offline  
Old 31st July 2002, 01:17   #21
Garious
Junior Member
 
Join Date: Jul 2002
Location: Chicago
Posts: 21
I propose we do this project in phases. Once a person done with the items in his part of the phase, save a copy of everything so that other person can test with just that feature set. This may seem unnecessary, but it has been my experience that the go, go, go technique just doesn't hold together in real-world group projects.

Alpha: Most basic feature set
- Server GUI:
* checkbox to enable broadcasting
* checkbox to synchronization
- Client GUI:
* (optional) a box for what server to connect to
- Server core:
* handles broadcasting and syncing. No client control.
* songs will be synced in the most basic way possible
(after each song, everybody lets the server know when it is done, and then the server sends a play signal when everyone is ready)
* No support for cross-fading
* No complex buffering (DL for a quarter second, and then play)
- Client core:
* requests playlist and handles syncing control signals.

Beta:
Try for most of the features in the architecture but don't waste time on optimizations.

Final release: everything nice and optimized with cool graphics and good stuff like that.
---

The idea of the alpha phase is to see what is actually possible and rearchitect if necessary before we get too deep into this.

The beta phase is because we'll probably find that the limiting factor in what pushes things out of sync aren't what we first anticipated. Therefore, writing perfectly optimized code everywhere will more than likely just be a waste of time and keep this project from ever getting finished.

Once the end is in site, we can add all the bells and whistles.
Garious is offline  
Old 2nd August 2002, 03:33   #22
Garious
Junior Member
 
Join Date: Jul 2002
Location: Chicago
Posts: 21
I finally decided to quit yappin and start coding, but I ran into some trouble starting out. I'm running Visual Studio 6.0 on WindowsXP and I can compile but can't build the example projects.

This file, called How to make a new component.txt, comes with the SDK:
- copy generic.h, generic.cpp, rename them appropriately
- edit all the //EDITME stuff
- make a new DLL project
- set the output file to whatever.wac
- add your .cpp to your project
- add waclient.cpp to your project

I don't believe that that's all there is to it. I followed those instructions and got 400-some linker errors. I looked at the generic project and saw that it is dependent on the bfc project. So, I added the bfc project to my workspace and tried to build once more. This time I got 12 linker errors, all saying stuff like _malloc already defined in...

The bfc project builds fine, but in my project and all the example projects, as soon as a change the active project off of bfc, I cannot build.

What am I missin here?
Garious is offline  
Old 12th August 2002, 03:54   #23
Garious
Junior Member
 
Join Date: Jul 2002
Location: Chicago
Posts: 21
so i got the project to compile. i know i didn't do it the *right* way, so i'm not going to bother posting my crude hack.

thepyr0x, you working on the GUI at anymore? if so, where you at on it?

I started coding today (for real this time), and things seem to be coming along smoothly. I got most of the messaging foundation done. I'm just working on making all the messages in XML right now, and then I'll be ready to start making playlist calls. Alpha should be ready in no time.

Wishlist: I thought it might be neat to add in a simply instant messeging system where clients can request the server play certain songs. This wouldn't be terribly useful inside a house where you can just yell to people, but if people were to use this plugin for non-synced over-the-net broadcasting, it might be worthwhile, eh?

Lastly, I'm still looking for ideas on where I can hook into the kernel to poll the sockets of people connected to the server. Right now, it's still looking like the onPaint function is the way to go, which only occurs a mere 1/20th of a second. It's a great refresh rate for the screen, but an awfully long wait when trying to sync.
Garious is offline  
Old 12th August 2002, 12:21   #24
Da3MoN-LoRd
Junior Member
 
Join Date: Aug 2002
Location: Frankfurt, Germany
Posts: 4
Send a message via AIM to Da3MoN-LoRd Send a message via Yahoo to Da3MoN-LoRd
One possiblility for synching: just an idea:

ok, all computers have same music and same playlists;
one of them is server:
-this server synchs all client's system clocks
-then, the server sends packets to clients for events;
e.g. start playing song at this exact time
-this allows packets to be sent anytime throughout the song;
-this would completely remove any LAN bottlenecks and buffers,
etc.
-in theory it should work; i may do some practical experimentation;

i totally agree with the whole concept; having multiple pcs in my house on a LAN, synched winamps would be invaluable to house partys!

any feedback or modifications to the above networking ideas, let me know! I have VB programming experience, also, if i could be used for something. (I am also running Visual Studio 6 on Windows XP)

-Da3m
Da3MoN-LoRd is offline  
Old 13th August 2002, 04:59   #25
Garious
Junior Member
 
Join Date: Jul 2002
Location: Chicago
Posts: 21
That's a great idea. That would eliminate the problem of being 50ms out of sync right off because the sdk will only give us a chance to check the socket every 1/20th of a second (unless I'm wrong about that).

Unfortunately, it won't eliminate the need for buffering because the server (or client with permission) needs to be allowed to change the playlist or jump to a song in as close to real-time as possible.

As for programming, I don't think there's too much to do with VB for this project. However if you know VB, you can probably pick up C++ very quickly. Download the SDK, read over the examples, and if you seem to be able to pick it up, let me know. I can handle the core parts of the project, but there's plenty of pieces of the GUI that can be developed independently. If you'd be able to take on one or two of those pieces, that's be awesome.
Garious is offline  
Old 13th August 2002, 22:00   #26
Garious
Junior Member
 
Join Date: Jul 2002
Location: Chicago
Posts: 21
Today I talked at length with a wicked-smart networking developer and we ended up rearchitecting a bunch of stuff.

The biggest change is that we decided not to allow the clients to change the playlist on the server. Although it might be convienent to control the server from another room, we think it'd more likely just cause problems with people fighting over the song to play. It'd also force a lot of coding hassles, such as having to not allow changes to be made to the playlist while someone else is changing it.

My original reason for wanting client control was so that I could easily integrate it into a RF remote control project. However, now it seems like the only time I'd really want to do any remote administration is with my one remote control, so I might as well just have a component right on the server; no need for networking. Therefore, I've decided to leave client control up to someone else.

If someone wants to do that, let me know and I'll send you the code for the messaging foundation I wrote. It's very very easy to use. I also would be happy to help work it into my client component if it makes sense to combine the two.

The other thing that was brought to my attention is that each computer will fall out of sync simply because their clocks themselves won't stay in sync. I think this can be handled simply by syncing clocks sometime during every song by sending the server's time 4 or so times and taking the average difference in time between the server clock and client clock.

Lastly, my original plan was to just pass the url of the song the client should DL and play. My networking guru friend convinced me to make a slight tweet to that. Instead, the server always downloads the song to itself first and then passes the url to the downloaded song on its own machine. That way, the clients can play any song the server has access to. Also, it's much more bandwidth efficient to stream one song from the net and distribute it on the LAN, then to have everyone try streaming from the net at once.

To sum it all up, the basic flow of events is:

Server streams songs it plans to play.
Server sends its time to clients.
Server sends URL of song to play, and next song (or perhaps just the changes to a playlist).
Clients respond when they have buffered enough to start playing.
Server sends a time when each client should start the song.
When time-to-play gets within 1/20 sec, the client hogs the thread and waits till the exact time it is supposed to play, and then starts the song.
After song starts, server sends its time again.
And so on.

As always, comments and ideas are welcome and encouraged.

Greg
Garious is offline  
Old 13th August 2002, 22:13   #27
YtseJam
Forum King
 
YtseJam's Avatar
 
Join Date: Dec 2000
Location: Israel
Posts: 2,399
Send a message via ICQ to YtseJam Send a message via AIM to YtseJam
Hrm, I've got nothing to contribute here, but asking from a mod to move this to the Wa3 developing forum might be better for you... You could possibly get comments from other component programmers.
YtseJam is offline  
Old 16th August 2002, 23:57   #28
Caleb
Senior Member
 
Join Date: Feb 2002
Location: In The Llama's Ass
Posts: 364
hmm lets see..

i was thinking about something much simpler..
so ur saying that the server should be like a shoutcast server that sends the other pcs songs to play with prefect sync (all on a LAN)

hmm why not simply share the song directory, and make a component that forces winamp to play a song at a certain time (the server sends the command)

Currenly Working on: WA3 Scripting/XML IDE
Caleb is offline  
Old 21st August 2002, 03:45   #29
FarrisGoldstein
Junior Member
 
Join Date: Aug 2002
Location: Dallas, TX
Posts: 1
Send a message via AIM to FarrisGoldstein
Interested Newcomer

I've just skimmed over this thread, I'll read it in detail soon. I'd love to help out on this project any way that I can.
FarrisGoldstein is offline  
Old 21st August 2002, 19:33   #30
Garious
Junior Member
 
Join Date: Jul 2002
Location: Chicago
Posts: 21
FarrisGoldstein, lookin forward to hear from you. It looks like I'm going to be very short on time the next few weeks, so I may finish up the message handling code and hopefully the clock syncing, and hand off the project to someone else for a while.

Caleb, this broadcasting server won't send the songs to the clients. It will just send the URL of the song. The tricky part is that the server will buffer the song itself just before playing it. Then, the URL will always point to a file on the server. That way, as long as the client has network access to the server (which it needs to connect in the first place) it will be able to download the songs or streams to play with no problem.

Imagine an apartment building with 4 people in each room. Say each set of 4 has a router to share the same internet connection. Now let's say a couple apartments want to have a massive party and they all want the same music in perfect sync (visualize speakers from everyone's room pointing in towards a common balcony). With the current architecture, one computer can be the server. You'd set the router so the public IP points to that computer. Then the server admin makes a playlist full of songs from his roommates' computers (which aren't accessible from anyone outside their firewall). At the end of the playlist, the admin adds a shoutcast server because he's too lazy to add more songs. Now, anyone in the apartment complex can connect to the server and listen to all the songs which were originally within the private network.

In short, your plan for simplicity is a good one, but requires that everyone be behind the same firewall, and that all the computers connected have network access to the shared folders from where the server queued the songs.
Garious is offline  
Old 28th August 2002, 20:07   #31
largie
Member
 
Join Date: Apr 2002
Location: lars.werner.no
Posts: 63
Cool Netsyncing... Experience....

Hi...

I have made the NetSync for Winamp 2.xx (and soon Winamp 3.xx too)

If you have tested my plugin, it does sync at some point! But the main problem is network delay...

Here are some points I have found out:
* The delay on the networks are usally stable...
* The system delay is usally stable to...
* Adding all songs to local harddrive makes it easier to sync...

Now my sync is not made "realtime" as for network checking etc... So if you start a song the loading time will be different on every computer.. So I made a quick routine when the client start to play it checks the position of "masteramp" and then seeks to the position given by the server... Now this works as an easy solution...

As for the delays... I'll add the feature of setting the delay manually so people can sync manually on each of the networks...

I always make it simple... Simple is best!

Btw: If you need me for any code please ask... but my time is limited...
largie is offline  
Old 6th September 2002, 22:52   #32
Tiresius
Junior Member
 
Join Date: Sep 2002
Location: Dallas, TX
Posts: 1
Send a message via Yahoo to Tiresius
First off, I think is a really cool software problem. Can it be done using networking? I'm not sure. I've worked with speech recognition for the past few years and have sent alot of voice data over networks. But that data is sampled at 8khz 8bit mono ADPCM (usually), mp3 audio is way different. I don't think syncing song start times prior to actually starting to play will work very well. If you're using a URL to obtain the song file; HTTP, FTP or any shared disk access protocols will introduce delays that you have no control over. And downloading the entire song before play begins will introduce long transfer times that will be unacceptable (especially for a party).

Maybe using multicast connections with timing info and proper packet sizing could work. I'm not sure sending packets of mp3 audio would be effective due to the compression technique used. Maybe if you converted the MP3 to wav (RIFF) or something else on the fly you could have better control over how many ms of audio were sent at a time (at the expense of more network traffic), you could come up with a packet size that was most effective for your network bandwidth. Here's the part I'm not sure would work well, if a packet arrives late or not at all when audio is needed, just play silence at the client side until a packet arrives on time, this might not be so bad since the other computers around could make up the difference in audio playback.

So the client opens a multicast socket and starts receiving packets, each packet received contains the time to play the packet in ms (actual time doesn't matter, it's just a reference point) and some audio data. The client determines local system time in ms and uses that time as the difference between times from the server and on the client. You will want to collect a few packets comparing local system time to when you received the packet, adjusting for differences in packet delay. The human ear is what you're trying to satisfy, probably a slider for adjustment would be needed to synchronize the audio output at each client to a ms level.

Once the timing is agreed upon (with adjustment by a user at the client side) just have all the clients play current audio if the packet they received is in time to be played, else silence. I've over simplified this a bit I think, and there may be some additional timing sync issues I've negelected (sorry it's Fri nite for me). Also you could control what songs are played by using a queueing mechanism like requesting a song from a radio station and maybe even provide an admin type request to switch from the current song to something else if the current song is really bad. You'd probly wanna password protect that on the server though.

Sorry if I've rambled too long, just my 2 cents.
Tiresius is offline  
Old 27th September 2002, 16:33   #33
knightRaven
Junior Member
 
Join Date: Sep 2002
Location: Ontario, Canada
Posts: 2
Send a message via ICQ to knightRaven Send a message via Yahoo to knightRaven
Smile

Don't know if this helps or not, but I am the author of WbWinamp, which I have been using for the better part of 2+ years to control my music playing. It does already have a client/server architecture and I would be willing to share some of it.

I have dealt with some of these problems, and am having some difficulties porting to WA3... any chance of an exchange of ideas?

cheers,
Jack
knightRaven is offline  
Old 27th September 2002, 16:59   #34
largie
Member
 
Join Date: Apr 2002
Location: lars.werner.no
Posts: 63
Nice... please do so..

I have been working on the problem, and is soon finish to publish a beta on the WA site..

Now I have a problem with the SetPOS function and getpos function.. I have measured the delay between the nettwork, and I compare the data with the getpos function + the network delay...

Does anybody know if the GetPosition function return number of MS played?! Or does it return number of frames pr. sec?

Does anybody know?!
largie is offline  
Old 3rd October 2002, 20:36   #35
Garious
Junior Member
 
Join Date: Jul 2002
Location: Chicago
Posts: 21
Hey everybody,

I'm letting everyone know that I'm backing away from this project for a little while. The biggest reason is that I'm currently taking 17 credit hours in the UIUC Computer Engineering curriculum which is quite frankly, a whole sh*t load of work. A secondary and significant reason is that after using Winamp3 for about a month now, I honestly don't want to ask my roommates and neighbors to switch to it. It is ridiculously slow on older computers and still has plenty of bugs, specifically with file associations.

Now don't get me wrong. I like a lot of the concepts of Winamp3 and the development kit is really good and easy to learn. It WILL be an excellent program. However, I just don't think Winamp3 is ready to replace Winamp2 just yet, and so I'm going to put this project on hold until it is.

I'd like to thank everyone who has contributed to the architecture. Depending on the state of largie's NetSync, I may start it back up in early December during the UIUC winter break.

Lastly, I would not be in the slightest bit offended if somebody used the architecture to build the component without me. I only ask that you make the source code available to all.

-Greg
Garious is offline  
Old 28th January 2003, 11:54   #36
Upp3rd0G
Junior Member
 
Join Date: Jan 2003
Posts: 1
Any news on the subject? I am also looking for a solution described in this project.
Upp3rd0G is offline  
Old 28th January 2003, 17:39   #37
largie
Member
 
Join Date: Apr 2002
Location: lars.werner.no
Posts: 63
Progress! :)

SCHOOL SCHOOL SCHOOL WORK WORK WORK!

My project has drovned, but I will try soon to publish the sync functions... But I give no date YET!

Hopefully my workload will start to fall, so I can continue...

-Large
largie is offline  
Old 31st January 2003, 13:20   #38
loveisweakness
Junior Member
 
Join Date: Oct 2001
Posts: 30
Quote:
Originally posted by Da3MoN-LoRd
One possiblility for synching: just an idea:

ok, all computers have same music and same playlists;
one of them is server:
-this server synchs all client's system clocks
-then, the server sends packets to clients for events;
e.g. start playing song at this exact time
-this allows packets to be sent anytime throughout the song;
-this would completely remove any LAN bottlenecks and buffers,
etc.
-in theory it should work; i may do some practical experimentation;

i totally agree with the whole concept; having multiple pcs in my house on a LAN, synched winamps would be invaluable to house partys!

any feedback or modifications to the above networking ideas, let me know! I have VB programming experience, also, if i could be used for something. (I am also running Visual Studio 6 on Windows XP)

-Da3m
when looking at your idea it seems fairly sound tho having tested the synching thing i have found one slight problem in that, unless you have it repeatedly synch time each request the times can drift abnormally far, as i did taht at work, i wrote up a small program originally to turn all the computers off at 4, which worked, cept for the drift that began, so i wrote a time check into it and had it synch off the file server computer, i set it to check on boot up, at noon, and at 2, but in doing that while just looking at the screens post the noon synch and a few were off by a few seconds, and by the end of the day there was about a 8 second drift from first shutdown to final shutdown, while i'm sure that may have been caused by the fact that the shutdown and synch program was pulled out of my ass in visual basic because i really didnt want to walk around and shut them off (the original concept including sending udp packets as a killswitch to cause them to shut off, but the router didnt particularly care for that), but i do reccomend other people give it a shot, it seems practical.
loveisweakness is offline  
Old 15th February 2003, 12:07   #39
largie
Member
 
Join Date: Apr 2002
Location: lars.werner.no
Posts: 63
Now I have uploaded the new NetSYNC for Winamp3...

The sync is not the best! But it works pretty well... So look out for NetSYNC for Winamp3 in the components area!

This should be tested...
largie is offline  
Old 16th February 2003, 21:03   #40
capitalsfn
Junior Member
 
Join Date: Feb 2003
Posts: 1
Thumbs up

Hey Largie,

Glad to hear that someone is still working on the project. I looked around, but didn't see it in the components area. maybe it just takes a little while for them to update or something....any chance we could get a link?

-Blair
capitalsfn is offline  
 
Go Back   Winamp & Shoutcast Forums > Winamp3 > Wasabi Development

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump