Ability to streaming to shoutcast-server

[sm0svx]

Reported by do6ep on 21 Sep 2011 09:59 UTC Requesting an ability to streaming to shoutcast-server. SVXLink is blocking the audio-device so it is not able to use this device for streaming.

Possible (simple?) solution: SVXLink provides an virtual audio device what can used by SHOUTcast Transcoder

Other Idea: SVXLink act as streaming-client it self

[sm0svx]

Commented by guysoft on 17 May 2012 13:56 UTC What is required for this to work? Could you perhaps list here what the audio protocol that svxlink uses with remotetrx?

I thought the best way to run this is to get remotetrx to transmit to some simple client, that takes the audio and pipes it to shoutcast, or anything really. This way its external to svxlink itself.

[sm0svx]

Commented by sm0svx on 2 Sep 2012 09:29 UTC If you have a shoutcast transcoder that can take audio from stdin you can use the "file" Alsa plugin. Add this to your alsa config (~/.asoundrc or /etc/asound.conf), replacing shoutcast_streaming_command with the proper command.

pcm.shoutcast {
  type file
  slave {
    pcm null
  }
  format "raw"
  file "| shoutcast_streaming_command"
}

On a !RepeaterLogic, use a !MultiTx config section to split the TX audio into two outputs. One output should specify "alsa:shoutcast" as the audio device.

On a !SimplexLogic is's a bit more work. Here you need to set up another !SimplexLogic that is connected to the primary logic. You may want to use the logic_linking branch to be able to permanently link the two logics together. In trunk, it's only possible to activate a link by command.

This is untested but may give you a hint what to test to get it running.

[sm0svx]

Commented by guysoft on 8 Oct 2012 05:06 UTC Ok, I am currently using the simplex logic idea, and I think its works for my link better (I'm using an HT connected to a real repeater, the repeater logic seems to announce, even when I specify RGR_SOUND_DELAY=-1 , SHORT_IDENT_INTERVAL=0 , LONG_IDENT_INTERVAL=0 , so I rather stay on simplex).

I can easily get the linking done on startup. I just wrote a small SvxLinkWrapper module ( https://github.com/guysoft/SvxLinkWrapper/blob/master/src/modules/AutoLinkLogics.py ). That loads it up before echolink starts, works like a charm.

I have one small problem left:

Where do I point the RX logic in the second SimplexLogic? I tried creating a dummy-snd device, but then svxlink floods the terminal that there is audio distortion. For the meantime I just plugged a USB sound card I had here, but thats not a variable solution.

Hope to link here in a few days a shoutcast stream :)

[sm0svx]

Commented by guysoft on 8 Oct 2012 14:59 UTC Update: This command takes stdin, and once youconfigure ezstream will stream to any icecast server of your choice : sox -t s16 -r 8000 -c 2 - -t wav - | lame - - | ezstream -c ezstream.xml

I could test it by outputting a file (say /tmp/shoutcast), then streaming.

However it seems like the syntax of this is wrong: file "| shoutcast_streaming_command"

Or in my casse: file "| /path/to/shell/script/with/command/above"

I get bad file descriptor if I put the command above in a shell scirpt, the point to it. Are you sure the pipeline works in this case?

[sm0svx]

Commented by guysoft on 8 Oct 2012 20:41 UTC Update: Ok, this won't work because each time sound is sent a command is executed. There needs to be some kind of buffer between the shell script that is running, and ezstream or any other streaming service. The problem is that stdin stops in the middle. It might work if there is a way to keep the Tx open all the time.

[sm0svx]

Commented by sm0svx on 3 Mar 2013 10:42 UTC Try using "socat -u UDP-RECV:10001 - | your_command" and the new UDP "sound device" in SvxLink (e.g. AUDIO_DEV=udp:127.0.0.1:10000) in your TX config section.

[pe1chl]

I think it is possible to get it working without svxlink modification, and in fact Paul PE1RJV has set it up on our new PI3UTR computer, but we have not yet tried it in real life because the computer has not been installed on the repeater location (see pi3utr.nl) yet.

However, the approach has been like this:

• add snd-dummy to the /etc/modules file. this will make the system load the Dummy sound device at boot. do modprobe snd-dummy to load it in the currently running system.
• add another local Tx to svxlink with audio output device alsa:plughw:Dummy,0
• start any streaming software you like and input from plughw:Dummy,0

The Dummy sound device (snd-dummy) is a soundcard with 8 subdevices (so instead of ,0 you can add more devices up to ,7) which acts as a loopback. This overcomes the limitation mentioned in the initial post, and it means you can stream anything that can be output on a soundcard, even with more than one separate stream in a single machine.

[sm0svx]

Cool. Thanks for the info!

[pe1chl]

Ok later I found that this functionality of the Dummy soundcard was later changed in Alsa. Instead of the above, you should now use snd-aloop, which creates the Loopback sound device. You can Tx to e.g. Loopback,0,0 and then you can run the streaming software on Loopback,1,0. The subdevices (last digit) are 0-7 for this device as well (so you can have 8 streams), but the sound is relayed from device 0 to device 1 of the Loopback card. (and vice-versa)