Re: And now...
On 13 Aug, Bruce Oblander wrote: > Yes...here's what I've got so far: > 1> I open one socket on my side at server initialization (I let Java pick the >local port) for > sending UDP packets > 2> Parse the GET HTTPheaders when FreeAmp connects and obtain it's receiving >UDP port (usually > 1 +) > 3> Send the x-audiocast strings as two separate packets to FreeAmp on it's >receiving (the > 1 +) > port (to be more specific: I create a datagram packet with the FreeAmp IP address >and the UDP port it > gave me > in the GET headers, and send the packet off). >4> I've verified that "something" has control of the passed in FreeAmp UDP port >by trying to open > another UDP > port using that same number and something (FreeAmp I presume) always owns that port. > > I'm pretty damn sure those are the correct steps. I'm also careful to create byte >arrays for the data > payload > of the UDP packet. Is there any way to see what FreeAmp is capturing on its UDP >port? Could this have > anything to do with byte order (i.e. big/little endian) - java is always big endian. Yeah, those are the correct steps. I would suggest placing a couple of debug printfs into the tstream.cpp code whenever FreeAmp receives any packets from the title server. Maybe the packets are somehow munged (likely caused by the UNICODE -> ASCII conversion) and FreeAmp thinks its getting trash and therefore tossing the packets. If FreeAmp is not getting anything, its on your end... Just some thoughts. --ruaok Freezerburn! All else is only icing. -- Soul Coughing Robert Kaye -- [EMAIL PROTECTED] http://moon.eorbit.net/~robert
Re: And now...
Yes...here's what I've got so far: 1> I open one socket on my side at server initialization (I let Java pick the local port) for sending UDP packets 2> Parse the GET HTTPheaders when FreeAmp connects and obtain it's receiving UDP port (usually 1 +) 3> Send the x-audiocast strings as two separate packets to FreeAmp on it's receiving (the 1 +) port (to be more specific: I create a datagram packet with the FreeAmp IP address and the UDP port it gave me in the GET headers, and send the packet off). 4> I've verified that "something" has control of the passed in FreeAmp UDP port by trying to open another UDP port using that same number and something (FreeAmp I presume) always owns that port. I'm pretty damn sure those are the correct steps. I'm also careful to create byte arrays for the data payload of the UDP packet. Is there any way to see what FreeAmp is capturing on its UDP port? Could this have anything to do with byte order (i.e. big/little endian) - java is always big endian. Still scratching my head on this one, Bruce [EMAIL PROTECTED] wrote: > On 12 Aug, Bruce Oblander wrote: > > Nope...this is for a "Shoutcast" type stream. I've gone so far as to capture the >network packets > > passed to FreeAmp and it looks like the "x-audiocast" commands are OK (and the >packets > > really are sent to FreeAmp) so me thinks you are correct but that leaves me at a >loss. Is the > > UDP port used for FreeAmp title streaming something different from java's >"Datagram" socket? > > This is pretty hard to screw up but I never cease to amaze myself. > > Thanks for refreshing my memory of your project. > > FreeAmp will open the server port and then send the stream server a > x-audiocast-udpport: header as part of the stream request. The title > stream information should be sent to that port. Are you doing that? > > --ruaok Freezerburn! All else is only icing. -- Soul Coughing > > Robert Kaye -- [EMAIL PROTECTED] http://moon.eorbit.net/~robert
Re: And now...
On 12 Aug, Bruce Oblander wrote: > Nope...this is for a "Shoutcast" type stream. I've gone so far as to capture the >network packets > passed to FreeAmp and it looks like the "x-audiocast" commands are OK (and the >packets > really are sent to FreeAmp) so me thinks you are correct but that leaves me at a >loss. Is the > UDP port used for FreeAmp title streaming something different from java's "Datagram" >socket? > This is pretty hard to screw up but I never cease to amaze myself. Thanks for refreshing my memory of your project. FreeAmp will open the server port and then send the stream server a x-audiocast-udpport: header as part of the stream request. The title stream information should be sent to that port. Are you doing that? --ruaok Freezerburn! All else is only icing. -- Soul Coughing Robert Kaye -- [EMAIL PROTECTED] http://moon.eorbit.net/~robert
Re: And now...
Nope...this is for a "Shoutcast" type stream. I've gone so far as to capture the network packets passed to FreeAmp and it looks like the "x-audiocast" commands are OK (and the packets really are sent to FreeAmp) so me thinks you are correct but that leaves me at a loss. Is the UDP port used for FreeAmp title streaming something different from java's "Datagram" socket? This is pretty hard to screw up but I never cease to amaze myself. Bruce [EMAIL PROTECTED] wrote: > On 6 Aug, Bruce Oblander wrote: > > Please excuse my ignorance but here's what my server is doingunsuccessfully: > > open a datagram socket with FreeAmp when FreeAmp connects (my server is a >Datagram > > client) > > when stream titles change: > > send a datagram packet consisting of: "x-audiocast-streamurl: >couldBeAnything" > > followed by another datagram packet of: "x-audiocast-streamtitle: > > alsoCouldBeAnything" > > (as far as I can tell from the code, there's one space after the ":" but, even if >there were > > two or three > > spaces, that wouldn't disrupt FreeAmp's parsing of the packet) > > You're doing RTP streaming, right? Unicast or multicast? I would guess > that the port setup is getting screwed up somewhere... > > --ruaok Freezerburn! All else is only icing. -- Soul Coughing > > Robert Kaye -- [EMAIL PROTECTED] http://moon.eorbit.net/~robert
Re: And now...
On 6 Aug, Bruce Oblander wrote: > Please excuse my ignorance but here's what my server is doingunsuccessfully: > open a datagram socket with FreeAmp when FreeAmp connects (my server is a >Datagram > client) > when stream titles change: > send a datagram packet consisting of: "x-audiocast-streamurl: >couldBeAnything" > followed by another datagram packet of: "x-audiocast-streamtitle: > alsoCouldBeAnything" > (as far as I can tell from the code, there's one space after the ":" but, even if >there were > two or three > spaces, that wouldn't disrupt FreeAmp's parsing of the packet) You're doing RTP streaming, right? Unicast or multicast? I would guess that the port setup is getting screwed up somewhere... --ruaok Freezerburn! All else is only icing. -- Soul Coughing Robert Kaye -- [EMAIL PROTECTED] http://moon.eorbit.net/~robert
Re: And now...
Please excuse my ignorance but here's what my server is doingunsuccessfully: open a datagram socket with FreeAmp when FreeAmp connects (my server is a Datagram client) when stream titles change: send a datagram packet consisting of: "x-audiocast-streamurl: couldBeAnything" followed by another datagram packet of: "x-audiocast-streamtitle: alsoCouldBeAnything" (as far as I can tell from the code, there's one space after the ":" but, even if there were two or three spaces, that wouldn't disrupt FreeAmp's parsing of the packet) The server isn't throwing any socket exceptions (and I've verified the UDP port at runtime) so, the data is sent *somewhere*. Is the above correct or is this another "Stupid Java/javaProgrammer trick" (lord knows I've seen lots of these in my project)? BTW, thanks for the pointers to the correct source code modules...knowing where to begin saves me a lot of time. Thank you for your patience, bruce oblander [EMAIL PROTECTED] wrote: > On 6 Aug, Bruce Oblander wrote: > > Got it...but one (well maybe two) more question: > > > > I send "x-audiocast-streamurl: myurl" to FreeAmp *once* when it connects to my >server. > > > > I'm then sending "x-audiocast-streamtitle: trackTitle" to FreeAmp as the titles > > change. > > > > is this correct or did I mis-read the code? > > No, the url and title are each sent when a new stream starts, and in > the case of Obsequeuim every 10 seconds as well. However, the code may > be confusing, since it uses two seperate packets and not one large > packet to the send the url and title. > > --ruaok Freezerburn! All else is only icing. -- Soul Coughing > > Robert Kaye -- [EMAIL PROTECTED] http://moon.eorbit.net/~robert
Re: And now...
On 6 Aug, Bruce Oblander wrote: > Got it...but one (well maybe two) more question: > > I send "x-audiocast-streamurl: myurl" to FreeAmp *once* when it connects to my >server. > > I'm then sending "x-audiocast-streamtitle: trackTitle" to FreeAmp as the titles > change. > > is this correct or did I mis-read the code? No, the url and title are each sent when a new stream starts, and in the case of Obsequeuim every 10 seconds as well. However, the code may be confusing, since it uses two seperate packets and not one large packet to the send the url and title. --ruaok Freezerburn! All else is only icing. -- Soul Coughing Robert Kaye -- [EMAIL PROTECTED] http://moon.eorbit.net/~robert
Re: And now...
On 5 Aug, Ross Finlayson wrote: > No! Please don't do this! The (RTP port)+1 is meant to be used for > sending/receiving RTCP reports. If you send anything else on that port, > you risk confusing receivers that listen for RTCP reports. Oops, I'm showing my RTP ignorance again. :-) Thanks for keeping me straight Ross. I'll go ahead and fix it in Obs and Freeamp. Is using port + 2 ok, or is there another established method that I should follow? > (BTW, one of the projects on my "to do" list is to define a RTP payload > format for streaming ID3v2 data. This, I think, will be the best way to do > multicast streaming of meta-data in the future.) Cool, I'd like to see it. --ruaok Freezerburn! All else is only icing. -- Soul Coughing Robert Kaye -- [EMAIL PROTECTED] http://moon.eorbit.net/~robert
Re: And now...
Got it...but one (well maybe two) more question: I send "x-audiocast-streamurl: myurl" to FreeAmp *once* when it connects to my server. I'm then sending "x-audiocast-streamtitle: trackTitle" to FreeAmp as the titles change. is this correct or did I mis-read the code? Thanks! bruce [EMAIL PROTECTED] wrote: > On 4 Aug, Bruce Oblander wrote: > > Sorry to break in here but... > > > > Mark and Rob, I'm the crazy guy working on the Java streaming mp3 server and was > > pondering the secret formula for feeding Title Streaming to FreeAmp. Ummm, what > > is it? Well, I confess, I'm just looking for shortcuts to avoid dissecting code. > > Well, it would be best for you to read io/src/tstream.cpp in freeamp > and xmit/Transmitter.cpp (int CVS) of Obs. > > However, the quick upshot is this: > > The client creates a upd server sockets and when it connects to an http > stream, it sends the port number to the remote server. The > shout/icecast server will then transmit the title of the stream in the > style of a http header. > > In the case of RTP/multicast, the server will simply transmit the > titles one port number higher on the same multicast address. > > --ruaok Freezerburn! All else is only icing. -- Soul Coughing > > Robert Kaye -- [EMAIL PROTECTED] http://moon.eorbit.net/~robert
Re: And now...
oops.. Ross Finlayson wrote: > >In the case of RTP/multicast, the server will simply transmit the > >titles one port number higher on the same multicast address. > > No! Please don't do this! The (RTP port)+1 is meant to be used for > sending/receiving RTCP reports. If you send anything else on that port, > you risk confusing receivers that listen for RTCP reports. > > The fact that Freeamp and "Obsequiem" don't use RTCP isn't so bad, but > having them use the RTCP port for something else is. So, please use some > other port. > > (BTW, one of the projects on my "to do" list is to define a RTP payload > format for streaming ID3v2 data. This, I think, will be the best way to do > multicast streaming of meta-data in the future.) > > Ross.
Re: And now...
>In the case of RTP/multicast, the server will simply transmit the >titles one port number higher on the same multicast address. No! Please don't do this! The (RTP port)+1 is meant to be used for sending/receiving RTCP reports. If you send anything else on that port, you risk confusing receivers that listen for RTCP reports. The fact that Freeamp and "Obsequiem" don't use RTCP isn't so bad, but having them use the RTCP port for something else is. So, please use some other port. (BTW, one of the projects on my "to do" list is to define a RTP payload format for streaming ID3v2 data. This, I think, will be the best way to do multicast streaming of meta-data in the future.) Ross.
Re: And now...
On 4 Aug, Bruce Oblander wrote: > Sorry to break in here but... > > Mark and Rob, I'm the crazy guy working on the Java streaming mp3 server and was > pondering the secret formula for feeding Title Streaming to FreeAmp. Ummm, what > is it? Well, I confess, I'm just looking for shortcuts to avoid dissecting code. Well, it would be best for you to read io/src/tstream.cpp in freeamp and xmit/Transmitter.cpp (int CVS) of Obs. However, the quick upshot is this: The client creates a upd server sockets and when it connects to an http stream, it sends the port number to the remote server. The shout/icecast server will then transmit the title of the stream in the style of a http header. In the case of RTP/multicast, the server will simply transmit the titles one port number higher on the same multicast address. --ruaok Freezerburn! All else is only icing. -- Soul Coughing Robert Kaye -- [EMAIL PROTECTED] http://moon.eorbit.net/~robert
