View previous topic :: View next topic |
Author |
Message |
Yeppah
Joined: 10 Jun 2014 Posts: 2
|
Posted: Tue Jun 10, 2014 4:35 pm Post subject: Problematic behaviour on clients when source gets silent |
|
|
Hello everybody,
I'm trying to set up a simple audio bridge for wifi at home. The actual configuration works almost fine. But there is one big drawback at the moment:
When the source (Ices2 with Input from Soundcard by PulseAudio Monitor on a Ubuntu 14.04 Virtualbox) gets silent (for example by muting or pausing tracks), the stream on the clients is holding, too.
If you start a track again on the source, there are extreme delays because of the "waiting" clients.
I checked this behaviour with VLC and totem on a Ubuntu client.
The goal is, to have a constant stream from a PC to a client connected with a stereo, even if the source doesn't play anything.
A silent fallback audio file didn't helped so far. If ices2 is connected to the icecast2 server, the fallback isn't active and the client holds the stream.
Here are my configuration files:
Ices2
Code: |
<?xml version="1.0"?>
<ices>
<background>0</background>
<logpath>/var/log/ices</logpath>
<logfile>ices.log</logfile>
<logsize>2048</logsize>
<loglevel>4</loglevel>
<!-- logfile is ignored if this is set to 1 -->
<consolelog>1</consolelog>
<stream>
<metadata>
<name>Eiskanal</name>
</metadata>
<input>
<module>alsa</module>
<param name="rate">44100</param>
<param name="channels">2</param>
<param name="device">pulse</param>
<!-- Read metadata (from stdin by default, or -->
<!-- filename defined below (if the latter, only on SIGUSR1) -->
<param name="metadata">0</param>
<param name="metadatafilename">test</param>
</input>
<instance>
<hostname>localhost</hostname>
<port>8000</port>
<password>eiskanal</password>
<mount>/stream.ogg</mount>
<yp>0</yp> <!-- allow stream to be advertised on YP, default 0 -->
<encode>
<quality>9</quality>
<samplerate>44100</samplerate>
<channels>2</channels>
</encode>
<!-- stereo->mono downmixing, enabled by setting this to 1 -->
<downmix>0</downmix>
<resample>
<in-rate>44100</in-rate>
<out-rate>44100</out-rate>
</resample>
</instance>
</stream>
</ices>
|
Icecast2
Code: |
<icecast>
<location>Earth</location>
<admin>icemaster@localhost</admin>
<limits>
<clients>100</clients>
<sources>2</sources>
<threadpool>5</threadpool>
<queue-size>524288</queue-size>
<client-timeout>30</client-timeout>
<header-timeout>15</header-timeout>
<source-timeout>10</source-timeout>
<burst-on-connect>1</burst-on-connect>
<burst-size>65535</burst-size>
</limits>
<authentication>
<!-- Sources log in with username 'source' -->
<source-password>eiskanal</source-password>
<!-- Relays log in username 'relay' -->
<relay-password>eiskanal</relay-password>
<!-- Admin logs in with the username given below -->
<admin-user>admin</admin-user>
<admin-password>eiskanal</admin-password>
</authentication>
<hostname>localhost</hostname>
<listen-socket>
<port>8000</port>
<!-- <bind-address>127.0.0.1</bind-address> -->
<!-- <shoutcast-mount>/stream</shoutcast-mount> -->
</listen-socket>
<mount>
<mount-name>/stream.ogg</mount-name>
<fallback-mount>/fallback.ogg</fallback-mount>
<fallback-override>1</fallback-override>
<hidden>0</hidden>
</mount>
<fileserve>1</fileserve>
<paths>
<!-- basedir is only used if chroot is enabled -->
<basedir>/usr/share/icecast2</basedir>
<!-- Note that if <chroot> is turned on below, these paths must both
be relative to the new root, not the original root -->
<logdir>/var/log/icecast2</logdir>
<webroot>/usr/share/icecast2/web</webroot>
<adminroot>/usr/share/icecast2/admin</adminroot>
<alias source="/" destination="/status.xsl"/>
</paths>
<logging>
<accesslog>access.log</accesslog>
<errorlog>error.log</errorlog>
<!-- <playlistlog>playlist.log</playlistlog> -->
<loglevel>3</loglevel> <!-- 4 Debug, 3 Info, 2 Warn, 1 Error -->
<logsize>10000</logsize> <!-- Max size of a logfile -->
</logging>
<security>
<chroot>0</chroot>
</security>
</icecast>
|
I suppose that the client thinks that the stream is broken if there is no audio signal? Can you help me to find the problem?
Thanks for helping! |
|
Back to top |
|
|
karlH Code Warrior
Joined: 13 Jun 2005 Posts: 5476 Location: UK
|
Posted: Tue Jun 10, 2014 7:36 pm Post subject: |
|
|
firstly, drop the <resample> block in ices. I suspect you are suffering the very low bitrate that occurs on silence which takes a long time on the pre-buffer. This isn't normally a problem for people as they don't have silence for any length of time, but you could look at the managed bitrate modes, where you specify a minimum bitrate to apply for the variable nature of vorbis.
karl. |
|
Back to top |
|
|
Yeppah
Joined: 10 Jun 2014 Posts: 2
|
Posted: Wed Jun 11, 2014 2:29 pm Post subject: |
|
|
Thanks for the great tip!
Problem is solved by setting up a bitrate management according to http://www.icecast.org/docs/ices-2.0.2/config.html .
I strongly disagree with "[...], this option has very little use so should not really be needed." under the explanation for the <minimum-bitrate>-option . |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2002 phpBB Group subRebel style by ktauber
|