Streaming to a TS channel on server

[AchimB]

Hi there,

I plan to use TS3 for our radio and would like to stream our radio stream to one or more Teamspeak channels.

I know that it is possible to have a Client PC with some VAC setup that will receive a stream with a Winamp and send it back to the server. I tried it and it works well.

But this is not what I want to do.

I would like to have a server application that will receive a stream from a shoutcast server and send it to a specific channel on a TS3 server.

I had a look into the SDK and as I am a programmer and I am able to code in C / C++ it shouldn't be a big issue to do so if it is possible.

In the SDK docs there are several options to open a playback / capture device, but as far as I could see, these are always devices (i.e. soundcards etc)

What I would need is a possibility to open such a capture / playback device that will give me the possibility to feed the raw stream (i.e. PCM samples) to the TS server.

The client lib should encode it and send it to the Server.

For another project it would be interesting to have something like this also for the playback device (i.e. the stream that comes from the TS3 server channel).

Now my question is : Is there a way to do this with the SDK ? Perhaps someone has a "pointer to the docs" where I can find a function or perhaps even a snippet of sample code how to do this ?

Thanks in advance

Achim

Edit:

Playing around with the SDK meanwhile and reading the SDK docs it showed, that the SDK Client was made - for whatever reason - incompatible to the public server. (Unable to connect)

So this makes it impossible to write cool Applications for Teamspeak 3 using the public Client / Server.

I would really like to know why this has been done and if it is planed to remove this restriction somewhere in the future, as it makes no sense for me.

[poktomi]

Hi Achim,

pls. let me know if you find anything. I am (technically) trying to do the same, except that I want to connect audio streams coming out of SIP dialogs (e.g. G.711 encoded audio data from an RTP stream) to the TS client and vice versa.
The only approach I have found, which should work on a server is a "virtual" audio device (Linux module snd-dummy).
This "virtually" corresponds to the VAC approach taken by (Windows) clients.

This seems quite "ugly" so I'm waiting before I pursue this - in the hope somebody points me to something easier and more elegant.
Ideally Teaspeak (anybody listening) would just expose the RTP streams

Keep me posted,

-p

Hi there,

I plan to use TS3 for our radio and would like to stream our radio stream to one or more Teamspeak channels.

I know that it is possible to have a Client PC with some VAC setup that will receive a stream with a Winamp and send it back to the server. I tried it and it works well.

But this is not what I want to do.

I would like to have a server application that will receive a stream from a shoutcast server and send it to a specific channel on a TS3 server.

I had a look into the SDK and as I am a programmer and I am able to code in C / C++ it shouldn't be a big issue to do so if it is possible.

In the SDK docs there are several options to open a playback / capture device, but as far as I could see, these are always devices (i.e. soundcards etc)

What I would need is a possibility to open such a capture / playback device that will give me the possibility to feed the raw stream (i.e. PCM samples) to the TS server.

The client lib should encode it and send it to the Server.

For another project it would be interesting to have something like this also for the playback device (i.e. the stream that comes from the TS3 server channel).

Now my question is : Is there a way to do this with the SDK ? Perhaps someone has a "pointer to the docs" where I can find a function or perhaps even a snippet of sample code how to do this ?

Thanks in advance

Achim

Edit:

Playing around with the SDK meanwhile and reading the SDK docs it showed, that the SDK Client was made - for whatever reason - incompatible to the public server. (Unable to connect)

So this makes it impossible to write cool Applications for Teamspeak 3 using the public Client / Server.

I would really like to know why this has been done and if it is planed to remove this restriction somewhere in the future, as it makes no sense for me.

[Elbandi]

snd-dummy module is a null module! (like the /dev/null), the "vac" module is snd-loopback. (it's not a vanila kernel module)

btw, i'm currently developing a TS3->shoutcast plugin... i need some day, to make public available.

[poktomi]

you are right of course, sorry for the typo. However I believe the module to be called snd-aloop.

In fact what seems to be more professional but also probably to high level and complex for what I want is JACK Audio.

snd-dummy module is a null module! (like the /dev/null), the "vac" module is snd-loopback. (it's not a vanila kernel module)

btw, i'm currently developing a TS3->shoutcast plugin... i need some day, to make public available.

regarding your project: is that the mechanism you are using or have you found another way?

thanks,

-p

[Elbandi]

if the recording started, the plugin get the voice data with onVoiceRecordDataEvent function.

[poktomi]

if the recording started, the plugin get the voice data with onVoiceRecordDataEvent function.

yo guy, now you got me hooked. pls. elaborate just a little bit.
can you the 5-10 surrounding lines of code too pls?

and i assume this means you are using the snd-aloop "trick" right?
thx,

-p

[poktomi]

if the recording started, the plugin get the voice data with onVoiceRecordDataEvent function.

the
const *float data parameter

is what format? I need it in PCM signed linear, which should be short rather than float, so I can convert it to G.711.

I do assume this is realtime, so if I "record" both clients audio stream and convert it to G.711 (and then put it into "my" RTP streams), I can thus "bridge" to SIP or any other RTP-based VoIP protocol, right?

finally getting there...

-p

[Elbandi]

i opened the original wav file in a editor, and say ist a "IEEE float 32-bit" wav. So this is the same. Because liblame use int wav, i sould convert to int array:

static void float32_to_short(const float in[], short out[], int num_samples)
{
int n;

for(n=0; n<num_samples; n++) {
int tmp = lrintf(in[n] * 32768.0f);
if (tmp > SHRT_MAX) {
out[n] = SHRT_MAX;
} else if (tmp < SHRT_MIN) {
out[n] = SHRT_MIN;
} else {
out[n] = (short) tmp;
}
}
}

[AchimB]

Hi !

nice to see that there are others working on similar projects I thought to set up a dialin to my Teamspeak as well. (TS <-> SIP/TS gateway <-> SIP phone)

We are still talking about starting the "official TS3 client" and wiring it to the snd-loopback device ? As I would like to set up the everthing on a Linux server this would mean I'll have to setup a Desktop so I can get the GUI-Client startet.

Or am I missing something ?

Bye

Achim

[Elbandi]

I have to write a plugin so official client, because i need to connect a real TS3 server. and it's running in a linux server (with Xvnc).

[poktomi]

Hi !

nice to see that there are others working on similar projects I thought to set up a dialin to my Teamspeak as well. (TS <-> SIP/TS gateway <-> SIP phone)

We are still talking about starting the "official TS3 client" and wiring it to the snd-loopback device ? As I would like to set up the everthing on a Linux server this would mean I'll have to setup a Desktop so I can get the GUI-Client startet.

Or am I missing something ?

Bye

Achim

At least that is what I am thinking (talking about). I will also be doing this on a Linux server, so let's stay in touch on this one.
And: where in the client_plugin_sdk is a GUI-client. Can't seem to find it.
From what I have read in the Forum the standard TS3 client will not work.

If you're serious about also working on a SIP gateway, let's collaborate. I can contribute most/lots on the SIP side and am a little weaker on the TS side.

Cheers,

-p

[poktomi]

I have to write a plugin so official client, because i need to connect a real TS3 server. and it's running in a linux server (with Xvnc).

so what do you do? I thought the SDK doesn't work with the current TS3 (kinda silly btw.; are you reading this TS team?)

the question is: we are developing stuff with this SDK and how will this ever move to production?

Or am I missing something?

-p

[Elbandi]

SDK != plugin SDK. i wrote a plugin.

[AchimB]

So, lets clean up a bit...

The SDK has its own server and client provided as library that you can integrate into your own application. These components are (for whatever reason) not compatible to the TS3 Server and TS3 Client, that one may download here. So it is not possible to use the SDK to extend the public downloadable Server/Client.

Next there is a Client Plugin SDK. This makes it possible to write Plugins for the official Client provided on this page.

But: To use this Client Plugin SDK you will need to use the official TS3 Client. This Client has a GUI thus installing this on a server requires some kind of Desktop Environment and - most likely - someone to start the Client manually, which makes it impossible to start it automatically during server reboot etc.

To use the TS3 environment I would need some kind of Client that is script-able so I can start it up when the server starts without the requirement of a GUI. I would need to get the audio streams to and from the client via an API (the snd-loopback is just a workaround).

Though I like TeamSpeak as I have used TS2 for several years now and the first checks of TS3 showed up a brilliant performance , I am not willing to work around these "political" barricades.

From my understanding it would be very easy for the TS guys to provide a library or some kind of API to connect to a public TS3 Server and extend their system. As they do not, I'll have to think about other "easy to use" conference systems.

From the commercial aspect, having special 3rd party clients would generate additional income from the required server licenses.

No comment so far from the team, so I think they are not interested into such kind of solutions and developing workarounds will probably lead into difficulties as you need the server licenses to run the "workaround clients".

[poktomi]

The question remains then: how did Phonecaster do it (PSTN - via Asterisk I believe - to Teamspeak gateway)???

-p

So, lets clean up a bit...

The SDK has its own server and client provided as library that you can integrate into your own application. These components are (for whatever reason) not compatible to the TS3 Server and TS3 Client, that one may download here. So it is not possible to use the SDK to extend the public downloadable Server/Client.

Next there is a Client Plugin SDK. This makes it possible to write Plugins for the official Client provided on this page.

But: To use this Client Plugin SDK you will need to use the official TS3 Client. This Client has a GUI thus installing this on a server requires some kind of Desktop Environment and - most likely - someone to start the Client manually, which makes it impossible to start it automatically during server reboot etc.

To use the TS3 environment I would need some kind of Client that is script-able so I can start it up when the server starts without the requirement of a GUI. I would need to get the audio streams to and from the client via an API (the snd-loopback is just a workaround).

Though I like TeamSpeak as I have used TS2 for several years now and the first checks of TS3 showed up a brilliant performance , I am not willing to work around these "political" barricades.

From my understanding it would be very easy for the TS guys to provide a library or some kind of API to connect to a public TS3 Server and extend their system. As they do not, I'll have to think about other "easy to use" conference systems.

From the commercial aspect, having special 3rd party clients would generate additional income from the required server licenses.

No comment so far from the team, so I think they are not interested into such kind of solutions and developing workarounds will probably lead into difficulties as you need the server licenses to run the "workaround clients".